Re: [xml-dev] Packaging (was Re: [xml-dev] Interoperability)

[Daniel Veillard <veillard@redhat.com>]

On Fri, Nov 16, 2001 at 05:31:47AM -0800, David Brownell wrote:
> David Megginson wrote:
> > It makes sense because it's widely deployed and proven to work (as
> > most of you know, Java's JAR format is zip-based).  The problem is
> > that ZIP is non-streaming -- you have to download the entire zip file
> > before you can start processing it, since the directory information is
> > at the end.  Until we know what people are actually going to do with
> > this stuff, it's hard to figure out the cost/benefit balance.

  The reason why ZIP was choosen over say zipped tar, is that at least
once it's available locally you can seek in the ZIP to the entry you're
interested into. Getting a package format which would be both streamable
and seekable might be an interesting challenge. Being able to seek is obviously
very important if you want to process large collections of packages
but are interested only in some kind of data (like a text indexer).

> To pick a nit, illustrate one of your point, and raise a question  ... :)
> 
>     - The JAR manifest is directory info that's required to be at
>       the beginning, specifically to avoid downloading the whole
>       thing before processing it.  (It's extensible metadata; ZIP is
>       short on certain kinds of metadata that's useful for stuff
>       like digital signatures.)

  Similary for the OpenOffice package, except the manifest is in XML
(hence extensible too which is very important if you want to add things
not present in an initial version like digital signatures). At least
that's what was discussed at the time, I didn't checked recently.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/