[squeak-dev] SqueakMap server

Frank Shearar frank.shearar at gmail.com
Tue Apr 15 07:47:11 UTC 2014


On 15 April 2014 08:34, Göran Krampe <goran at krampe.se> wrote:
> Hi guys!
>
> Just FYI, I don't track all of squeak-dev (no time), but I can promise to
> read and reply (to questions) on all threads mentioning SqueakMap in the
> subject.
>
> Chris Muller knows SM in-and-out I would say and yes, the web UI is
> separated from the domain model. In fact, the *exact same* domain model is
> used in your image when you use SMLoader (or its cousins), SMLoader is just
> a "different UI" on top of it.
>
> That was indeed one of the *key design points* that unfortunately was never
> really understood by large parts of the community - my guess at least!
>
> The idea was always that we would maintain a map together, the domain model,
> and we could operate on it *in our own images*. This means that say,
> iterating over all packages and selecting a subset of them and installing
> them - that is trivially done in a few lines of code.
>
> Frank: There is "no" client-server protocol to speak of. The client just
> does a HTTP GET to check the transaction counter of the domain model at the
> SqueakMap server - if its higher than the local counter - we do another GET
> to fetch a gzipped ImageSegment of the domain model.

HTTP GET _is_ a client/server API. SM's protocol isn't documented, and
I didn't have the time to figure out the http framework, which you
mention below so I'll just continue there...

> ...anyway, if anyone has any questions, feel free to ask and I will do my
> best to answer.
>
> SIDENOTE: The web UI really sucks code wise. It was written using HttpView,
> my own web layer which actually inspired Avi in some ways when he did
> Seaside. Today I would personally just clone off the UI of SmalltalkHub
> (written all in Amber) or write a new one in Seaside or some other proper
> web layer. Both those approaches need some attention to "bookmarkable URLs
> though", SM is very restful which is IMHO very important to make things
> googlable. And oh, for any restful API I would use Seaside-REST, its really
> nice and I use it now in a project at 3DICC.

I guess maybe I should have been more precise in what I was
complaining about. I don't know much about SM's domain model, and I
don't care: that's an implementation detail of the service. What I
care about is the service's API. So if it's possible to take SM's
existing domain model, and SM's existing data, and just replace the
HttpView stuff with some new API (that's actually documented!), then
great! Less work for Chris Cunnington to do!

The main point to my reply was that I'd like to see Chris Cunnington
supported in his experiments around SM, and I'd like to see Chris
Muller sleeping easily at night knowing that our core infrastructure
isn't going to be ripped apart during said experiments.

frank

> regards, Göran


More information about the Squeak-dev mailing list