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

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> 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.

Not sure what you mean by transparently here.  Do you mean to build  
the conversion into the code itself, or run it as a maintenance task?

Just to be clear here (since you said you haven't been following the  
thread), this is only referring to updating contact lists that contain  
contacts from other address books and those other address books are  
visible whether or not shares are enabled.  It's not referring to the  
original flatten shares update. So...if your only using shares with a  
SQL source this particular issue wouldn't really be an issue - since  
you wouldn't even see any of the other sources with shares  
disabled...the larger data structure issue, of course, would still  
apply - though I'd have to agree with Chuck: while I understand your  
particular issue, I would see trying to implement both types of share  
structures as a step backwards since we are ultimately trying to  
remove datatree usage altogether.


>
> 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/
>
>
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>



Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2013 bytes
Desc: PGP Public Key
Url : http://lists.horde.org/archives/dev/attachments/20070718/78da7408/attachment.bin