Version Support and Statistics Gathering
Locked
Version Support and Statistics Gathering
 
|
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. 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. It would also provide some window into the overall picture of what Squeak versions are out there and being used. I suspect this would be useful information for many of us. Would anyone likely object to this information being sent? Again all I'm thinking of at the moment is the Image version, the VM version, and the platform. Ken |
signature.asc (197 bytes)
Re: Version Support and Statistics Gathering
|
|
Re: Version Support and Statistics Gathering
|
|
Re: Version Support and Statistics Gathering
|
|
In reply to this post by Göran Krampe
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 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 |
| Free forum by Nabble | Edit this page |