On 03.10.2007, at 09:59, Gustaf Neumann wrote: > It should be possible to do async i/o on the raw channel > (maybe rename "ns_conn channel" to "ns_conn rawchannel"), call > ns_write from the readable/writable callbacks and provide > an argument to ns_write for the channel. Based on that it should be > possible to provide a fcopy based on ns_write with little effort.
Possible, but for what purpose? Why not just call ns_write in the first place? If we really want to expose the complete protocol support (chunking, encryption, compression, whatever) that server is providing, to a Tcl channel, then you need the..... > > This does not address the problem of needing the Conn structure. Exactly. You need the Conn structure.... > An option > might be to provide essentially a deep copy of conn and pass this in > the custom channel. which is (may be?) a lot of plumbing... > > We discussed something very similar some time ago in context of the > writer > threads, where a more flexible model on passing control between > spooling > and worker threads sounds interesting (e.g. checking on file uploads > the quota via database, do spooling, do postprocessing in workter > thread). Indeed we did. I was not that much underway in this area of code so I cannot comment if this is possible or not and if yes what level of effort is needed to make this happen. To me, the most important thing is: usage. We cook what we need to eat, at least we are doing that (we're commercial company living from what we sell). So far, my main concern was how to get the server doing something *else* beside serving HTTP reqests (which it does excellent anyway) so I made that [ns_conn chan] short-circuit in no-time getting much for no-work. Of course a nice Tcl-channel wrapper over the Conn, utilizing all that's below is a nice-to-have feature, but at the moment we (I speak about myself, selfishly) do not need such thing. If somebody does, I may help a little with the implementation but I cannot lead it (constant lack of resources!). Cheers, Zoran ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
