[dev] Shares and multiple storage backends
Gunnar Wrobel
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?
Thanks in advance!
Cheers,
Gunnar
--
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p...@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@rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-uns...@lists.horde.org
Jan Schneider
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/
Gunnar Wrobel
> Zitat von Gunnar Wrobel <wro...@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...@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@rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Jan Schneider
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/