[dev] Turba shares and SyncML

[Karsten Fourmont]

thanks for the info, that did help.

So the history should be changed to store the share name rather than the 
  username/owner name as it currently does. This makes it consistent 
with the other apps as well.

So I did change the history code to look like this:

$history->log('turba:' .
($this->usingShares ? $this->share->name : $this->name) .
':' . $uid

I checked all usage of history in turba and adapted it. So it shouldn't 
break anything.

However all old history entries become useless with this change. I don't 
see a (practical) way to convert them.

Cheers,
  Karsten


Michael Rubinsky wrote:
> It's been a while now since I wrote the share support in Turba so I may 
> be a little rusty on the details, but the general gist of things for 
> sources / shares goes something like this:
> 
> For sources that support shares (SQL and IMSP), each horde user has a 
> 'default' share (not to be confused with the 'default_dir' that the user 
> chooses as a pref).  This default share corresponds to the address book 
> that is always present and is defined by the $cfgSources entry.  This 
> address book is referred to in the main Turba code simply as the source 
> type ('localsql' for example).  Turba_Driver::factory turns this into 
> something like 'localsql:karsten' to use as a share name in order to 
> retrieve the share information from the datatree. 
> 
> If the user has access to other shares, Turba creates new $cfgSources 
> entries on the fly for those shares.  The new entry is based on the 
> 'base' $cfrSources entry for that source type.  So, for example if you 
> have access to *my* personal SQL address book, Turba would create a new 
> $cfgSource entry with a key of 'localsql:mike'.  In this case, 
> Turba_Driver::factory sees the ':' in the source name and knows uses the 
> full name to retrieve the share info from DT. 
> 
> When you perform a search on a share enabled source, the Turba_Driver 
> that represents the address book being searched will determine what 
> owner_id (to use the SQL driver's nomenclature) to search.  For 
> 'default' address books this will be the horde username, for 
> user-created address books, this will be a 'uid' string.
> 
> I'm not that familiar with your SyncML code so I can only offer very 
> general suggestions here: It seems to me that we will need to have Turba 
> save both the source type as well as the username.  I may be missing 
> something here, and I'm not looking at the code at the moment, but it 
> currently looks impossible to know what source an entry was 
> added/deleted from.
> 
> My thought is that we should have Turba save both bits of data as we 
> need both in order to create a Turba_Driver that points to the correct 
> share.  For instance, in my horde_histories table, I have the following 
> object_uid 'turba:mike:20070111195012.34nrs5u9ldyc at portal.host.com'  
> This would have to be saved as:  
> 'turba:localsql:mike:20070111195012.34nrs5u9ldyc at portal.host.com'  Then 
> you should be able to pass something like 'turba:localsql:mike' to 
> Horde_History::getByTimestamp.  I'd have to look more closely to see if 
> this is a BC break or not though.
> 
> Another thing to consider is that I know we are trying to get rid of the 
> hierarchal nature of the shares in Turba to make them compatible with 
> the framework's Horde_Share code and Chuck's thinking was to do it by 
> making the source name part of the group_uid (So the group_uid would be 
> something like horde.shares.turba.localsql). Without looking at the 
> code, I'm not really sure how that would affect this...perhaps Chuck 
> could chime in here...
> 
> 
> Hope this helps you out somewhat.  If you have any other questions, 
> please ask.  When I am sitting down where I can look at the code to 
> refresh my memory I can probably give some more in depth answers.