From: Brian Q. <br...@sw...> - 2002-08-06 21:03:21
|
I've started to think about making a YAML-RPC specification along the same lines as XML-RPC. Here is an example method call sequence: Client ------ server = yamlrpclib.ServerProxy('yaml.org/test') m = yamlrpclib.multicall(server) m.pow(2,3) m.format(string="Late....", justification="right") p, f = m() --- !yaml.org/^rpc-method-call method-name: pow arguments: - 2 - 3 --- ^yaml.org/^rpc-method-call method-name: format arguments: string: > Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338. wrap : 79 justification: right Server ------ def pow(x, y): __builtins__['pow'](x,y) def format(string, wrap=80, justification="left", use_tabs = 0, spaces_per_tab = 4, use_hyphens = 1): raise ValueError, "right justification is not currently supported" --- !yaml.org/^rpc-response 6 --- !yaml.org/^rpc-fault fault-message: > ValueError: right justification is not currently supported Key features: - Boxcarred requests are supported by having multiple YAML documents in the same HTTP request - Named arguments are supported (though probably not recommended for cross-language compatibility) - Exception handling I'd like a bit of feedback and advice before I proceed. Is my YAML reasonable? Should I differentiate between exceptions and responses using an explicit transfer? Does the Python YAML implementation support explicit transfers? I have some other issues with the Python YAML implementation: - Unicode handling could be better. The dump() function should have an optional argument to indicate the desired encoding - Using a magic method called __yaml__ is evil - Maybe there could be a magic method to control transfers? e.g. class YAMLRPCFault(Exception): def _yamltransfer(self): return '!yaml.org/^rpc-fault' - I think that the dumper won't work correctly for new-style Python classes Cheers, Brian |
From: Ned K. <ne...@bi...> - 2002-08-06 21:58:26
|
On Tuesday 06 August 2002 02:04 pm, Brian Quinlan wrote: > I'd like a bit of feedback and advice before I proceed. Is my YAML > reasonable? Should I differentiate between exceptions and responses > using an explicit transfer? Does the Python YAML implementation > support explicit transfers? How are you going to connect responses/exceptions with the requests?=20 Seems like there needs to be a token of some kind in the request that=20 gets passed back in the response/exception. I've been thinking about something similar in the context of a group=20 messaging system (so that you won't necessarily have to identify the=20 actual procedure to be called, and so that you can have many-to-one,=20 many-to-many, etc.). --=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
From: Brian Q. <br...@sw...> - 2002-08-06 22:29:05
|
> On Tuesday 06 August 2002 02:04 pm, Brian Quinlan wrote: > > I'd like a bit of feedback and advice before I proceed. Is my YAML > > reasonable? Should I differentiate between exceptions and responses > > using an explicit transfer? Does the Python YAML implementation > > support explicit transfers? > > How are you going to connect responses/exceptions with the requests? > Seems like there needs to be a token of some kind in the request that > gets passed back in the response/exception. I can match requests to responses using the order that their documents appear in the stream. |
From: Ned K. <ne...@bi...> - 2002-08-06 23:20:28
|
On Tuesday 06 August 2002 03:30 pm, Brian Quinlan wrote: > > On Tuesday 06 August 2002 02:04 pm, Brian Quinlan wrote: > > > I'd like a bit of feedback and advice before I proceed. Is my > > > YAML reasonable? Should I differentiate between exceptions and > > > responses using an explicit transfer? Does the Python YAML > > > implementation support explicit transfers? > > > > How are you going to connect responses/exceptions with the > > requests? Seems like there needs to be a token of some kind in > > the request that gets passed back in the response/exception. > > I can match requests to responses using the order that their > documents appear in the stream. How would you do this if you wanted to have a multi-threaded server?=20 Would you force serialization of execution for multiple requests? --=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
From: Brian Q. <br...@sw...> - 2002-08-06 23:42:08
|
> > I can match requests to responses using the order that their > > documents appear in the stream. > > How would you do this if you wanted to have a multi-threaded server? > Would you force serialization of execution for multiple requests? I don't understand the problem. Where does the synchronization problem occur? Cheers, Brian |
From: Ned K. <ne...@bi...> - 2002-08-07 00:43:30
|
On Tuesday 06 August 2002 04:43 pm, you wrote: > > > I can match requests to responses using the order that their > > > documents appear in the stream. > > > > How would you do this if you wanted to have a multi-threaded > > server? Would you force serialization of execution for multiple > > requests? > > I don't understand the problem. Where does the synchronization > problem occur? If you started a thread for each separate RPC call, the thread that=20 was doing the second call could finish before the first one. Unless=20 you're waiting until all are done to return the results together,=20 this could be a problem. If you stick to having (say) two responses come across together for=20 every two requests that got submitted together, you're fine. Which is=20 like the example you gave. I wasn't sure what the model was; looking back at your example it=20 looks like all the RPCs would finish, and then you'd send back all=20 the results. I'd misunderstood your intention at first, sorry. --=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
From: Brian Q. <br...@sw...> - 2002-08-07 00:57:47
|
> If you started a thread for each separate RPC call, the thread that > was doing the second call could finish before the first one. Unless > you're waiting until all are done to return the results together, > this could be a problem. The output stream has to be synchronized at the document level in any case. And waiting for all of the results makes it easier to build the HTTP headers. > If you stick to having (say) two responses come across together for > every two requests that got submitted together, you're fine. Which is > like the example you gave. > > I wasn't sure what the model was; looking back at your example it > looks like all the RPCs would finish, and then you'd send back all > the results. That's exactly it. Cheers, Brian |
From: why t. l. s. <yam...@wh...> - 2002-08-06 22:21:03
|
Some ideas.. Brian Quinlan (br...@sw...) wrote: > --- !yaml.org/^rpc-method-call > method-name: pow > arguments: > - 2 > - 3 > --- ^yaml.org/^rpc-method-call > method-name: format > arguments: > string: > > Late afternoon is best. > Backup contact is Nancy > Billsmer @ 338-4338. > wrap : 79 > justification: right Why not seperate the named method parameters technique into a seperate type? !yaml.org,2002/rpc-method-call and !yaml.org,2002/rpc-named-call or something to that effect. Not a big deal. And don't forget the dates with domain types soon to be added to the spec. Personally, I'd rather put the method in the type family and go with the succinct: --- !yaml.org,2002/rpc-method-call:pow - 2 - 3 --- !yaml.org,2002/rpc-named-call:format string: > Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338. wrap: 79 justification: right Of course, you can't really extend it and add options beyond the paramaters. But it's also kind of nice to have that restriction there. Keeps it simple. I have thought of putting together a simple RPC spec with the name OKAY (Object Kit Across Yaml; also simply because Okay is a great word for communciation, synonymous with ACK). If we could negotiate a subdomain at yaml.org, we could add !okay/call and !okay/call-named... Yeah, so... A couple ideas. > Server > ------ > > def pow(x, y): __builtins__['pow'](x,y) > def format(string, wrap=80, justification="left", > use_tabs = 0, spaces_per_tab = 4, use_hyphens = 1): > raise ValueError, "right justification is not currently > supported" > > --- !yaml.org/^rpc-response 6 > --- !yaml.org/^rpc-fault > fault-message: > > ValueError: right justification is not currently supported > Key features: > - Boxcarred requests are supported by having multiple YAML documents in > the same HTTP request Your above example shows a response, followed by a fault. What if the fault occurs first? Do the other calls continue to roll through? Your above example implies that both calls are processed, regardless of the responses. I can see a use in having boxcarred requests fail when any fault is thrown. Especially if the two requests are closely related. > I'd like a bit of feedback and advice before I proceed. Is my YAML > reasonable? Should I differentiate between exceptions and responses > using an explicit transfer? Does the Python YAML implementation support > explicit transfers? For OO languages, the explicit transfer is nicer. PyYaml does support explicit transfers. _why |
From: Brian Q. <br...@sw...> - 2002-08-06 22:37:37
|
> Why not seperate the named method parameters technique into a seperate > type? !yaml.org,2002/rpc-method-call and !yaml.org,2002/rpc-named-call > or something to that effect. Not a big deal. And don't forget the > dates with domain types soon to be added to the spec. > > Personally, I'd rather put the method in the type family and > go with the succinct: > > --- !yaml.org,2002/rpc-method-call:pow Too few characters are allowed in the type family. I should be able to have Japanese method names if I want. Or use periods for namespacing. > Your above example shows a response, followed by a fault. What if the > fault occurs first? Do the other calls continue to roll through? Yes. > Your above example implies that both calls are processed, regardless of > the responses. > > I can see a use in having boxcarred requests fail when any fault is > thrown. Especially if the two requests are closely related. This feature isn't important enough to increase the complexity of the protocol, IMHO. > For OO languages, the explicit transfer is nicer. PyYaml does support > explicit transfers. According to Steve, it doesn't support them for dumping yet. Cheers, Brian |
From: why t. l. s. <yam...@wh...> - 2002-08-09 05:09:42
|
Brian Quinlan (br...@sw...) wrote: > > Too few characters are allowed in the type family. I should be able to > have Japanese method names if I want. Or use periods for namespacing. > Another alternative is to use the URL to invoke methods, as the REST folk teach. I'd actually really like to see a YAML-REST technique implemented, as YAML makes such a great payload. Of course, no boxcarring if you do this. Not sure there's great advantages to the boxcarring. It's slimmer on sockets, but I could see some awful code produced by users of such a feature. > > Your above example implies that both calls are processed, regardless > > of the responses. > > > > I can see a use in having boxcarred requests fail when any fault is > > thrown. Especially if the two requests are closely related. > > This feature isn't important enough to increase the complexity of the > protocol, IMHO. Very well. Any chance we'll see some of this surface on Wiki? _why |
From: Brian Q. <br...@sw...> - 2002-08-09 16:40:22
|
> Another alternative is to use the URL to invoke methods, as the REST > folk teach. I'd actually really like to see a YAML-REST technique > implemented, as YAML makes such a great payload. YAML-REST would be cool, but that would be a totally different project. > Of course, no > boxcarring if you do this. Not sure there's great advantages to the > boxcarring. It's slimmer on sockets, but I could see some awful code > produced by users of such a feature. Latency is usually the big killer in RPC applications. > > This feature isn't important enough to increase the complexity of the > > protocol, IMHO. > > Very well. Any chance we'll see some of this surface on Wiki? I'll give it a try. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-08-06 23:45:11
|
Hello Brian! I'll let Steve address the other items, but from what I know he's not going to be able to do any further work on PyYaml for a wee bit. I'm sure you are welcome to "hack" it some... support for explicit transfers could be much better, etc. | | - Using a magic method called __yaml__ is evil | Steve originally had to_yaml for the method name. I think that __yaml__ is entirely appropriate: - It is quite magical and is othogonal to application concerns. It's not any where near a "normal" function. - It follows the same pattern as __str__, __iter__, and __repr__ that is, it returns an object which complies with the appropriate protocol. - It won't have a name clash. YAML is big enough now that no one would be using __yaml__ for anything. Eventually yaml may even get popular enough to be included in the Python core, and in this case __yaml__ will be entirely appropriate. So, overall, I think that __yaml__ is the best route and I've thought about this quite hard. As for the protocol for __yaml__, now that's something that needs some deep thought. It really needs to expect a tuple (type-family, value) instead of just a value for starters. Ideally the value would be an iterator. Best, Clark |
From: Brian Q. <br...@sw...> - 2002-08-06 23:58:31
|
> | > | - Using a magic method called __yaml__ is evil > | > > Steve originally had to_yaml for the method name. I think > that __yaml__ is entirely appropriate: > > - It is quite magical and is othogonal to application > concerns. It's not any where near a "normal" function. OK. > - It follows the same pattern as __str__, __iter__, and __repr__ > that is, it returns an object which complies with the appropriate > protocol. OK. > - It won't have a name clash. YAML is big enough now that no one > would be using __yaml__ for anything. Eventually yaml may even > get popular enough to be included in the Python core, and in this > case __yaml__ will be entirely appropriate. All __*__ identifiers are reserved by Python (see 2.3.2 of the language reference). Even if yaml became a part of the Python standard library (which is very plausible), it probably still would not be allowed to define its own reserved name. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-08-07 00:49:14
|
On Tue, Aug 06, 2002 at 04:59:36PM -0700, Brian Quinlan wrote: | All __*__ identifiers are reserved by Python (see 2.3.2 of the language | reference). Even if yaml became a part of the Python standard library | (which is very plausible), it probably still would not be allowed to | define its own reserved name. Ok. I'll go through the hoops to get it approved. |
From: <sh...@zi...> - 2002-08-07 06:34:54
|
> On Tue, Aug 06, 2002 at 04:59:36PM -0700, Brian Quinlan wrote: > | All __*__ identifiers are reserved by Python (see 2.3.2 of the language > | reference). Even if yaml became a part of the Python standard library > | (which is very plausible), it probably still would not be allowed to > | define its own reserved name. > > Ok. I'll go through the hoops to get it approved. > Clark, I think it might make more sense for us to pick a name that's compatible with other languages. For example, it would be nice if Perl, Ruby, and Python all used to_yaml and from_yaml as the magical method names. Brian's mentioned the idea to me out here in Seattle, and I think it makes sense. |
From: Brian I. <in...@tt...> - 2002-08-07 07:59:48
|
On 06/08/02 23:34 +0000, sh...@zi... wrote: > > On Tue, Aug 06, 2002 at 04:59:36PM -0700, Brian Quinlan wrote: > > | All __*__ identifiers are reserved by Python (see 2.3.2 of the language > > | reference). Even if yaml became a part of the Python standard library > > | (which is very plausible), it probably still would not be allowed to > > | define its own reserved name. > > > > Ok. I'll go through the hoops to get it approved. > > > > Clark, > > I think it might make more sense for us to pick a name that's > compatible with other languages. For example, it would be nice if > Perl, Ruby, and Python all used to_yaml and from_yaml as the magical > method names. Brian's mentioned the idea to me out here in Seattle, > and I think it makes sense. Yup. I plan on talking to Steve tommorrow about setting forth a common proposed public API for YAML. Nothing mandatory. Just a meeting of the minds. I've already changed the YAML.pm API twice to be more YAMLesque. Store() became Dump() and Bless() is becoming Shadow(). It would be nice to agree upfront. Right now I'm using yaml_dump() and yaml_load() methods. But I'll probably switch to from_yaml() and to_yaml(). I'll run our discussion by Why as well. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-08-07 08:03:29
|
On Wed, Aug 07, 2002 at 12:59:42AM -0700, Brian Ingerson wrote: | On 06/08/02 23:34 +0000, sh...@zi... wrote: | > > On Tue, Aug 06, 2002 at 04:59:36PM -0700, Brian Quinlan wrote: | > > | All __*__ identifiers are reserved by Python (see 2.3.2 of the language | > > | reference). Even if yaml became a part of the Python standard library | > > | (which is very plausible), it probably still would not be allowed to | > > | define its own reserved name. | > > | > > Ok. I'll go through the hoops to get it approved. | > > | > | > Clark, | > | > I think it might make more sense for us to pick a name that's | > compatible with other languages. For example, it would be nice if | > Perl, Ruby, and Python all used to_yaml and from_yaml as the magical | > method names. Brian's mentioned the idea to me out here in Seattle, | > and I think it makes sense. | | Yup. I plan on talking to Steve tommorrow about setting forth a common | proposed public API for YAML. Nothing mandatory. Just a meeting of the | minds. I've already changed the YAML.pm API twice to be more YAMLesque. | Store() became Dump() and Bless() is becoming Shadow(). It would be nice | to agree upfront. Right now I'm using yaml_dump() and yaml_load() | methods. But I'll probably switch to from_yaml() and to_yaml(). I'll run | our discussion by Why as well. Ok. What ever you fellas agree on then. Perhaps consistency is a good hobgoblin in this case! Saves me a PEP and 8 hours of work on python-dev, so I'm for it. Clark |
From: why t. l. s. <yam...@wh...> - 2002-08-07 16:40:50
|
Brian Ingerson (in...@tt...) wrote: > Yup. I plan on talking to Steve tommorrow about setting forth a common > proposed public API for YAML. Nothing mandatory. Just a meeting of the > minds. I've already changed the YAML.pm API twice to be more YAMLesque. > Store() became Dump() and Bless() is becoming Shadow(). It would be nice > to agree upfront. Right now I'm using yaml_dump() and yaml_load() > methods. But I'll probably switch to from_yaml() and to_yaml(). I'll run > our discussion by Why as well. Obviously, I'm diggin' it, as the to_yaml() setup is already a part of YAML.rb. I have some slight urges against from_yaml(), but I think that's because generally objects in Ruby have export conversion functions only. Then my Emitter class has export to various types. I don't know if a public API would be a good idea or not. Hard to tell without hearing everyone's ideas. Let's bounce around some specifics and I'm sure we can work it out. Chill, _why |