On Mon, Jul 22, 2002 at 04:31:51PM +1000, Martin Pool wrote: > On 21 Jul 2002, jw schultz <[EMAIL PROTECTED]> wrote: > > > That is the better approach. Use I/O routines so most > > processing can be "while (get_input()) { process(); send_output()}" > > Then the I/O routines can be defined accorinding to platform. > > while 1: > examine fd > if input available: > read input packet > if a reply: > dispatch to whoever was waiting for that reply > else if a request: > dispatch to whoever handles that request > if ready for output: > send next output packet from queue
I'm confusing subthreads here but the my psuedo snippit is how a given component in the pipeline might work and your little snippit is one way of connecting the components. > > You could do this with blocking IO, nonblocking, or even potentially > threads, if you were on W32 (and drunk) and threads seemed like a > really good idea. > > > If a platform has some special type of file it would be > > responsible for converting to/from a multi-segment > > bytestream. > > Yes. > > > It would be possible to build a server that didn't depend on > > local filesystem semantics and so could support an attribute > > superset. But that is out of scope for now. > > One idea that both Samba and Subversion have is a virtual filesystem > layer that mediates access to the local filesystem. The default > implementation maps straight down to regular IO, but you could plug in > different implementations. For example, you might want to store > everything in one big database, so that the server can hold backup > files with the clients semantics regardless of its native filesystem. Get the protocol right and have clearly defined components and we can do almost anything we want on the server. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html