[dev] [cvs] commit: turba/lib Turba.php

[Chuck Hagenbuch]

Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> This at least breaks IMSP shares, since they rely on this attribute   
> being set properly.  In essence, this turns all IMSP sources into  
> one  big address book from Turba's point of view.

The problem is that it was taking my existing shares, which have no  
'name' attribute, and using an empty value for them in a few places  
(generating warnings - do you develop with error_reporting set to  
E_ALL? If not, please change that now), and also was causing Turba to  
segfault for me. I never really traced that down farther than Turba,  
though.

> The 'name' attribute *should* be set in all shares with this code,

New shares, I guess, but people using existing Turba probably saw what I saw.

> although I am still working on the flatten shares upgrade script.   
> Plus, I suppose we will need an additional script for those that  
> have  already run the flatten shares on 'virgin' data (there are  
> other  things that need to be set as well

Definitely. Fwiw, this new code created several duplicate address  
books for me; in the course of cleaning them up I ended up nuking my  
address book because I had multiple address books with a backend key  
of "chuck". Fortunately (because of a previous incident, that time  
with poorly conceived testing code for Turba), I have very thorough  
backups and didn't lose anything, but this is not good behavior.

Fwiw, I really don't like the new default share behavior. There is  
absolutely no way now *not* to have your own addressbook even if you  
don't want one. I did some manual hacking on the saved parameters to  
get things back to how my family uses Turba; it wouldn't have been  
possible otherwise.

> I'm trying to figure a way to remove the IMSP driver's dependency on  
>  this attribute, but the 'name' parameter is used in various   
> places...it's the only place for shares where we actually store the   
> backend's name for this address book (owner_id for sql shares,  
> address  book name for IMSP shares) I'm not 100% sure how shares are  
> working  for you at all without ['params']['name'] being set in your  
> shares...

Well, after your changes, they apparently weren't. :)

-chuck