[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