[hunchentoot-devel] Re: Current development

[Lars Rune Nøstdal]

Lars Rune Nøstdal wrote:
> Lars Rune Nøstdal wrote:
>> Bjørn Nordbø wrote:
>>>
>>> On 2008-06-10, at 9:00 PM, Lars Rune Nøstdal wrote:
>>>>
>>>> Ok. Yeah, maybe a Comet module for HT would be of interest. I really 
>>>> hate promising things, but I might give it a try; I mean, attempt 
>>>> make it modularized and not hardwired into SymbolicWeb .... x)
>>>
>>>
>>> It's interesting to read about your efforts as we discussed Comet
>>> as a way to implement real time streaming to our Ajaxy mobile
>>> application yesterday.  In fact I started writing a Comet module
>>> for it almost a year ago (only a naive test), but the interest
>>> vaned as the only mobile device that worked with it was the
>>> iPhone.
>>>
>>> But I was just thinking of looking at it again as the situation
>>> on the client side may have improved since then.  And, of course,
>>> the iPhone is finally coming to Norway.
>>>
>>> Anyway, my point is that since there are two developers in Norway
>>> that have interest in Hunchentoot/Comet, there has to be hundreds
>>> if not thousands! worldwide. :-)
>>>
>>> --Bjørn Nordbø
>>>
>>>
>>
>> ..hehe x)
>>
>> Ok, way early, but something like this:
>> http://paste.lisp.org/display/62069 
> 
> 
> ..yeah, bit too early. I'll try again later, but the general idea is 
> something like what's seen there..
> 
> ..sleep now..
> 

.. Ok, back again x) .. I gave it a try but I'll stick with the old thread + wait-condition method for now. It works well; the only problem is that it does not scale, so I'll work on something else for SW than scalability for a while.

There are too many changes needed to pull this off properly and I think it'll basically end up a complete rewrite of HT instead of just an addon/module for it. I can try to describe some of the problems even though many of you are probably already aware of some of them.

A major problem is global variables. I suggest that instead of having things like *REPLY* *REQUEST* *SERVER* and *HUNCHENTOOT-STREAM*, a concept of or class ROUND-TRIP is added:

  (defclass round-trip ()
   ((request)
    (response)
    (socket)
    (stream)
    (server)
    (session)))


..and that for, perhaps, backward compatibility things like this would do:

  (define-symbol-macro *session* (session-of *round-trip*))


This would "close over" a single round-trip cycle (request->response) and maintain everything in one place so it can be passed around easily ("response is to be delayed, thus end this thread and pass it to another thread for execution later!").

Also, this means handling of a round-trip cycle cannot be hardcoded into a single function/method or into a single path of execution (a single thread). Using things like UNWIND-PROTECT makes the path of execution static; "when thread ends close the stream" (but we, well I, don't want this!). 

I think things needs to be more split up for this to happen; this is hard to get just right.

I recall removal of globals mentioned on this list for the new HT, and to avoid stepping on peoples toes and wasting time I'll wait around a bit. It also seems things are moving from DEFUN to DEFMETHOD which would enable things to be more split up by the user.

-- 
Lars Rune Nøstdal
http://nostdal.org/