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

[Chuck Hagenbuch]

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.

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

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

Okay.

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

Feel free to smack me back. :)

-chuck