On 20 April 2012 16:04, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 20 Apr 2012, at 15:29, Igor Stasenko wrote:
On 20 April 2012 13:46, Sven Van Caekenberghe <sven@beta9.be> wrote:
JB,
On 19 Apr 2012, at 19:19, jb wrote:
i just downloaded 1.4, installed seaside using the  configuration browser and everything went great.
i added a Zinc server adapator in the Seaside control panel and its all working fine.
but then i went to set up the comet/streaming server and im kind of stumped. Â there is only one kind of Zinc server adapter and when i try to use it for the comet examples they all complain about needing a server that supports streaming.
what do i need to do to get a streaming server for the comet applications?
thanks in advance!
jb
As author of Zinc I would like to help you, but I don't know what functionality is expected from a server that 'supports streaming'. If you or someone else could refer me to code and/or documentation that describes what should be there, maybe I can try to help you.
If you remember we discussed that before. Mainly it  is about getting a stream for contents from HTTP response. i.e. something like:
'http://x.y.z' asUrl getContents where you get all contents at once, versus
'http://x.y.z' asUrl getContentStream where you get only a stream and can read incrementally from it.
I don't really remember ;-)
But I think I more or less begin to understand: some Seaside (client) code wants to access the underlying socket stream to the client ? For reading and/or for writing ? Inside or outside an existing request/response ? Inside or outside the dynamic context of the request handling ?
In any case, this seems dangerous.
Can I read something about the intended use of this somewhere ? Example usage code ?
Yes, you can look at my hacky implementation of SCouchDB, where i partially implemented the HTTP protocol and use streams for content. See http://www.squeaksource.com/SCouchDB there i use a stream to directly parse the input without waiting all data to arrive. This is also useful for up/downloading huge files, where content size can easily surpass the amount of RAM available.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.