Re: [Pharo-project] 1.4, seaside, comet, how to get it working
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. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
On 20 Apr 2012, at 15:29, Igor Stasenko wrote: On 20 April 2012 13:46, Sven Van Caekenberghe s...@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 ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill -- Best regards, Igor Stasenko.
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
On 20 April 2012 16:04, Sven Van Caekenberghe s...@beta9.be wrote: On 20 Apr 2012, at 15:29, Igor Stasenko wrote: On 20 April 2012 13:46, Sven Van Caekenberghe s...@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.
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
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 ? For writing only, see WAListenerAdaptor in Seaside-Adaptors-Comanche. WAListenerAdaptor is a custom server implementation that uses Kom for some utility functions. It enables Seaside to directly write to the Socket and to keep the response open as longs as Seaside needs (to stream contents). Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
On 20 Apr 2012, at 17:47, Igor Stasenko wrote: 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. OK, I will have a look, but I don't think that will answer my questions. Zn already nicely handles streaming through its ZnStreamingEntity object: it captures all metadata and a reference to the stream and leaves it up to its user to drain it or to fill it. And indeed, that is the way to handle things like large uploads or downloads while not taking everything in memory at once. Sven
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
On 20 Apr 2012, at 18:03, Lukas Renggli wrote: 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 ? For writing only, see WAListenerAdaptor in Seaside-Adaptors-Comanche. WAListenerAdaptor is a custom server implementation that uses Kom for some utility functions. It enables Seaside to directly write to the Socket and to keep the response open as longs as Seaside needs (to stream contents). Lukas OK, thanks Lukas, I will have a look. Sven
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
On 20 April 2012 18:41, Sven Van Caekenberghe s...@beta9.be wrote: On 20 Apr 2012, at 17:47, Igor Stasenko wrote: 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. OK, I will have a look, but I don't think that will answer my questions. Zn already nicely handles streaming through its ZnStreamingEntity object: it captures all metadata and a reference to the stream and leaves it up to its user to drain it or to fill it. And indeed, that is the way to handle things like large uploads or downloads while not taking everything in memory at once. Ah, so its already there.. less to worry about Sven -- Best regards, Igor Stasenko.
