[delphizip] Fwd: [nanozip] (unknown)
- From: Gerard <gslurink@xxxxxx>
- To: delphizip@xxxxxxxxxxxxx
- Date: Mon, 11 Nov 2002 09:38:44 +0200
Hi all,
For those who have not read it in the NanoZip list, this is the response of
Adem on my mail to both groups. He agreed to forward it to the DelphiZip list.
Gerard.
>Hi Gerard,
>
>I can not find a thing to object to in your post -not even to your
>comments about that NanoCommon should be made into a separate unit.
>I have thought about that quite a bit, it was possible but I'd have
>to move everything other than TNanoZip to a new unit. It definitely
>was possible, and it still is. And then TNanoZip would probably be
>a shell component (TNano?) ready for other compression methods.
>
>As far as other compression methods (other than cmStored and
>cmDefalted) are concerned, I'd be more than glad if some other
>samaritan came along and added them. I dont think I can muster
>up enough energy to do them myself, if for nothing else, I dont
>need any other methods in Zip/Unzip myself.
>
>And, once I was over Zip/Unzip stuff, I was planning to incorporate
>ReSource and UCL compressions at least and worked on them for a while
>as I like them both for different reasons, but each one (including
>zip) used different languages while doing basically the same.
>
>In an attempt to generalize, I chose container/content methaphor --I
>was sick of calling everything a file and do mental translation that
>they were really streams --one inside the other.
>
>And then, while I have a lot of respect for the zip format, there are
>a few things I'd like it to have done: Like writing the total size,
>content count, position of repository (central directory --even though
>it is not central at all) etc. at the beginning of the stream so that
>the receiving end would be able to make better decision about what to
>do with it. Further, I dont see why it does not compress the
>repositories and headers too --I suppose re-inserting the floppy
>was not sexy then ;-) But, I suppose this is what you have to endure
>with established standards. Ooops, I digressed.
>
>To cut it shorter: I for one would love see a simple interface where
>archive manipulation and compression engine(s) were separated (I
>never really understood why they had to do it all in one single code
>block); it was always a target at the back of my mind anyway;
>whether I would have had the time or the skills to do that is, of
>course, another matter.
>
>In short, if it could be done through a community effort I will
>be more than happy to be a part of it.
>
>Cheers,
>Adem
>
>PS: While I can live with non-pascal code, I'd like to let be
>known that I would much rather all code be in Pascal (not
>necessarily Delphi since there is also Kylix and FPK now).
>--- In nanozip@xxxx, Gerard <gslurink@xxxx> wrote:
> > Hi zippers,
> >
> > This mail is posted in the nanozip and in the delphizip newsgroup,
>and
> > addressed to all.
> > I am not writing in behalf of any group, this is a personal mail,
>for which
> > I am responsible, if there is anything you don't like, blame me,
>nobody
> > else !! (I assume you all are familiar with the persons I am
>referring in
> > this mail, if not make sure you' become familiar with their work !)
> >
> > First, Adem, congratulations on your v2.00 Alpha. It looks very
>clean. I
> > could read the code in 15 minutes and had practically no difficulty
>in
> > understanding it. That is a major achievement! ;-) I had no time to
>test it
> > yet, but I will.
> >
> > So what is this mail about ? (I'll try to be brief)
> >
> > We had a little discussion in the DelphiZip group on the zip
>format. (see
> >
> <//www.freelists.org/archives/delphizip)>//www.freelists.org/archives/delphizip)
> > My personal opinion is that the file format is lacking flexibility
>for new
> > uses and needs rewriting too much. I have new uses for compressed
>files and
> > compression in general (for which Jim and Mike are responsible by
>opening
> > new doors with the Virtual Treeview and Virtual Shell Tools :-)
> > I don't want to go in details on a new format but a (to me) major
>result
> > that came out of it was the proposal of James Turner that we could
>(should)
> > separate that compression/decompression code and (zip) archive
>manipulation
> > code.
> > Major advantages with such a modularity would be:
> >
> > Have compression/decompression code that can be used in a broader
>area
> > - for creating an own interface to the zip file
> > - for creating a new file format not compatible with zip but
>still using
> > all or some of its compression methods
> > - for other non standard use (ie not directly related to files)
> > If the archive manipulation code component is not sufficient for
>someone,
> > (s)he could replace it by another component without having to
>concern about
> > the (complex) compression
> > New compression methods can easily be added (ie rs compression,
>fast
> > extraction, ...)
> >
> > To my opinion all would benefit from such an approach.
> >
> > What to do ?
> >
> > - define a clean, small and simple interface between the two parts
> > - adapt existing code to it or write new code
> >
> > I realize that this can be a lot of work, and most of us have lots
>of other
> > things on their mind, but nevertheless I want to use this
>opportunity to
> > advocate this and try to point our noses into the same direction.
> > Most of us would love to have pure Pascal code, but since there is
>still a
> > lot of C code available in dll's I don't want to leave this out.
> > Following steps are not exclusive. They could be done parallel and
> > complement each other.
> >
> > DelphiZip
> > Unfortunately most of the work is done now by the dll's. It would
>be great
> > if a C programmer could create new dll's, which restrict themselves
>to
> > compression/decompression. With a simple Delphi wrapper, we would
>have all
> > current compression code available (as I am not a C programmer, I
>cannot do
> > this, I have no idea if this would be relative easy to do or would
>require
> > much work)
> > As DelphiZip provides a popular interface, it could be extended to
>take
> > over the functionality taken from the Dll's (I leave that up to
>Russell and
> > Roger)
> >
> > NanoZip
> > Separate NanoZipUnzip and NanoCommon. Make a small interface to
>Nanocommon
> > and concentrate all compression related code in it. Focus
>NanoZipUnzip on
> > the archive manipulations. Very much of the code is already that
>way, but
> > it still would require some work. (ie reversing the inclusion of
>nanocommon
> > in nanozipunzip ;(). This is of course up to Adem.
> >
> > InfoZip C source
> > To quote Eric: 'take the InfoZip C source files, and perhaps
>include them
> > as object files with very few changes. If we
> > could stay close to real InfoZip source, then we could continue to
>upgrade
> > our low-level zip code whenever InfoZip has a new release. This way
>we
> > could get support for new zip flavors, like deflate64. And we could
>get all
> > the security fixes that InfoZip gets'.
> > This would be work for a C programmer I guess, I would not know
>where to start
> >
> > New Pascal code
> > As most of us would prefer pure Pascal, this would be ideal (as
>Nanozip is
> > doing), but it would mean a lot of work.
> > I could do it if I have to, but at the moment I cannot make the
>time free
> > for it. I have however no doubt that if this proves to be the only
> > solution, the day will come that I start doing this.
> >
> >
> > So, the word is out. Before starting a discussion on a new format
>(for
> > which most likely a new group will be started) I am eager to hear
>your
> > reactions on this one.
> >
> >
> > Best regards,
> >
> > Gerard.
> >
> > PS, I am prepared to do not only talking but also actual coding
> >
> > PS2, forgive me my English, it's not my native language (Dutch it
>is)
Other related posts:
- » [delphizip] Fwd: [nanozip] (unknown)