river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: jeri?
Date Mon, 14 Feb 2011 14:59:57 GMT
"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 <pats@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 <sim@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.
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message