Hi all, I mentioned in an email earlier that I have a rough prototype of socket rendering working via oiio into iv. The purpose of this email is that I am having trouble making the socket rendering model fit within the oiio "open/read/close" ImageInput model. At first glance they may seem compatible -- open a socket connection, read the tile data, close the connection -- but there are serious problems lurking once you dig deeper.
Consider the typical socket rendering scenario: 1. start a listening server 2. on connect from client, create a new image buffer 3. read tiles from client into buffer 4. close connection 5. repeat steps 3-4 (possibly at the same time) In this scenario, there is a single server listening on another thread all of the time: before, after, and during a socket render. The server handles all incoming connections and creates the SocketInput instances, which handle the remainder of the data streaming for that connection. In the "open/read/close" model, on the other hand, each SocketInput acts as its own server, valid for a single connection only. What this means is that a new SocketInput must be created *prior* to each new render performed. I'm very opposed to placing this burden on the user, but performing the convoluted code trickery in IV required to lift that burden is not attractive either. There is other fallout as well. For example, in the ideal/typical scenario, when the server accepts a connection from a renderer, the first thing it does is get the filename of the image about to be sent. though the image does not exist on disk, the file name serves both as a unique handle in the case of multiple simultaneous renders, and as something useful to display in IV to identify the image. Since the name can't be changed once the ImageInput is created, we would either force the user to enter in a new name prior to each render or use the same name for all socket images. So, what is the best solution? Perhaps we could abstract the server model down to an "image generator": a function that runs on a separate thread and generates new ImageInput instances. plugins could register these generator functions, if they apply. Are there any other file formats that would benefit from some kind of abstracted server model? I'm really not sure what else could benefit from such a thing, but I'm trying to work within the plugin framework to avoid treating sockets as a special case. Any guidance on this would be greatly appreciated. -chad _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
