Hi Brian and all!
Ned Konz ned@bike-nomad.com wrote:
Last night I attended (and spoke at) the Seattle Perl User's Group meeting. Also in attendance were Brian Ingerson and Michael Schwern of Portland.
Cool!
Before the meeting, I had a chance to talk with Brian Ingerson (more below). He's working on an interesting and relevant project.
<sidelight> Though not the subject of the main talk, I soon found myself answering questions about Squeak (and doing some promotion <g>). There were several people in the crowd who were interested.
After the meeting, we went to a pub for a beer or two. There I demonstrated Squeak to several interested people (note to self: get a good demo together to show to programmers).
Smart move Ned, hit them while they are intoxicated. :-)
I think that with the right kind of introduction and modular system we could convert a bunch of Perl programmers.
</sidelight>
Anyway, one of the interesting ideas that came from this was from Brian.
He's working on an alternative to CPAN (the popular Perl repository/mirror/registry system). I'll let him describe what he's doing (I just sent him an invitation to join this list), but in summary he's working on a repository/registry system with metadata. Currently he's making it handle Perl and Ruby; there's some interest in Python from Michael Schwern. Especially since we're also evolving the SqueakMap system, it might be useful to talk with him about joining SqueakMap with FreePAN in some way. This would provide a single set of mirrored repositories covering all our languages, with immediate exposure to the "scripting language" community.
Sounds of course interesting.
And it sounds like some of Göran's excellent work could be used with FreePAN (or at least inform it).
Ok.
Anyway, I thought I'd open this up to discussion, as it's a timely and relevant issue for both our communities.
Ideas?
Well, to let you know where I am right now:
Currently I am writing version 1.1 of SM which involves a whole bunch of changes. The current 1.0x version is quite simplistic in many ways, but that was *by design* to get it up and running and to make it easily accepted.
Basically SqueakMap is a metadata-catalog with "smart" incremental update-mechanism based on "transactions". It also has a domainmodel which is identical on the client and the server - in fact, in SM1.1 the client and server will more or less be equal entities.
Then on top of the domain model we have a bunch of slick Morphic UIs and a web UI that is darn ugly, but that was also *by design*. Next version will be a bit prettier but on the other hand next version will not really need it anymore (currently some operations can only be done trough the web UI) so people will not care.
Currently SM has a master and all the clients are just synched slave mirrors. In SM1.1 the "slave" mirrors will be able to have additional local content visibile to them and their slave mirrors. It will also mean that changes in the map can be applied locally and then "published" up the tree of servers.
Important notes:
- SqueakMap is completely written in Squeak. Not a single line of anything else. - The protocol between servers and clients is dead simple on top of http. I like to keep things as small as necessary - no need for SOAP or XML. I just use very simple commands in http requests and use Squeak as "language" for transmitting structures. - The domain model (both client and server) maintains a logfile with all the transactions logged a "evals" (or do-its as we Smalltalkers call them). This means the domain (server or client) is easily reloaded/recovered from the log and the server uses the logfile when calculating the incremental update to send to a client.
Anyway, I have no idea if this was interesting to read for anyone. ;-)
regards, Göran