[dev] Turba shares and SyncML

[Michael Rubinsky]

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.



> Hi,
>
> I need some understanding of the Tuba share system to get it working 
> properly with the SyncML code.
>
> Currently mnemo,nag and kronolith syncs are done against the default 
> share as defined in the respective applications (typically the username, 
> like "karsten"). Ultimately this should be user configurable, but that's 
> for later.
>
> In Turba, things are a bit different.
> $prefs->getValue('default_dir')
>
> yield the name of the source.php source, like "localsql".
>
> In such a source there are various "subsources"(?), like "karsten".
>
> For turba_import, turba_replace, and turba_export this is just fine.
>
> However syncing needs the turba_listBy functionality that lists all 
> changes of a given sources (localsql) since a specific timestamp.
>
> So how would I implement the correct listBy functionality for Turba?
>
> First guess is to store the source (localsql) rather than the owner in 
> the Turba history entry. Otherwise we have no way to find out changes in 
> localsql.
>
> But then the listBy need to do some "filtering" on the entries in the 
> history, so that only the ones available for the specific user (the 
> right "subsources") are returned. imho this needs to be similar to the 
> Turba_Driver::search code. But how?
>
> Can anyone provide me with input for this? A general description how 
> turba sources work would be a start. I'd very much like to get this done 
> for Horde 3.2.
>
>
> Cheers,
>   Karsten
>
>
>   


-- 
Thanks,
Mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org