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 12:48:34 GMT

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.

> Gr. Sim
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

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