cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dzmitry Kazimirchyk <>
Subject Re: work on ROP
Date Wed, 20 Jan 2016 16:35:58 GMT
Following up on this discussion, I've made an attempt to refactor ROP 
logic, separating serialization and connectivity layers. Here is the 
diff of what I currently have:

Full branch:

The important change here is appearance of pluggable 
ROPSerializationService and ROPConnector interfaces.

ROPSerializationService is responsible for serializing/deserializing 
messages traveling from client to server and back.

ROPConnector implementation is client side logic responsible for 
handling sending data over the network. It is closely tied to its server 
counterpart, ROPServlet, which handles those connections and sends the 
server response back.

At this point the implementation is quite crude and lacks proper unit 
tests, but it shows the general direction we could follow. Comments and 
suggestions are welcome.


On 12/21/15 9:31 AM, Andrus Adamchik wrote:
>> On Dec 18, 2015, at 12:34 PM, Aristedes Maniatis <> wrote:
>> On 18/12/2015 6:28pm, Andrus Adamchik wrote:
>>> I was thinking about this design some more.. This isolation between wire protocol
and serialization layer sounds great at some level, but has significant drawbacks too. It
would prevent us from building a truly RESTful service, as serializer can't manipulate URL,
headers or access media type information. Treating the underlying HTTP as blackbox was the
mistake SOAP made back in the day, which caused its undoing. So I am not sure we want to go
this route.
>> Except that we are building a ROP service, not a restful service. ROP requires the
use of a Cayenne QueryMessage object to describe the resources we want to fetch, where REST
would describe that as a URL path. That's not what I'm trying to accomplish here since it
gives us minimal benefit when the client isn't a web browser.
>> Cayenne ROP currently has just two method calls. One to log in and create a session,
and one for everything else. All the data (which objects we are getting, updating, etc) are
within the serialised data stream itself and not in the URL or headers.
>> The only reason I'm wanting to keep http at all is because some nice stuff has been
already built on it for us. gzip, keep-alive and SSL are all pretty trivial over HTTP. Other
than those, we could just as easily be opening a raw TCP socket and pushing the data over
> If we are focused narrowly on fixing ROP, then I agree. This is fine and is probably
a good low-hanging fruit for us to take care of.
> If we want to make something better and more widely usable out of it, then my concerns
come into play. As I personally haven't committed to doing anything in this area yet, I don't
have any objections to improving ROP per approach discussed above either.
> Andrus

View raw message