- From: Geert Josten <geert.josten@dayon.nl>
- Date: Fri, 20 Apr 2012 08:42:29 +0200
- To: Mike Sokolov <sokolov@ifactory.com>, Florent Georges <fgeorges@fgeorges.org>
- Cc: XProc Dev <xproc-dev@w3.org>
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 Friday, 20 April 2012 06:42:37 UTC