> * the code looks like just the server-side implementation. Would there also > be a client-side implementation to tie into Cayenne.
Yes, we’d need to write an alternative to client HessianConnection to translate Cayenne operations to LinkRest calls. > What about other platforms like a javacript client library? I wanted to write Cayenne-like client in JS at some point, but being an outside in the JS community, I wasn’t sure that’s the right direction. However the existing JS frameworks (Sencha, etc.) can easily use LinkRest as is. > Could a Java client work on Android? No idea. > * could it be tied into servlets so that on the server side we'd have a > GenericServlet subclass like ROPHessianServlet is now? Or is this a very > different implementation? More likely not to servlets, but to JAX-RS resources that work on top of servlets. Also while we can have a single endpoint (say LinkRestResource) that dynamically serves all entities, in this model it will be trivial to add per-entity endpoints , each with its own security characteristics, all tied to a single ServerRuntime. > * I assume it would be easy to wrap the interaction in https and deflate? Of course. > * is it wise to tie it into Jodatime as that library is just now being > replaced by the new Java time classes? I hope LinkRest will be on Java 8 in the next 6 months. Then we drop Joda. Andrus On Sep 1, 2014, at 5:48 AM, Aristedes Maniatis <a...@maniatis.org> wrote: > On 1/09/2014 1:26am, Andrus Adamchik wrote: >> After a marathon of 5 LinkRest [1,2] releases in the last 20 days, I am >> starting to think it soon might become capable enough to replace Hessian in >> ROP. Which is going to be awesome, as the same server will be able to work >> with either Swing/SWT or JS clients, and ROP may break out of its current >> shrinking niche. > > Some questions: > > * the code looks like just the server-side implementation. Would there also > be a client-side implementation to tie into Cayenne. What about other > platforms like a javacript client library? Could a Java client work on > Android? > > * could it be tied into servlets so that on the server side we'd have a > GenericServlet subclass like ROPHessianServlet is now? Or is this a very > different implementation? > > * I assume it would be easy to wrap the interaction in https and deflate? > > * is it wise to tie it into Jodatime as that library is just now being > replaced by the new Java time classes? > >> Aside from the protocol details, the biggest architectural difference >> between current ROP and LinkRest is that the later is not based on blind >> serialization. Instead it has a well-defined query API that the client would >> have to follow. SelectQuery, RelationshipQuery, ObjectIdQuery will all be >> easily translatable to LinkRest. As well as commits (after PATCH [3] is >> implemented). Some consequences of the above: >> >> * A LinkRest server can have fine-grained security. To a point of shaping >> the response objects and attributes per user role. We’ve done that already >> on a number of real projects. > > Are you doing that by controlling access around which RESTful paths which can > be called, or by controlling the objects which are returned? > >> * A LinkRest server can be upgraded without upgrading all the clients. E.g. >> we can use newer Cayenne version on the server and the client wouldn’t know. > > That's very nice. > > >> I am working on improving LinkRest now, and don’t have immediate plans to >> jump on the ROP adapter for that, but still wanted to gauge interest in such >> a technology. And of course in a wider LinkRest discussion. > > > For us, Hessian's main limitations are its lack of documentation, release > notes or clarity in releases. Beyond that it has been extremely robust. It > has been difficult to extend though: adding more cookies, deflate or other > changes have not been trivial for us. > > The one thing that LinkRest could be a regression compared to Hessian is that > Hessian is a very compact binary format. We'd need to compare bandwidth needs > between the two after deflate is applied. > > > Cheers > Ari > > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
