There is maybe something similar to what you're looking for. Cisco phone is receiveing XML files describing menus - so maybe digging into that would help. It's somekind of customized Orbiter proxy that sends xml files to phone to display GUI and I guess it contains less (or even none) graphics....
In a long term it would be proper solution to have somekind of Text Orbiter proxy, that could deal with less graphic and more text oriented devices...
I agree, this sounds like a good model. A generic xml orbiter proxy seems a useful thing to have, as you could have it used by different remotes with no change to the proxy.
This would also have the advantage of removing or at least reducing the need for regenerating the orbiter, and would make using the device that much more feasible over a gprs link.
I think it will still be preferable to transfer some graphics over the wire, but it may be possible to have a seperate graphics service running to give access to those and let the remote device request them when required.
In fact, taking that concept a bit further, if you had some kind of separate service running to serve up media to the orbiters, such as menu graphics, you could then have the xml orbiter proxy tell the device semantically what to render as an xml file, it could then runtime detect the best way (graphic/ text/ combo), then request the correctly scaled versions of the graphics from the DCE router media service, using these to construct the UI.
Something like this would give us a nice development path, create an xml orbiter proxy, create a j2me app that renders them menus as text; then add nicer graphics features in the future.
Has anyone looked at the cisco orbiter proxy code in detail? would it be easily adaptable as a generic xml proxy? I'm not very good at C++, so would anyone like the chance to make a huge contribution to lmce and join me in constructing this?
David.
