Dirk... its Jun :) I think Tils is getting to you. He is the only one that calls me Yun.
1 object and multiple packages is possible. Lets look at for example news object. A news package is the mother package, but since the news object is a content type, its possible that another cms package can either manipulate it or display it. I am not disagreeing with putting package_id. Just would like to make sure that its not enforced to be 1:1. One of the main purpose of making a central object system is that other packages can either display or manipulate it. If it was the case of 1:1 then its like ACS 3.x. Basically it may not only be central services that can touch other objects. It may well be other packages. For example integration between logger and bug tracker, these packages may be manipulating a single shared object. Anyway main point is that I hope I voiced out that 1:1 on package_id will NOT be imposed.
As for the name. If we are to put it into acs_objects then we should remove cr_items.name. maybe leave it there for legacy, not sure. But it should be nice that it should not be duplicate.
As for stuffing all named objects into CR. Some may disagree on the additional bagage CR will put.
The way I see it I think here are the options:
- add fields to acs_objects, if some exists in CR. Remove from CR like name.
- put every name object in CR. and slim down CR.
- since acs_object is too light and CR is too heavy. Create something in between.
I am not sure where to go. But I do think that change is ok and good. Just not sure where is the best path. Hopefully with some more input, you will be able to decide our best path.
BTW, as for the archive_p, delete_p or state column. publish_status in CR looks similar, but not the same.
