[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>:
>
>>   Log:
>>   Fix problem where multiple share enabled sources could cause
>> cfgSources key collisions. This should (hopefully) close Bug: 5535
>>   Any testing / feedback welcome.
>
> Here's the thing: I've been trying to get away from the share keys
> containing meaning. That we name default shares after users is bad
> enough, when for a SQL-based share driver we should really just have
> an integer primary key. Having a display name and a non-display name
> is not a great situation (see datatree_id and datatree_name).
>
> I might be on the wrong track here; we might _want_ share ids to
> contain meaning - but we can't really specify that meaning for all
> possible backends, or we can't really assume it'll be the same.
>
> So I think I like your other idea, of having the drivers do the
> default share check, better. The IMSP driver can know what its shares
> are named and handle them appropriately, and the SQL driver can let a
> default implementation (in the base turba_driver class) look at
> whether a share with the parameter "default" exists... that sound
> doable?


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.

So, while we really don't have to give the share keys *meaning* per  
se, we do need to make sure we can produce predictable, unique values  
for those keys that would make sense either with or without shares.   
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.

This, of course would still hold true no matter what object is  
responsible for creating the names, checking for default shares  
etc...so, even if it makes sense for specific drivers to know how to  
name their default shares, we still need them to produce something  
like 'source.name' or 'source%name' or whatever...

I've got this mostly worked out in my source tree, just need to tweak  
it some, but wanted to get more thoughts, feedback (or smacks in the  
head for overlooking something obvious) before moving forward.


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