Latest Swazoo gives walkback on HttpServer>>shutDown

I've downloaded the lastes Swazoo port that Esteban pointed me to and find
that it seems to have some missing methods.

Specifically I did an HttpServer shutDown and I got a DNU on SpEnvironment
for Message selector: #removeShutdownActionFor: arguments: #(HTTPServer)

And it appears that SpEnvironment doesn't implement that message.

I had a quick look but SpEnvironment looks wierd - I see #addImageShutdownTask:for:
and it looks odd to me, doesn't do what the comment says - I think its supposed
to interact with #imageShutdownTaskBlocks? I'm guessing as I've never really
understand the architecture of Swazoo (althougth I'm getting a bit closer).


Tim

Tim M escribió:
> I've downloaded the lastes Swazoo port that Esteban pointed me to and
> find that it seems to have some missing methods.
>
> Specifically I did an HttpServer shutDown and I got a DNU on
> SpEnvironment for Message selector: #removeShutdownActionFor: arguments:
> #(HTTPServer)
>
> And it appears that SpEnvironment doesn't implement that message.

You can safely, and dirty, replace HTTPServer>>shutDown by:


shutDown
        "HTTPServer shutDown"
        self allInstances do: [:each | each stop].



> I had a quick look but SpEnvironment looks wierd - I see
> #addImageShutdownTask:for: and it looks odd to me, doesn't do what the
> comment says - I think its supposed to interact with
> #imageShutdownTaskBlocks? I'm guessing as I've never really understand
> the architecture of Swazoo (althougth I'm getting a bit closer).

The comments of SPort, and Swazoo in part, *are* weird, and I didn't
like the tone of them*. But the port is initial and in the "Make it
work" phase. Most comments are outdated, when Sport was, probably, named
differently, that's why the OSk prefix in many class names in the comments."

*I.e, the method comments starts showing which object the method return:
SpSocket>>getSocketName
        "^an OSkSocketAddress
        see: man getsockname
        I return my local socket address which may be any subclass of
        OSkSocketAddress."


Best regards,

--
Esteban.

Hi Esteban,

> You can safely, and dirty, replace HTTPServer>>shutDown by:
> ...


Yes but wouldn't the better solution be to add the missing method to SpEnvironment?
(Even if its blank for now?)

Are you the only person porting Sport to Dolphin? It seems like what the
code is trying to do is make it possible to shutdown your image (and stop
the server) and then when you restart (it restarts the server). It shouldn't
be that hard to fix that portion should it?

If I've understood some of the stuff I've read so far - is this to allow
a platform neutral set of services that we can all build off? (Which seems
like an a great goal).

I admire your stab at orting some of this stuff properly. Was it difficult
porting Swazoo to Dolphin using this?

It just seems that always we end up with half ported stuff on Dolphin and
its annoying - a great environment with half finished libraries that everyone
else takes for granted.

I ran the latest port you sent to me through the Dolphin browseUnimplemented
browser ande there is now a different list of supsicious methods that aren't
implemented.
(e.g. SpTringUtilities>>bytes: subjectBytes asStringUsingEncodingNames: anEncodingName

        ^subjectBytes asStringEncoding: anEncodingName  << asStringEncoding:)

How can I help get this sorted out once and for all? Maybe I can help in
a small capacity and contribute a few fixes.

Of course we've been down this rathole before - its hard becuase we suffer
from no common repository we can jointly check into and make fixes to. Sigh...
we'll get there but its frsutrating.

Tim

Tim M escribió:
> Hi Esteban,
>
>> You can safely, and dirty, replace HTTPServer>>shutDown by:
>> ...

> Yes but wouldn't the better solution be to add the missing method to
> SpEnvironment? (Even if its blank for now?)

Yes, indeed that would be the solution, my suggestion was a fast patch.

> Are you the only person porting Sport to Dolphin?

Yes.

> It seems like what the
> code is trying to do is make it possible to shutdown your image (and
> stop the server) and then when you restart (it restarts the server). It
> shouldn't be that hard to fix that portion should it?

Yes, it's easy to fix that portion.

> If I've understood some of the stuff I've read so far - is this to allow
> a platform neutral set of services that we can all build off? (Which
> seems like an a great goal).

Yes, but my position at this is contradictory, I like it because some
frameworks can/will be ported with ease in the future, but I like native
and coupled solutions.
But, for the case of Swazoo is the only alternative given that all the
ports came from the community (mostly VW), and from people who made it
in their spare time.

> I admire your stab at orting some of this stuff properly. Was it
> difficult porting Swazoo to Dolphin using this?

Not so. However Sport was ported with the intention of having the
minimum necessary to make Swazoo work (and are some missing items, as
the ones you marked before), and is incomplete, the Sport "mentor",
Bruce Badger, have some other stuff working based on it, as the
PostgreSQL driver.

To help with its completenes, I added test cases to it, to know how it
should behave, because I didn't had anything working to test it with
(kind of blind development).

The idea is that SPort get retrofitted based on user needs and feedback.
When I did this port, I adapted some methods in SpSocket, because
Dolphin uses a different abstraction for server and client sockets,
those modifications weren't introduced in the Sport mainstream codebase yet.

> It just seems that always we end up with half ported stuff on Dolphin
> and its annoying - a great environment with half finished libraries that
> everyone else takes for granted.

It's sad, but is that way.
Our community is effort/ad honorem based, and that means generating
libraries in the spare time.
Even the folks at Object Arts seems to work with a lot of effort to
respond to users demand, and fortunately they do it well.
With no external sponsors nor investment on this, not too much can be
done with predictable release dates.

> I ran the latest port you sent to me through the Dolphin
> browseUnimplemented browser ande there is now a different list of
> supsicious methods that aren't implemented.
> (e.g. SpTringUtilities>>bytes: subjectBytes asStringUsingEncodingNames:
> anEncodingName
>     ^subjectBytes asStringEncoding: anEncodingName  << asStringEncoding:)


> How can I help get this sorted out once and for all? Maybe I can help in
> a small capacity and contribute a few fixes.

Yes, you can! Send it to me, and I'll upload it to the page.

> Of course we've been down this rathole before - its hard becuase we
> suffer from no common repository we can jointly check into and make
> fixes to.

Yes, at least we can install a issue tracking system, Udo said he will
collaborate with the hosting and the mysql database, so is just a matter
of dedicating a couple of hours to set it up.

> Sigh... we'll get there but its frsutrating.

true & true :-)

I would like to see a Dolphin roadmap somewhere.
At least one with lying release dates, as the VAST 7 roadmap ;-)


Best regards,

--
Esteban.

Hi Esteban,

- I've sent you an email on your eXXXXX gmail account with some .stp files
with some small changes I noticed.


Tim