Putting a web front end on an embedded device
Hi All: Sorry in advance if this has been asked before, I've only been looking at modules for a couple of weeks, but I checked everywhere I could think of and I'm still looking for some answers. I have a relatively high powered device on a network with a TCP debug/status port. Users can telnet to this port, enter their credentials, and tell the device to start spewing data at them. This particular device outputs XML. Multiple users can connect to the device simultaneously and each user has a different profile (list of events they subscribe to). I'd like to put an apache web server on the network and code up a module to create a web front end. So far, this is what I'm thinking: - User enters credentials, the module opens a socket to the device, passes along credentials, and holds the request_rec connection to the browser open (comet style streaming). - Device passes back some administrative preamble and starts to stream data to the module, the module passes the chunks of xml to a filter which applies an XSLT transform to JS script chunks and the browser updates If this is a plausible direction to go in, then my issue comes about when a user wants to change their profile. On the browser, I open a 'back door' XmlHttpRequest and send it, along with the session ID of the user. The module must then find that session's connection to the device, signal the module somehow, and tell it to pass the client request along to the device. How would you guys go about coordinating the IPC here? A socket to the device and a listening socket to listen for subscription changes on a select? Seems like a lot of overhead per user, plus I'd have to coordinate the listening sockets to be on unique ports for each client, which would require perhaps shared memory or the server pool. Perhaps shared memory and signals? This is very MPM specific, though. It would also be nice to move from a prefork MPM to the Event MPM to support more simultaneous users in the future without a total overhaul. Any input is appreciated. Thanks! -Chris
Putting a web front end on an embedded device
Hi All: Sorry in advance if this has been asked before, I've only been looking at modules for a couple of weeks, but I checked everywhere I could think of and I'm still looking for some answers. I have a relatively high powered device on a network with a TCP debug/status port. Users can telnet to this port, enter their credentials, and tell the device to start spewing data at them. This particular device outputs XML. Multiple users can connect to the device simultaneously and each user has a different profile (list of events they subscribe to). Naturally, I'd like to put an apache web server on the network so I can support a web front end. So far, this is what I'm thinking: - User enters credentials, the module opens a socket to the device, passes along credentials, and holds the request_rec connection to the browser open (comet style streaming). - Device passes back some administrative preamble and starts to stream data to the module - the module passes the chunks of xml to a filter which applies an XSLT transform to JS script chunks and the browser updates If this is a plausible direction to go in, then my issue comes about when a user wants to change their profile. On the browser, I open a 'back door' XmlHttpRequest and send it, along with the session ID of the user. The module must then find the session's connection to the device, signal the module somehow, and tell it to pass the client request along to the device. How would you guys go about coordinating the IPC here? A socket to the device and a listening socket to listen for subscription changes on a select? Seems like a lot of overhead per user, plus I'd have to coordinate the listening sockets to be on unique ports for each client, which would require perhaps shared memory or the server pool. Perhaps shared memory and signals? This is very MPM specific, though. It would also be nice to move from a prefork MPM to the event MPM to support more simultaneous users in the future without a total overhaul. Any input is appreciated. Thanks! -Chris
