[dev] [cvs] commit: turba/lib Turba.php base.php turba/lib/Driver imsp.php share.php

Jan Schneider jan at horde.org
Wed Jul 18 21:12:57 UTC 2007


Zitat von Michael Rubinsky <mike at theupstairsroom.com>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael Rubinsky <mike at theupstairsroom.com>:
>>
>>> Ok. I've been looking at this on and off over the last week or so
>>> and  here's the deal:  In order to get contact lists to work
>>> correctly in  *all* cases, we need to provide not only unique share
>>> ids / cfgSource  keys, but they need to be predictable,
>>> reproduceable, and (for the  cfgSource keys at least) the same
>>> whether we are using shares or not  for a particular source.
>>> Otherwise, if an installation goes from not  using shares to using
>>> shares (or vice versa) then any contact lists,  in any source, that
>>> contain contacts from the newly 'sharified' source  would break -
>>> those contacts would not be found since the key used to  identify
>>> the source would change.
>>
>> If this is the only holdup, then I don't think this is that much of a
>> problem - changing the use_shares source _is_ changing the source of
>> the contacts in it, and if we could have an upgrade or "switch" script
>> for it.
>
> Ok.  The only gotcha here is that any upgrade script wouldn't be  
> able  to update sources that need a user login...like IMSP.  But I  
> guess as  long as we document this somewhere at least admins will  
> know.

Maybe the update could be done transparently. I personally won't like  
that because I still need to run the same address books on both the  
FW_3 and HEAD versions and rather want to decide myself when I'm going  
to upgrade them, but it's much nicer for the admins and fixes the  
authentication problem.

I didn't follow this whole thread, but do you guys think it's possible  
to either keep some code in HEAD that still works with the old data  
style, or add some forward compatible code to FW_3 that supports the  
new style, so that transition is easier? I think this is the first  
time that we break some important data structures so much that you  
can't run the two versions side-by-side at all.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list