[dev] Shares and multiple storage backends

[Jan Schneider]

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

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

Yes, Turba for example used the source name as a prefix to easier map  
a share back to the storage backend, because it's always coupled with  
that one. So no, you can have the same share using different backends  
or even switching the backend.

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

No, the share driver is always defined globally and never changed.

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

Good.

Jan.

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