I have not had any problems using WinZip with an archive that contains
Squeak code at the front of it.  So I don't think that physically having
something there will hurt anything.

Perhaps the approach should be to change the Squeak file-in mechanism with
this capability in mind.  You could make it so that your file-in code has
access the relevant information without needing to do hacky things like
Craig had to do (ie. have "installer" variable bound to the installer, give
access to the directory and file name that you're filing in, provide some
framework for making it simple to access the members of a zip file, etc).

I think this would be very useful to have in conjunction with a SAR
specification for what a Squeak ARchive should actually contain (naming
conventions, etc).  But, it would also be generally useful if someone
needed/wanted to distribute something in a zip file that didn't have a
standard SAR layout.

So, I'd say let's make the file-in mechanism a little more intelligent to
accomodate zip archives and that would benefit anyone wanting to distribute
Squeak stuff in an easily loadable zip file.  BTW, I've often wanted to
access the file name in a file-in...so I think there are some other benefits
to be had in the file-in process in general.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Ned
> Konz
> Sent: Wednesday, November 20, 2002 2:18 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: SAR
>
>
> On Tuesday 19 November 2002 09:50 pm, Craig Latta wrote:
>
> > > You know, I started out having SARs [be completely
> > > self-contained].
> > >
> > > But then I was discouraged by some discussion on the list by
> > > people who thought that wasn't an important feature.
> >
> > 	Wow, I missed that one... I find that feature to be extremely
> > useful.
> >
> > 	I'm just curious... did this discussion take place before or after
> > 12 August, when I released/announced my self-installing thingie?
> > And when did you start developing SAR?
>
> The discussion was after that time (around a month ago), because your
> installer was mentioned and I looked at it (after I'd come up with
> something similar on my own, unfortunately).
>
> http://aspn.activestate.com/ASPN/Mail/Message/1404843
>
> It looks like you were part of the discussion <g>...
>
> > > Part of the problem, of course, is that you have to do something
> > > like Craig did to actually find the zip stream (he went up the
> > > caller stack...).
> >
> > 	What's the problem?
>
> No huge problem; it is sensitive to the fact that the stream itself is
> doing the fileIn (which is the case in Squeak so far but could
> change).
>
> But there are some complications:
>
> I'd like these to be valid Zip files (i.e. with correct member offsets
> in the central directory) so we can use the usual zip tools for
> validation and checking on them. So just sticking a stub on the front
> of an existing zip file won't cut it.
>
> There aren't any interactive tools for writing valid zips with
> prepended data that I know of, other than my ArchiveViewer. And the
> ArchiveViewer can only prepend data from a file, so I'd like to have
> a fixed stub to ease creating these things by hand.
>
> Another reason for a fixed stub is to make the actual mechanics of
> extraction visible to standard (non-Squeak) tools. The SAR format
> puts everything into files, which lets you use any zip tool that you
> want to construct them.
>
> With a fixed stub, the extraction of individual members wouldn't be in
> the stub, it'd be in the preamble and postscript as it is now with
> SARs.
>
> And I'd like to be able to install these SARs both by file-in and by
> the SARInstaller (which also can handle change-set renaming,
> registration with DVS, etc.). So I'd like the stub to be responsible
> for filing in the preamble and postscript, but these expect to have
> "self" set to an installer. Which doesn't work with the stock
> PositionableStream>>fileInAnnouncing: because self is set to nil. So
> I'd have to load some methods to allow this, which I'd then have to
> delete from the current change set. These methods could be in a
> compressed member that's loaded first by the stub, though.
>
> > > ...the code to do the installs would have to be added to each
> > > SAR, and can't be compressed itself (it has to be vanilla
> > > Smalltalk code).
> >
> > 	Is it big enough to matter?
>
> It might be in excess of 500 bytes. I'd have to play with it a bit to
> see.
>
> > > However, since most SARs will be appearing in SqueakMap, it seems
> > > like we should probably just install the SARInstaller stuff (it's
> > > small, anyway) along with SqueakMap.
> >
> > 	I still like the idea of having an installer that's completely
> > self-contained (or rather, it only depends on parts of the system
> > which are decades old :).
>
> I didn't write the Zip stuff until Feb 2001, apparently. Though it
> seems that I did it earlier; I'm not sure. The GZip stuff only dates
> back to late 1998, as far as I can tell.
>
> The idea is still appealing; I may still add it to the SARBuilder
> package. But I'm not sure that it's worth the effort.
>
> --
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>
>