Re: Request: Test suite for EFS.

[bob thestuff net]

He's right about useing url's in the xml file. a relative url would be
perfect. And a directory would work good to store it. If you need to put
it all into one file, you could just use a gnome-vfs tar file.

On Thu, 17 Feb 2000, Daniel Veillard wrote:

> On Wed, Feb 16, 2000 at 08:15:52AM -0600, Miguel de Icaza wrote:
> > 
> > Hello Daniel,
> > 
> > >   I afraid you are gonna object that you don't have time to pusue the issue
> > > that it's too complicated and you have a product to ship. I already got this
> > > argument for not switching gtkHtml to the libxml/DOM code. I feel concerned
> > > about this. Until now Gnome was very nice in the sense that people took the
> > > time to stick to Do The Right Thing even if it was a bit more painful/slower.
> > 
> > Please do not take this position.
> 
>   I would very happily retract that as soon as I see I'm wrong :-)
> 
> > As we talked in the past, the GtkHTML code would in the future use
> > libxml/DOM code.  But this --as usual-- needs a devoted hacker to work
> > on this.  The work that Ettore is doing is related to add the features
> > we need and the stability we need to GtkHTML: an existing code base.
> 
>   Point taken. But libxml/gdome exists already. Some APIs may change,
> and it will be expanded, but there is a code base. IMHO the real question
> is:
>   - do we need 2 HTML widget ? One small/fast and limited feature wise
>     (HTML only, no editing, limited hyperlinking, no CSS), still useful in a number
>     of applications, and another more complex handling editing and a whole
>     bunch of other "nice" but heavy feature (XML/CSS/DOM/...).
> 
>  I tend to think the answer is yes, the first one certainly would be sufficient
> for a number of simple usages (help browser ... though structure based
> annotations would be nice). 
>  Problem in that case is that Ettore and other gtkhtml folks are working
> on taking a code base suitable for the first one and trying to extend it
> to have the extra set of feature. And that's where I think there is an
> improper decision.
> 
> > But this does not mean that Ettore is the only hacker ever allowed to
> > touch that code base.  If you want to help with the DOM/libxml effort,
> > feel free to jump in, and help switching GtkHTML code there.
> 
>   Well for the moment I'm focusing on the lower layers. When libxml-2.0
> will ship I will certainly look at it.
> 
> > It is completely absurd to think that we wont ship an HTML engine
> > because it is not fully DOM enabled.  But if you want to change
> > things, you can be part of it.  
> >
> > while in the real world people choose solutions based on proprietary
> > software.  Probably for academia (or Federico :-)) it makes sense to
> > wait until you have everything perfectly done.  But it is just not
> > possible to negate people GtkHTML because it does not use the DOM.
> 
>   I don't negate. Do not take my words take gtkHtml people ones.
> I don't think gtkHtml is bad. I say extending a code base primarily
> targetted at simple rendering to make it an editing widget is not a good
> decision. I understand this choice was mostly based on time constraints.
> I believe also that this complicate the code base of the initial simple
> widget, maybe making it less suitable for simpler task.
> Am I wrong ?
>   
> > On the Structured Storage front: I still think storing everything as
> > XML is highly inneficient.
>   
>   Yes
> 
> > Why would I want to store my images as
> > base64, if I can store them directly in the way they have shown up?
> 
>   Store them the way they are, make them referencable as URL. add metadata
> to those resources, index them and put wrapper front-end as separate
> resources if you really need to glue them in an unique way. Your problem
> is in the address space, not in the format !
> 
> > How can I address the problems I described before?
> 
>   By taking the problem in a different way. Why do you need a single unique
> resource for multiple flows of data ? This makes your life really hard
> for indexing/searching/extracting. All this because you believe that
> the compound set of resource should be unique. As a result you're creating
> (opaque) herarchies, hard to browse/index. 
>   Shift your mind that's the solution. There is only one address space,
> it's flat and based on URL (absolute or relative).
> 
> > You did not reply to my mail on the reasons why libefs made sense, but
> > you did reply to Nat's "we need ss for Bonobo".
> 
>   Libefs makes sense if you really need to merge everything on a single
> resource for sharing, say save onto a floppy. But why don't you just 
> copy every individual resources onto a dir an  make the entry point
> a simple (why not XML) file pointing at the different resources, giving
> their mime type, and all the other metadata you would need about them ?
> 
>   Daniel
> 
> -- 
> Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
> Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
> Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
>  http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>