"and performing basic operations in a simple way" Where simple might mean "without too many platform assumptions"?
On 14 February 2011 14:57, 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. >> > >
