Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.220.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=UN3dURMfTpZF0OvszCQkf8y7cAkdAPiZkl3NBezdD7Zyw7qxFnLMgjIM3MQdfojIb8
         8df6um+Qot47A/01MhaOMqFvyAk7xe4ZpIOKHDHBD2BSUBJ5dVDqDHxHYYj0HHD3EPKS
         QH02f4GUPFEKkqheF65sobzfdGwJM1y8DZOgc=
MIME-Version: 1.0
In-Reply-To: <4D592310.1090902@qcg.nl>
References: <AANLkTimrkPV=SYag+XzLifGod9TDPf3P4kAYSGWjVpiG@mail.gmail.com>
	<4D566919.1000308@zeus.net.au>
	<1297622418.19722.144.camel@cameron>
	<0FC65041-5B25-4210-8331-3B3C886F51D3@gmail.com>
	<6F2647E1-B9F6-48DA-B8FF-491B63A93129@topiatechnology.com>
	<AANLkTi=zJ_5raxDuW_9gQRGEemY+aNq2GduzLGu36k7A@mail.gmail.com>
	<12E76FB4-DA0C-4531-B6A8-81C33FE1EA66@topiatechnology.com>
	<D4B6D661-937B-4AA8-A21E-332B4BD7D447@gmail.com>
	<AANLkTi=BQ=Ery5EsOpgEA6nLubt13Z6EPosoyd9NBdFT@mail.gmail.com>
	<4D59138F.30803@qcg.nl>
	<AANLkTi=A5BQ9Y5Q_GugGxu5VB6w6doravHSsURp9kYrb@mail.gmail.com>
	<4D5919EC.6040504@qcg.nl>
	<AANLkTikKPC9R683dW1WJz2ewt5yMbiVmjqEia78c=1a2@mail.gmail.com>
	<4D592310.1090902@qcg.nl>
Date: Mon, 14 Feb 2011 12:48:34 +0000
Message-ID: <AANLkTimCHftNtK6XHtuJ=rP3HvPpkpqXb7vyg2P-LVM+@mail.gmail.com>
Subject: Re: jeri?
From: Dan Creswell <dan.creswell@gmail.com>
To: dev@river.apache.org
Content-Type: multipart/alternative; boundary=90e6ba4fc3b643098b049c3d77a4

--90e6ba4fc3b643098b049c3d77a4
Content-Type: text/plain; charset=ISO-8859-1

...

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
>

--90e6ba4fc3b643098b049c3d77a4--