river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: jeri?
Date Mon, 14 Feb 2011 20:13:46 GMT
I've been considering adding a method to MarshalledInstance to only 
resolve code locally, for Entry's and the StreamServiceRegistrar, 
however it could be used for reflective proxy's too, since they don't 
require downloaded code.

Peter.


Dan Creswell 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 <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
View raw message