[Twisted-Python] pb.Copyable, round trip objects, and untrusted clients

[David Ripton]

Christopher Armstrong wrote:

> Ok, I'm going to debate this assumption of yours. It seems you're 
> complaining about something that is barely a problem: let's talk about 
> code size. Here's an example of how stuff could work.
> 
> In the client:
> 
> persp.callRemote("getCurrentGames").addCallback(_cbGotGames)
> 
> def _cbGotGames(self, games):
>     # games is a list of complex objects, or whatever
>     print "games are", games
>     print "which one?"
>     ui.whichGame(games).addCallback(_cbChosenGame)
> 
> def _cbChosenGame(self, game):
>     #here's what you think saves a lot of code space:
>     persp.callRemote("chooseGame", game)
>     #as opposed to
>     persp.callRemote("chooseGame", game.id())
> 
> 
> Hmm, I count a single extra method call there. That doesn't seem like a 
> whole lot to me. :-) This is not worth getting worked up over. 

Probably not.  It's one more little piece of boilerplate all over. 
(Well, two -- the server has to lookup the game by id.)

I was worrying about code size more in the other subthread, the 
difference between

client.callRemote("send_game", game)

and

client.callRemote("send_stuff_about_game", game.name, game.owner, 
game.create_time, game.start_time, game.min_players, game.max_players, 
game.player_names)

Demonstrating the difference between passing complex objects and passing 
shredded bits of them.  This is what motivated my latest attempt to use 
Copyable instead of lots of little actions to manually push discrete 
changes to game state around.  (Which was probably a poor choice in any 
case; I really like the little discrete actions in most ways.)

Which is of course an exaggeration, because it would really be
client.callRemote("send_game_dict", game.as_dict())
Assuming we only need the atomic elements of game, not contained complex 
objects.  (Nested dicts get ugly fast.)  Also assuming it's okay to have 
one as_dict method that returns the superset of items we ever need, 
rather than a bunch of specialized versions.

> There's certainly applications using Copyable and Cacheable in 
> production; I'm not sure what exactly you're talking about.

I'm not saying they don't work.  I agree that they work quite well, up 
to a point.  Just not up to the point I wanted and mostly expected. 
(Based on reading optimistic docs, or perhaps reading docs optimistically.)

PB is a very nice framework, but the combination of live remote 
references to complex objects and untrusted clients is tough.  Which is 
fine -- I can just pretend Copyable and Cacheable aren't there, and be 
happy that it's so easy to pass dicts and strings.  If newpb solves this 
problem, great, but if not, PB is still the best RPC framework I have.

-- 
David Ripton    dripton at ripton.net