So.... On 14 February 2011 13:19, Sim IJskes - QCG <s...@qcg.nl> wrote:
> On 14-02-11 13:48, Dan Creswell wrote: > >> 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. >> > > Ha! :) If by URI, then a ref to SRV is easily extended. > > What do we validate on going from dynamic structures to statically typed? >>> >> 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. >> > > Exactly. The contract on exchanging the data would be the typing. Do you > see a recursive serialisation right down to the value objects and > primitives, or do you foresee shortcuts? > Haven't thought about that, least not in the context of setting a standard. > > Not worried about the verbosity? Binary is so much smaller isnt it? > > Binary is smaller and there are plenty of examples of this going back to the likes of XDR and before. In my experience, each service can tune it's data/contract to suit. So some can be text, some can be binary. Thinking customer profile information versus financial price dissemination. > > 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. >> > > Until someone starts coding a java bytecode to python/javascript translator > and starts serving these :). > > Dont you see this all ending up in river running on a SOAP-size like RPC > mechanism? > > No, because I don't believe the RPC paradigm is appropriate under all circumstances. Streams versus small packet request/response. > But the main gist of your vision is the replacement of the RPC mechanism, > right? > > Mmmm, no cos I think there are a set of patterns beyond the basic comms to encode and in any case as I imply above, I think there may be a "standard" RPC stack but there's some other "standard" stack as well to cover other use cases (websocket or similar maybe). > > Gr. Sim > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >
