Re: RFP: CompoundStorage document



Hi Dietmar,

I believe that Bonobo is either the wrong way to solve this problem or solves this problem on a different level than I'd like to see it solved at. In my mind, these are functionally equivalent statements ;-)

What I'm looking for is a lower-level class heirarchy that Bonobo can build on top of, if it so chooses. You could create monikers for these different proposed storage classes. If you've already taken the time to map the Bonobo storage interface on top of disparate libraries (libefs and libole2), why not take the time to map the Bonobo storage inteface back on top of my proposed unified class(es)? The mapping from my proposed class to the Bonobo storage interface would seem to be fairly straightforward. It also seems to me that the interfaces could be practically identical and that we could grab the existing OLE2 and EFS code and push it upward into my proposed class. This way our classes and libraries are available to more people and platforms and still wholly & easily accessible to Bonobo. This inclusionary RFP seems to make sense, at least to me. You are, of course, free to disagree.

If my RFP is rejected by the GNOME community (nb: your suggestion will severely break my application), I'm prepared to go and invent this wheel nevertheless.

Cheers,
Dom

From: Dietmar Maurer <dietmar ximian com>
To: cinamod hotmail com
CC: gnome-office-list gnome org, Michael Meeks <michael ximian com>
Subject: Re: RFP: CompoundStorage document
Date: 10 Apr 2002 17:30:26 +0200

We have a working solution for that - called bonobo. The bonobo storage
interface is IMO the way to go. AFAIK we also have libefs and OLE2
bonobo monikers. libefs also supports encryptions and transactions. What
else do we need?

- Dietmar

On Wed, 2002-04-10 at 16:18, Dom Lachowicz wrote:
> KDE has something like this, and I'd think that it would be a good idea for > us to have something like it too. Feel free to disagree with me (or make my
> argument better, for that matter).
>
> What I'd like to see is an abstract baseclass/interface which sensibly
> represents a compound document. Some requirements would be:
>
> 1) Easy mime-type identification (possibly achieved through points 2,3)
> 2) Creation of heirarchical structure (subfolders inside of the document)
> 3) Creation of streams within the root folder (/) and subfolders
> 4) "Normal" file operations, such as reading, writing, seeking, ...
>
> This storage interface could be then implemented by things such as:
>
> * Zip/JAR (ala OpenOffice)
> * OLE2
> * TGZ (ala KOffice)
>
> I think that having a nice base interface which can be implemented by
> subclasses would be a great leap for us, especially as we try to achieve
> greater compatibility with existing products on the market, such as MSFT and
> OpenOffice.
>
> Just a throught up for grabs - I'd be interested in working on something
> like this. As a side bonus, other non-office applications could potentially
> benefit from this too.
>
> Dom
> /glad to see some traffic on this list again
>
> --
> Men are incapable of using sex to get what they want. Sex IS what men want.
> Sex is not the answer.  Sex is the question.  "Yes" is the answer.
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
> _______________________________________________
> gnome-office-list mailing list
> gnome-office-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-office-list


_______________________________________________
gnome-office-list mailing list
gnome-office-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-office-list


--
Men are incapable of using sex to get what they want. Sex IS what men want. Sex is not the answer. Sex is the question. "Yes" is the answer.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]