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:
https://github.com/dzmitryk/cayenne/compare/master...dzmitryk:rop-refactoring
Full branch:
https://github.com/dzmitryk/cayenne/tree/rop-refactoring
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.
Dima
On 12/21/15 9:31 AM, Andrus Adamchik wrote:
On Dec 18, 2015, at 12:34 PM, Aristedes Maniatis <a...@maniatis.org> 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 that.
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
