Perhaps this refers to the original vision by Gelertner? Two computer passing information with non-overlapping tomes of existence, like clouds.
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:59 AM, Dan Creswell <dan.cresw...@gmail.com> wrote: > "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. >>> >> >>
