[dev] Splitting the share driver

[Michael Rubinsky]

Quoting "Dr. Gunnar Wrobel" <wrobel at pardus.de>:

> Each share has an id as well as a name. While creating a horde share
> the id is commonly set to a random number - only if it is a default
> share the owners id will be used instead. Subsequently most code that
> creates new shares also sets the displayed name of the share.

To clarify here since the naming can get confusing - when you create a  
Horde_Share, it is the internal share name (lets call this share_name)  
that gets set (usually) to a unique id...and it is this value that you  
can see when browsing the shares using the DataTree page under  
Administration.

The Display name of the share is nothing more than a property stored  
within the share...there is no inherent restriction on the display  
name being unique.  If the display name were unique, than two users  
could not have a Turba address book with the same name, say "My  
Friends".


> This share name will usually be used to reference the share at a later
> time.

It is the share's unique name (share_name) that is used to reference  
the share at a later time...not the display name.


> While there is a function "getShareById" that retrieves shares
> by the id it is nearly never used throughout the horde modules

Without looking at the code, I'm not 100% sure, but I believe that  
this method is used to get a share by it's Datatree_Id, not it's  
share_name.  The Datatree_Id is how the share entry is uniquely  
identified in the Datatree tables. I know that this is how we retrieve  
gallery shares and images from the Ansel api since using the  
Datatree_Id is much faster than using than unique share_name.


> In my eyes it would be better to always refer to the actual id of the
> share rather than referencing the displayed name (even though it may
> also be unique). Is there any specific reason for having both id and
> displayed name as unique identifiers of shares?

I don't know of anywhere in Horde that uses the share's display name  
as a unique identifier.  I think you are thinking of the Datatree_Id  
and the unique share_name.


> While I am able to cope for the current situation whithin the kolab
> driver the code would be much cleaner if the id as the unique
> identifier would always be used to reference shares. The name of the
> shares would then only be fetched for display purposes.

This is how it works now.  Again, I think you are thinking of the  
unique share_name vs the datatree_id.

Most of the places that I'm aware of use the share's unique share_name  
to retrieve the share. For instance, in Turba shared address books are  
identified as something like  
`localsql:dd9723e7ac00aae1829dea214a2f6621` or `localsql:mrubinsk` for  
the user's default book.  User's can name their address books anything  
they like and this becomes the share's display name, and it is very  
likely two user's might create a address book named "Family" for  
instance.

There are other places, like in Ansel's api, that use the Datatree_Id  
to get the share, again, because it's faster than using the  
share_name. It might help clarify things if we look at the datatree as  
the 'backend' to the share system, then essentially what we are doing  
in Ansel, is accessing the share using a backend specific identifier.

I agree that it is confusing to access Shares in these two different  
ways, but I'm not sure what the answer is...on the one hand, referring  
to them by the Datatree_Id is cleaner looking and quicker - but moving  
to this approach Horde-wide is sure to break existing share code in  
almost all applications that use them.

Thanks,
mike

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