- From: Mike Sokolov <sokolov@ifactory.com>
- Date: Fri, 20 Apr 2012 22:46:44 -0400
- To: Geert Josten <geert.josten@dayon.nl>
- CC: Florent Georges <fgeorges@fgeorges.org>, XProc Dev <xproc-dev@w3.org>
I read more about the zip format, and I think in fact there's no reason one can't present a directory abstraction that allows for efficient retrieval of the contents of a directory. And it would definitely be a benefit. Sorry for the noise. -Mike On 4/20/2012 2:42 AM, Geert Josten wrote: > I think Florent was talking about the manifest of a zip (for creation or > investigation). I don't see why the representation of the manifest needs > to influence the speed of extracting individual files. > > Kind regards, > Geert > >> -----Oorspronkelijk bericht----- >> Van: Mike Sokolov [mailto:sokolov@ifactory.com] >> Verzonden: maandag 16 april 2012 14:46 >> Aan: Florent Georges >> CC: XProc Dev >> Onderwerp: Re: EXProc ZIP content representation >> >> On 4/15/2012 2:26 PM, Florent Georges wrote: >>> BTW, I don't undesrtand why the entries are represented as a flat >>> list, instead of a tree of dirs and files. The entry names in a ZIP >>> file are a flattened view of what they represent: a tree structure. >>> Wouldn't it make more sense to represent it in XML? That's what we >>> have in the EXPath ZIP functions<http://expath.org/spec/zip> for >>> instance, and IMHO it is way easier to use with XML technologies >>> (naturally tree-oriented). >>> >> One possible danger of presenting a tree directory structure on top of >> Zip's flattened internal model is that users of the API might expect it >> to be efficient to retrieve files in a sub-directory. But will it be? >> I'm in favor of having APIs that accurately reflect the underlying data >> model so as to avoid surprises like that. >> >> -Mike
Received on Saturday, 21 April 2012 02:47:24 UTC