I think Janko also meant to send this to the list.
Hi Ken
Ken Treis wrote:
> Steve -- good thoughts. My time is somewhat limited right now, but
> I've been chipping away at some of these things in spare moments. My
> project deadlines are just pushing me towards other areas of Swazoo
> (thus my recent work has been on integration of CacheControl,
> SwazooActivePages, etc.).
>
> Here's where I think I'd like to see things go WRT your comments:
>
> HTTPServer: We'll move the socket accept code into SwazooSocket. I'd
> also like to make the master server socket be an instance variable of
> HTTPServer so that we don't have to pass it around in awkwardly-named
> messages like #interactWithNewConnectionOver: (would #acceptConnection
> be better?).
I agree completely here :)
> The only ramifications I can see are that the socket has to be managed
> properly if ever a live HTTPServer is saved in an image snapshot. On
> my server, I don't do that, but I think Janko does. Do you, Steve?
> Janko, speak up. :)
Yes, that's a good thing to add. I did that in one of my versions
loooong ago. I would put snapshoot event handling in dialect specific
package and only provide hooks in core. Start/stop (which by the way
don't work ok right now) of entire Swazoo and any Site will probably
suffice as hooks.
I think we need to introduce start/stop into Resources too. In order to
start/stop aSite, some resources also need to know about that start/stop
event (to cleanup caches for instances, to initialize, to save someting
etc.)
>
>
> HTTPConnection: I think a short timeout on the reading of a message
> header (combined with a longer timeout on the reading of the entity)
> should be sufficient. The #interruptWith: block is a kludge, to say
> the least, and all it does is implement a timeout on the combined
> reading of the message and header. There is a very rudimentary start
> of support for this in SwazooSocket, but it wiil probably also require
> some support in HTTPConnection (i.e., HTTPConnection will have to know
> the header / entity timeouts and send SwazooSocket>>#read:timeout:
> repeatedly until the header or entity arrives). This would eliminate
> the need for a low-priority "cleanup" process IMHO, but we'd have to
> verify that empirically.
I think a keeper process will be need sooner or later. For hardening
Swazoo I'm thinking of using it for changing priority of long-lived
requests (to reduce a endless loop inpact for instance), to timeout
whole connection, to timeout bogus requests etc etc.
I'm also proposing to introduce a connection state, that is, in which
state is connection at that moment. States that come into my mind are:
#idle #receiving #processing #sending
States and timestamps will then help keeper process to decide what to do
with a connection.
>
> HTTPPost: What does the spec say on decoding? I haven't looked at it
> in a while. Whatever it takes to comply with the spec, let's do that.
>
> Resources: I'm fine with the backpointer, but I haven't had a driving
> need for it. I'll try to integrate your code soon. Can you tell me
> which methods are most significantly affected?
I vote for backpointers too :)
JAnko
Locked
