Hello James, What I would be concerned about the below is that running with your opinion we would be saying to Nanozip author - we like your i/o routines but the rest we are not interested in. This is the delicate art of negotiation so we would need to be careful how we approach this aspect. JT> So far as NanoZip is concerned, I have yet to form an opinion on its overall JT> design, but if the author is agreeable, it could serve as the source for JT> implementing a pure compression/decompression engine. A zip wrapper for such JT> an engine would be very useful but the advantage of structuring things this JT> way is that if someone wants to implement a new archive format (e.g. Z++) JT> they should be able to do so without any great difficulty. Also, if someone JT> needs to work with, say, memory streams they could ignore the zip wrapper And the below... JT> and work purely with the compression/decompression engine. Surely, if major JT> changes/new code is under discussion, this should be the direction we move JT> in - ie create flexible and modular code. If it were possible to satisfy everyone then Nanozip may very well want to move in that direction as well in any case? JT> Well, that's my opinion - I'm sure that plenty will disagree. Maybe not ;-) JT> -- James Turner Lets just wait and see what Russell and Roger come back with before we expand on this topic further. -- Regards, Alistair+