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

[Michael Rubinsky]

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.

>
>>  We can keep the actual storage somewhat cleaner though by
>> introducing  a 'name' paremeter in the 'params' attribute in the
>> share if desired -  it would essentially be the 'raw' value for the
>> address book  name...for sql sources, for example this would either
>> be the username  or the uid string for user created address books
>> and for imsp sources,  it would be either the imsp username (for
>> default address book) or  username.bookname for other address books.
>
> That doesn't seem so bad. I've already resigned myself to/figured out
> that having some sort of "params" is necessary, so if any info like
> this goes here, that's better. Still lets us use autoincrement ids for
> shares with a future straight-sql share driver. :)

Cool. I've suppose it's also worth mentioning that I've been going  
under the assumption that we still need to create the md5(mt_rand())  
style keys from Turba since there's no bc way to have the share system  
create it's own keys at this point...


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/8ce77912/attachment.bin