[dev] Shares and multiple storage backends

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at pardus.de>:

> Hi!
>
> I have been working on extending the Horde share driver to work
> together with Kolab (http://www.kolab.org) shares. Basically Kolab
> uses IMAP folders as shared storage objects. Most of the functionality
> provided by the original DataTree-based share driver can be mapped to
> an IMAP server based system without problems. But I did hit an impasse
> now and would be happy if I could get some feedback.
>
> The DataTree share driver is able to handle shares for different
> storage back ends simultaneously. For example you could activate an
> SQL-based and an LDAP-based source for addresses within Turba and let
> the DataTree share handler handle shares across both sources at the
> same time. This is something the Kolab driver is currently not able to
> handle since the list of available shares is strongly linked to the
> actual storage backend (IMAP in the case of Kolab).
>
> Now I considered the possibility of extending the Kolab share driver
> so that it provides the necessary capabilities to support shares for
> multiple storage back ends. This would be possible but I assume that
> it would result in an awkward hack and would only have very few use
> cases.
>
> Then I did take a closer look at Ingo (following Chucks hints in
> http://bugs.horde.org/ticket/?id=5117) and realized that the DataTree
> driver seems to have its own problems with regard to handling shares
> over different storage back ends.
>
> The DataTree driver may declare shares that simply won't work if the
> storage back end does not allow users to see/edit the data of other
> users.  This is the case if you use LDAP as a storage back end. The
> LDAP permissions will have to allow users shared access to data and
> that is something the DataTree driver cannot influence even if you
> declare the shares within the driver.
>
> So my resulting question would be if the handling of shares should not
> rather be linked to specific storage drivers instead of having one
> global share configuration that allows you to choose only one driver
> for all storage backends at the same time?

This is not possible due to visibility issues. All applications and  
their storage backend can access the global share system in Horde. But  
the share system doesn't know anything about installed applications,  
available storage drivers etc. As you already noticed it's a very  
abstract view on available shares. They are only defined inside the  
share system, no matter if they have any counterpart in an  
application. Thus we can't link shares to to specific storage drivers.

Unfortunately I don't have an idea how else to solve this dilemma, I  
guess we need to put the responsibility of activating shares into the  
hands of administrators, and document that properly. E.g. document in  
ingo/config/backends.php that 'shares' can only be enabled if using  
the sql storage driver or a preference driver that allows access  
without user credentials.

But I don't understand what exactly your problem with the Kolab shares  
is, because due to the nature of this driver, the shares *are* already  
tightly coupled to the storage backends, because they are annotations  
of the imap folders containing the data. Or am I missing anything?

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/