On 9 January 2013 20:54, Chris Muller <asqueaker at gmail.com> wrote:
> The best way is to test it is on your own machine.  Do you have access
> to the server?
>
> In /home/squeakmap is the server image -- Squeak3.8-6665-sm.image.
> Grab it and the changes as well as  "start.st" boots the server in the
> same directory (note a classic VM is required).  Running it on your
> localhost so can actually step through debugger in the server to make
> sure the change works.
>
> This is how I did the 2011 enhancements for the Release Editor and CSP
> improvements.
>
> Doing this will also bring to light how badly we really need to
> improve or replace SqueakMap's implementation, particularly on the
> server side.  :(   The domain model itself is actually pretty nice,
> but the machinery needs improvement.

I poked around a fair bit and can't figure out how anything actually
gets done. What would be really great is something somewhere saying
"these are the routes we accept, that define the API as HTTP sees it"
and that delegates implementation thereof to other objects. Kind've
what one would see in a Sinatra app, I guess:
https://github.com/lshift/rabbitmq-service-sinatra-sample/blob/master/rabbit.rb

But fair enough, Sinatra wasn't around when SqueakMap was born.

(While it'd be _nice_ to have SM vN+1 written in Smalltalk, if someone
knocked up a Sinatra/whatever app that ran on Heroku, I wouldn't
complain. Not a bit. Well, given the rash of JSON vulnerabilities
plaguing Ruby at the moment, maybe not Sinatra.)

frank