Re: [HC Evolution] Re: libole2 -> gnomevfs backend?

[Arturo Tena <arturo directmail org>]

Ettore Perazzoli wrote:
>     Michael>    Hmm; herein lies an interesting quandry. The real
>     Michael> reason the merge was not done was licensing, it was
>     Michael> thought that leaving libole2 GPL was a good idea [ after
>     Michael> some discussion ], although libole2's design should lend
>     Michael> to rather simple vfs-ing.
>
>   Uhm, I am not sure what you mean here.  Do you mean that adding a
> libole2 backend to gnome-vfs was not done because libole2 is GPL and
> gnome-vfs is LGPL?
>
>   Actually, gnome-vfs still has a problem with modules based on GPL
> libraries, because it has no license protection.  This means that you
> can link a proprietary application with gnome-vfs, and then gnome-vfs
> might load a GPL module, thus violating the license.
>
>   But this is actually rather easy to fix and will have to be added
> anyway (it has been in the gnome-vfs to-do list for a loong time).  (I
> would do this right away, but I have no time ATM.)

How will you fix it, since it is a licensing issue, not a techical issue, if I understood
correctly.

>   Actually I do think keeping libole2 GPL is a good idea myself.

Agreed.

>     Michael>    If I was going to choose a robust in-file filing
>     Michael> system to store all my vital mail in I would not
>     Michael> automaticaly choose libole2 :-) Although it has had a
>     Michael> load of testing there are still a few skeletons in the
>     Michael> closet ( eg. seeking beyond the end of a stream doesn't
>     Michael> extend it etc. ).
>
>   What about efs then?

I don't know the current state of efs, but it was supposed to be exactly what Evolution
was looking for: a non-propietary file-system-in-a-file, cappable to storing any kind of
information in a hierarchy. But, I don't know if it was designed for performance (I just
know it uses UNIX inode ideas).

>     Michael>    Possibly it is a good idea, certainly it shouldn't be
>     Michael> too tough though quite why it is any better than
>     Michael> eg. tar.gz or zip format is beyond me.
>
>   I think the problem with `tar.gz' and `zip' is that they are not
> going to be fast.  It's a real pain to update them.

Agreed.

>   But, incidentally, I must say am not very fond of this
> filesystem-in-a-file idea myself.  Why not just using a directory?

Because that way, a user only needs to copy one single file, no matter if their document
has embedded images or so.

> --
> Ettore