[dev] Splitting the share driver

[Gunnar Wrobel]

Hi Mike!

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

You are completely right. I got confused by the fact that there is
actually another id in the background, the datatree id.

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

This is also correct.

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

There is actually a place where shares are referred by name. Nag does
this for example in task.php when moving tasks from one tasklist to
the other. This is one of the problems for the kolab driver at the
moment since I need to derive the unique id from the display
name. Could the $share->move() function be modified to accept only
ids?

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

Yes and this is the actual problem for the kolab driver. I am forced
to link the unique share id to the folder name. And the user expects
the folder to be named according to the display name. So if the user
creates the "Family" address book there needs to be a "INBOX/Family"
folder in the IMAP tree rather than
"INBOX/dd9723e7ac00aae1829dea214a2f6621". 

So let me rephrase my initial question. Would it be possible to
collapse the creation and naming of shares into a &newShare($id,
$name) function?

Currently the main apps all call newShare($id) immediately followed by
$share->set('name', 'xyz'). If that could be collapsed into a single
function call then I'd be able to choose the name as unique id.

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

After your explanation it is clear, that my kolab problem does in fact
not relate to the ansel discussion. The datatree id in the background
does not matter for splitting the share driver. The problem is caused
by the fact that id and display name are more tightly coupled in the
kolab case.

So the problem with regard to the share id are only the move()
function and the newShare() call.

Thanks for your explanations!

Cheers

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : wrobel at pardus.de                          Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                      Hartwig-Hesse Str. 12
Fax    : +49 40 432 70855                            D-20257 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> Mail at ease - Kolab out of the box <<                 P at rdus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~