Merge lp:~pedronis/u1db/remote-sync-exchange-response-order into lp:u1db
Proposed by
Samuele Pedroni
Status: | Rejected |
---|---|
Rejected by: | Samuele Pedroni |
Proposed branch: | lp:~pedronis/u1db/remote-sync-exchange-response-order |
Merge into: | lp:u1db |
Prerequisite: | lp:~pedronis/u1db/remote-sync-exchange |
Diff against target: |
233 lines (+53/-32) 6 files modified
u1db/backends/__init__.py (+19/-5) u1db/remote/requests.py (+7/-2) u1db/remote/sync_server.py (+9/-10) u1db/tests/__init__.py (+5/-1) u1db/tests/test_remote_client.py (+6/-9) u1db/tests/test_remote_sync_server.py (+7/-5) |
To merge this branch: | bzr merge lp:~pedronis/u1db/remote-sync-exchange-response-order |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Ubuntu One hackers | Pending | ||
Review via email: mp+80801@code.launchpad.net |
Description of the change
reorganize things to send args first in remote sync exchange response
To post a comment you must log in.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/31/2011 03:05 PM, Samuele Pedroni wrote: /code.launchpad .net/~pedronis/ u1db/remote- sync-exchange- response- order/+ merge/80801
> Samuele Pedroni has proposed merging
> lp:~pedronis/u1db/remote-sync-exchange-response-order into lp:u1db
> with lp:~pedronis/u1db/remote-sync-exchange as a prerequisite.
>
> Requested reviews: Ubuntu One hackers (ubuntuone-hackers)
>
> For more details, see:
> https:/
>
> reorganize things to send args first in remote sync exchange
> response
I think the overall change here is that 'send_response' doesn't
actually send a complete response back.
Instead, the act of getting 'e\0\0\0' from the client triggers us to
send the end of the response back to the client.
And that feels a bit wrong. If a client sends us an incomplete
request, or if we error out in the middle, the server should still
send the client back a complete record.
I'd be a lot happier with an api that had:
def start_response(...)
def finish_ response( ...)
def send_response(...): start_response( ...) finish_ response( ...)
self.
self.
So that we have a convenience function for RPCs that just a have a
single chunk of response to send. And fuller api so if RPCs want to
control the start and finish of the response.
Doing it based on data from the client doesn't feel right.
I definitely like that the response header is sent before the stream
content.
> + my_gen = self._checkpoin t_sync_ exchange( from_replica_ uid, generation, + generation) +
> +
> from_replica_
> last_known_
^- I'm not sure about the name here.
> === modified file 'u1db/remote/ requests. py' --- requests. py 2011-10-31 14:04:45 +0000 +++ requests. py 2011-10-31 14:04:45 +0000 @@ -168,11 send_stream_ entry(( doc_id, doc_rev, doc)) + stream_ entry(( doc_id, doc_rev, doc)) + _checkpoint_ sync_exchange( + replica_ uid, + replica_ generation, + known_generatio n) + send_response( other_new_ generation= new_gen) new_gen _finish_ sync_exchange( self.from_ replica_ uid, replica_ generation, self.last_ known_generatio n, other_new_ generation= new_gen) +
> u1db/remote/
> u1db/remote/
> +168,16 @@
>
> def handle_end(self): def send_doc(doc_id, doc_rev, doc): -
> self.responder.
> self.responder.
> new_gen = self.target.
> self.from_
> self.from_
> self.last_
> self.responder.
> = self.target.
> self.from_
> send_doc) - self._result(
> self._close()
>
^- I understand how you are splitting things up here, but it feels a Request poking at the private apis of
bit wrong to have RPCSyncExchange
SyncTarget.
I think making it clear how to split up sync exchange into separate
steps is great. We should just make it a bit more part-of-an-api
rather than private collaboration between the classes.
I think if we moved to a state-of-sync object that might be a way to
go. Because it is true that we don't want to expose it as part of the
network RPC.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk6 u/E8ACgkQJdeBCY SNAANalgCeJBmm5 KYZkFj1YfvY+ +qan+wo jQD1HPwByEQK1Yp ECVfRG6SJp
8nsAoI/
=xjvG
-----END PGP SIGNATURE-----