Re: object setsitegroup

Jukka Zitting wrote:
> Hi,
> 
> On 3/8/06, Tarjei Huse <tarjei-y/[email protected]> wrote:
>> Piotras wrote:
>>> 1. Create new sitegroup with admin group and admin person.
>>>     And this can be solved with ability to set sitegroup when create method is called.
>> Please add :
>> Also create host (as you have to be sg0 for that), pages and topics for
>> the sitegroup.
> 
> The feature should be included in the generic $object->create() method
> so it applies to all cases.
> 
>>> 3. setsitegroup method should be replaced with object's replication.
>> ?? Please explain that one.
> 
> I still don't see a good use case for moving existing objects from one
> sitegroup to another. If that is needed, a better approach is to
> create a copy in the other sitegroup and delete the original object.
> That will avoid all the hairy database consistency issues.
I guess a clone method might be ok.

I'm not perfectly happy with that as I can se usecases where you want to 
do development and then deploy to a client or move functionality from 
one client and up to sg0 for sharing.

Still, it is better to define limits and have something that works than 
to have no limits and nothing working.

Afaik Piotras has fixed the bug that started this thread, but maybe not 
according to how the code should work in the future?

I would like to see an mRFC on sitegrouphandling quite soon so that we 
got a clrea idea on how to move forward.
Tarjei

> 
>>> 5. Sitegroup delimeters should be dropped, or optionally supported.
>> Maybe only supported in basic auth?
> 
> Sounds good, the delimiter parsing code could all be moved to midgard-apache.
> 
> BR,
> 
> Jukka Zitting
> 
> --
> Yukatan - http://yukatan.fi/ - [email protected]
> Software craftsmanship, JCR consulting, and Java development