I've been thinking about Tooling and ServiceUI and how that can be expanded beyond the Swing toolkit as far as a proper contributed implementation is concerned.
If we think of the UI being 'User Interaction' rather than just 'User Interface' then I think we could very well provide services without mobile code. I've been toying with adding a HTML Controller (maybe even to the standard ClassServer) for forwarding service UIs to a browser, with the controller negotiating between the service proxy and the browser client, if this is further 'distilled' to a simplified XML-type form (and here, initially, I was thinking in terms of a user interface definition that could be 'interpreted' by an application such as an iPhone app, etc) with certain service actions exposed through the ServiceUI object (and hence the HTML/XML representation) for this you could use REST. Although these ideas are only at an embryonic stage, of course, this kind of implementation all though it would need to be carefully managed and staged, could help a lot with interop. --Calum On 14 Feb 2011, at 14:57, Patricia Shanahan wrote: > I like this general idea. I have been becoming more and more concerned that > doing everything through moving code around is, in several ways, a problem > rather than an advantage. > > I see the movable code idea as being most powerful for providing versions of > services that reduce communication cost by doing more work on the client. > That could be done in parallel with basic versions of the same services that > do not require code movement. > > For many issues, such as negotiating trust, finding suitable services, and > performing basic operations in a simple way, it seems to me to be a hindrance. > > Patricia > > > Dan Creswell wrote: >> ... >> On 14 February 2011 12:41, Sim IJskes - QCG <[email protected]> wrote: >>> On 14-02-11 13:22, Dan Creswell wrote: >>> >>>> Android and the consequences is one angle certainly. I was thinking >>>> something maybe a bit more sacred like: >>>> >>>> All services exposed via REST and dynamically discovered (properly as >>>> opposed to the more traditional definition of dynamic discovery used for >>>> the >>>> web which involves having a specific URL to start from and some feed or >>>> another to parse). >>>> >>>> If one goes wholly REST the idea of movable code everywhere is less >>>> relevant >>>> though not eliminated (it's still an attractive proposition for certain >>>> platforms/environments). >>>> >>> REST, big leap, lets try. Are you talking about dictionary based exchange >>> of parameters and result? Textual (or value) data is easy serialized, but >>> how about references to exposed services. Serialize by url? >>> >> Sure, could be JSON or XML (shudder) for parameters (although not everything >> has to be considered a parameter - how about streams of data and such?) >> Serialize by URL? Probably - certainly have to express contact details and >> this is one way to do it. DNS or similar is also somewhat possible with SRV >> records and such. >>> What do we validate on going from dynamic structures to statically typed? >>> >>> >> Can you say more about this one - not sure what you're asking..... >> Closest I can get is that service and client must understand each others >> contract. They may or may not bother with enforcement of such a contract and >> thus they may or may not validate. >>> Do you envision a multi language/platform solution here? >>> >>> >> I certainly envision multiple platforms. Multi-language kind of falls out as >> a gimme, once one drops away the requirement for movable code. As I said >> elsewhere, that doesn't mean movable code cannot still be used. No reason >> one couldn't build such a layer in front of REST services if that's "nicer" >> in various cases. >
