does anyone have ANY thoughts on this? i'm not really sure how best to proceed at this point. i've made a lot of progress on this and it'd be a shame for it to go to waste.
-chad On Jun 9, 2012, at 12:50 AM, Chad Dombrova wrote: > 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
