This demands a lot of thought for and by my part. Nicely put! Sent from my iPhone
Michael McGrady Principal investigator AF081_028 SBIR Chief Architect Topia Technology, Inc Work 1.253.572.9712 Cel 1.253.720.3365 On Feb 14, 2011, at 6:57 AM, Patricia Shanahan <p...@acm.org> 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 <s...@qcg.nl> 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. >
