Today I threaded skt_server so it can service multiple clients at once. I've tested it to verify that it can service multiple people at once, and (mostly) clean up after itself. I need to think harder about how to make it service people with changing data streams as time goes on. That is one of the more complicated concurrency problems.
I wrote it today because I think we may soon approach where we will want to service multiple clients at once, and it is either this or forking processes. The netcode has actually been upgraded a bit since it was put into blobd. It is a little bit simplified (could stand to be more simplified probably) and can be easily told to run over unix sockets or TCP.
I am wondering if soon we might start encountering cases where the protocol is inadequate as well -- Davide's program is encouraging since it appears to maintain an arbitrarily long blob subscription from the server.
It occured to me that it may behoove me, depending on where I get with Compiz, to work on a proxy from our protocol to Tuio. Tom is programming against Tuio I assume, and it will be a little rough for him if we don't deliver that. I was kind of hoping that our mouse driver, if we made one, would consume Tuio as well -- although in the short term, it is probably simpler to implement it with our current protocol.
10 years ago