[Fwd: Re: code compatibility]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: code compatibility]

Ken Treis-4
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