[Twisted-Python] Deserializing AMP callRemoteString without knowing the Command's signature
Hi, As some of you may know I am working on a JSON-RPC <-> AMP bridge to consume AMP services from browsers. WIP: http://lvh.github.com/amphibian/ I've hit a failing integration test. I know what the issue is -- I don't know how to resolve it. I attempted to write the proxy without any knowledge of the remote commands. It assumes that the JSON provided satisfies the remote signature. If it doesn't -- that's okay, we'll get a failure back from the AMP server. So, I use callRemoteString and manually serialize by typechecking. Although that works for sending, the result I get back from callRemoteString is also in wire format. Because I don't know the signature, I have no idea if the sender meant 4, "4", u"4"... On IRC: dreid pointed out that I really shouldn't need a language-specific implementation of a class for this to work teratorn pointed out that there is a JSON schema ticket for AMP. Perhaps there should also be a "DiscoverSchema" command? Alternatively I could just cop out and require commands to be importable. Would make the code simpler but the entire design would become significantly more coupled. -- cheers lvh
On Jun 26, 2012, at 12:09 PM, Laurens Van Houtven <_@lvh.cc> wrote:
On IRC: dreid pointed out that I really shouldn't need a language-specific implementation of a class for this to work teratorn pointed out that there is a JSON schema ticket for AMP. Perhaps there should also be a "DiscoverSchema" command?
Yes, definitely. There's a ticket for this, even, I think, although I can't find it at the moment.
Alternatively I could just cop out and require commands to be importable. Would make the code simpler but the entire design would become significantly more coupled.
I think this is where you should start. For now, importing Command objects is how you learn about AMP serialization rules. We have plans to expand that, but trying to build that at the same time as Amphibian is probably too much at once. (By all means though, once it exists, Amphibian should use it.) -glyph
On Tue, Jun 26, 2012 at 02:09:59PM -0500, Laurens Van Houtven wrote:
Hi,
As some of you may know I am working on a JSON-RPC <-> AMP bridge to consume AMP services from browsers. WIP: http://lvh.github.com/amphibian/
I've hit a failing integration test. I know what the issue is -- I don't know how to resolve it.
I attempted to write the proxy without any knowledge of the remote commands.
If my "proxy" you mean in the style of Python's built-in XMLRPC Proxy class then I think that is the wrong approach for AMP - you have to have Command signatures available ahead of time for a BINARY protocol. Guessing just isn't any fun or even useful at all. Static typing on the wire - yess.
It assumes that the JSON provided satisfies the remote signature. If it doesn't -- that's okay, we'll get a failure back from the AMP server. So, I use callRemoteString and manually serialize by typechecking. Although that works for sending, the result I get back from callRemoteString is also in wire format. Because I don't know the signature, I have no idea if the sender meant 4, "4", u"4"...
Sure.
On IRC: dreid pointed out that I really shouldn't need a language-specific implementation of a class for this to work teratorn pointed out that there is a JSON schema ticket for AMP. Perhaps there should also be a "DiscoverSchema" command?
I've been calling that "Service Discovery" or "Route Discovery" for a while. And yes, we should have *something* allowing AMP to complete effectively in the "webservice" space (whatever that is). The ticket for an AMP Schema is #5532 (http://twistedmatrix.com/trac/ticket/5532) I would suggest extending the existing proposal with route information. I'm a little bit unclear on what an AMP route is, but as I understand it, it is basically a set of AMP Commands that are available at some known location - useful for segregating functionality (pre-login, post-login, user, admin, etc). Glyph, is that right? There is some code from Divmod lying around somewhere that needs to be looked at. There is a ticket for AMP URLs that include route paths. #5548 (http://twistedmatrix.com/trac/ticket/5548) This would be a great area for someone to come in and try and connect these disparate threads together! -- -E
On Jul 7, 2012, at 6:32 PM, "Eric P. Mangold" <eric@teratorn.org> wrote:
I'm a little bit unclear on what an AMP route is, but as I understand it, it is basically a set of AMP Commands that are available at some known location - useful for segregating functionality (pre-login, post-login, user, admin, etc). Glyph, is that right?
It's not really the set of commands, so much as it is an identified endpoint for AMP boxes, so that you can multiplex them over a single connection. The general idea is that you stick an extra key ("_route") into the box, and that tells it where to go on the other end of the connection, so you can easily have as many parallel AMP streams as you want with only one TCP connection. No protocol switching if you want to do this, of course. Of course, your peer on a particular route will have a specific set of commands available, but so will the "root" route, i.e. the thing that you are talking to when you establish a TCP connection. (Plus, maybe you get some extra or different stuff after you authenticate.) But your peer on a particular route might be a completely dumb IBoxReceiver without even command-dispatch logic. You can see an implementation of this here: <http://bazaar.launchpad.net/~divmod-dev/divmod.org/trunk/view/head:/Epsilon/...>. (And I could swear there's a twisted ticket to integrate this but I can't find it in a quick search.) -glyph
participants (3)
-
Eric P. Mangold -
Glyph -
Laurens Van Houtven