Re: Request: Test suite for EFS.

[Daniel Veillard <Daniel Veillard w3 org>]

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