[dev] Shares and multiple storage backends

[Gunnar Wrobel]

Jan Schneider <jan at horde.org> writes:

> Zitat von Gunnar Wrobel <wrobel at pardus.de>:
>
>> 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?

I might have been confused by the fact that applications like Turba
and Ingo use a syntax like "kolab:MyDefaultShare" or
"sql:MyDefaultShare" in order to identify shares. I assumed that it
would be possible to use shares with different storage back ends at
the same time.

But indeed neither Turba nor Ingo seem to allow this. Is this a fixed
rule for all Horde apps? 

In that case the Kolab share driver could simply ignore the "kolab:"
prefix and assume that it always operates on a Kolab IMAP
back end. This is how I wanted to implement it initially but then I got
doubts :)

My line of thought was going into the direction of specifying the
required share driver within the storage back end parameters. Right now
there are boolean values used for both Ingo and Turba in order to
indicate if a given back end should use shares or not ("use_shares" in
the case of Turba, "shares" in case of Ingo).

I thought it might have been possible to enter the necessary share
driver here instead of a boolean value. So that the correct driver
would be chosen for each storage back end and you would not have the
global option currently available in the Horde configuration.

But I assume this would also cause severe problems with backward
compatibility.

If each app can only use shares on one back end the Kolab share driver
has no problems anyhow.

Thanks a lot for you feedback!

Cheers,

Gunnar

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

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                      Hartwig-Hesse Str. 12
Fax    : +49 40 432 70855                            D-20257 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~