On Mon, 2010-04-05 at 09:39 +0200, Göran Krampe wrote:
> Hi!
> 
> Ken Causey wrote:
> > For some reason I was thinking earlier today about the recent issues
> > with SqueakMap and Göran's very reasonable desire to continue to support
> > versions all the way back to 3.8 (IIRC).  I certainly agree that this is
> > a good idea in general but there are costs involved and compromises that
> > have to be made to support multiple versions, costs that increase as we
> > release new versions.
> 
> Yes, but actually, for the moment - the cost is not high. It occurred to 
> me that we can *add* another serialization method and still keep the 
> current one "on the side". Then, depending on your client code it will 
> use the appropriate request to fetch the map.
> 
> > I think we should consider ways of measuring the actual need for
> > supporting past versions.  It has occurred to me that it would probably
> > not be too difficult to have SqueakMap send the Squeak version info
> > (platform and VM version also?) to the SqueakMap server, say each time
> > the map is updated.  SqueakMap could record this information on the
> > server and as it accumulates we could start to get some picture
> > regarding, at least, the use of SqueakMap in the various Squeak
> > versions.
> 
> Now, the recording you are talking about is indeed interesting in itself 
> though. On the other hand, soonish I hope we will move to a distributed 
> model of the map - and then this type of gathering will not really be 
> that easy, I think.
> 
> regards, Göran

Why would it be harder under a distributed model?  (I take the term
distributed model to mean multiple SqueakMap servers any of which may be
used to distribute the map, packages, etc. independently.)

When the client asks the server for an update to the map couldn't
additional arguments be added specifying the version info?  Sure it
would then be stored locally for each server, but it could be compiled
when desired.

The data would of course not be a one-to-one map to existing
image/vm/platform instances but instead map to some definition of a
SqueakMap usage level.  This is useful information in and of itself in
my opinion, there may be many, for example, Scratch images out there,
but if they aren't accessing SqueakMap it's not relevant to the idea of
whether SqueakMap (and perhaps related infrastructure) needs to continue
to support them on a first-class level.

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100405/27d5040a/attachment.pgp