[mochikit] Re: Async status success return codes question
Implement a workaround. Just write an errback that turns 2xx into a successful response, that way your code will still work if the behavior eventually changes. On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So is this yet another thread on success codes that ends without consensus or a final word on success code meaning in MochiKit? Obviously I would prefer it if MochiKit treated all 2** as successes but if the decision is that this wont change then I'll just implement the work around and take it of my TODO list. So Bob can you provide the final word? Regards, Simon Cusack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
So is this yet another thread on success codes that ends without consensus or a final word on success code meaning in MochiKit? Obviously I would prefer it if MochiKit treated all 2** as successes but if the decision is that this wont change then I'll just implement the work around and take it of my TODO list. So Bob can you provide the final word? Regards, Simon Cusack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On Jul 6, 10:11 am, Bob Ippolito [EMAIL PROTECTED] wrote: It works 100% of the time. If you're doing something obscure with status codes (anything obscure, even successful codes that aren't 2xx), you need to use an extra three lines of code in this case. That doesn't mean it's broken. The OP wants 2xx codes to be success, but your remark above even successful codes that aren't 2xx makes me wonder if you think the OP is talking about non-2xx status codes. My reading of this thread is that the OP wants any 2xx code to be a success because that's the way RFC2616 reads. I apologize for being presumptuous and post this excerpt from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html --- 10.2 Successful 2xx This class of status code indicates that the client's request was successfully received, understood, and accepted --- My take on this is that any 2xx status code should be treated as success, regardless if it's commonly seen in the wild. It's true, it's only 3 lines of code to add. But, that's three lines for the OP, and three lines I need to add to all my client's projects, and 3 lines that others will be adding to their code in the future. This behavior is not something I'd expect, since (at least my reading of RFC2616) is that any 2xx should be treated as successful. Sometimes there's a conflict between what a spec says, and what's been commonly coded and deployed. In those cases pragmatic code is good because it works with what's in the wild, even if that doesn't match the specification. But in this particular case, I can't think of any server/service returning a non-common 2xx code that means failure. Following up on what Arnar said, another advantage to MochiKit is that it doesn't do anything unexpected. So, for example, differences between IE and other DOM implementations are hidden away and everything just works. For that, I love MochiKit. But in this particular case, treating 2xx as non-success *is* unexpected to the OP, and unexpected to me. Is there some reason other than it's only 3 lines of code to fix that this behavior should not be changed in MochiKit? Thanks, -B --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/5/07, Karen J. Cravens [EMAIL PROTECTED] wrote: On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote: with (the ones that you actually run into in the wild). It's easy to Given the increasing popularity of REST, seems pretty likely you'll start running into a wider range of response codes in the wild. It's kind of disturbing to learn it's that noncompliant; we haven't settled on a library yet, but Mochikit was the front-runner for me. Now I'm back to I dunno, let's put all the names in a hat and pick one, since Wirebird makes use of pretty much the full range of HTTP responses. As demonstrated it's effectively three lines of code to do whatever you want to do with HTTP status codes, and you only have to write it once. If that really makes such a difference, then I doubt MochiKit is the right choice for you. There are many cases where you actually have to write code, but MochiKit's behavior is well documented so at least you know what it's going to be doing. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Karen [EMAIL PROTECTED] wrote: On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote: As demonstrated it's effectively three lines of code to do whatever you want to do with HTTP status codes, and you only have to write it once. If that really makes such a difference, then I doubt MochiKit is the right choice for you. There are many cases where you actually have to write code, but MochiKit's behavior is well documented so at least you know what it's going to be doing. Yes, I saw the example, but it's more of a philosophy issue... it's a matter of the right tool for the task. I need a stickler-for-the-rules RFC-compliant library; Mochikit seems to have a more pragmatic approach. This works 99% of the time, but I'm that obscure 1%. It works 100% of the time. If you're doing something obscure with status codes (anything obscure, even successful codes that aren't 2xx), you need to use an extra three lines of code in this case. That doesn't mean it's broken. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote: As demonstrated it's effectively three lines of code to do whatever you want to do with HTTP status codes, and you only have to write it once. If that really makes such a difference, then I doubt MochiKit is the right choice for you. There are many cases where you actually have to write code, but MochiKit's behavior is well documented so at least you know what it's going to be doing. Yes, I saw the example, but it's more of a philosophy issue... it's a matter of the right tool for the task. I need a stickler-for-the-rules RFC-compliant library; Mochikit seems to have a more pragmatic approach. This works 99% of the time, but I'm that obscure 1%. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Karen [EMAIL PROTECTED] wrote: On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote: It works 100% of the time. If you're doing something obscure with status codes (anything obscure, even successful codes that aren't 2xx), you need to use an extra three lines of code in this case. That doesn't mean it's broken. It means it's not RFC-compliant out of the box. I'm not saying that's a bad thing overall (the other 99% of the time, you don't want overhead for bits that almost no one uses), I'm just saying it's a bad fit for me. Three lines of code for this fix and that does start to add up; at a certain point it becomes more efficient to start with a more low-level library rather than try to impose a new design philosphy on a more advanced one. Given that you can write your own functions, and those functions can call other functions, you only have to do it once. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Karen [EMAIL PROTECTED] wrote: It means it's not RFC-compliant out of the box. I'm not saying that's a bad thing overall (the other 99% of the time, you don't want overhead for bits that almost no one uses), I'm just saying it's a bad fit for me. Three lines of code for this fix and that does start to add up; at a certain point it becomes more efficient to start with a more low-level library rather than try to impose a new design philosphy on a more advanced one. The whole point of using advanced design like deferreds in a high-level library/framework like MochiKit, is that it's easily extendable to handle edge cases like yours, with little extra code. You can go with something more low level, but in my experience you'll just end up with more code to maintain. Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have been working with Async to build an inhouse web app, we have
ended up using the return codes to implement some interesting
behaviour in our clients.
MochiKit is just one of the clients that uses the web service and some
of our other processes (robots essentially) look for return codes to
act upon. One of these codes is 202 - Accepted. We use this in
response to requests that fire off long running processes in the
server. The server responds with a 202 saying that it is now running
the process and includes a location header to indicate where the
client should go to get updates on the current status of the process.
By default MochiKit doesn't treat a 202 as a success.
MochiKit is written mostly with practical considerations in mind, and
it only knows how to handle the specific success codes that it deals
with (the ones that you actually run into in the wild). It's easy to
make it do what you want though... something like this:
function http_2xx_ok(err) {
if (err instanceof XMLHttpRequestError err.number = 200
err.number 300) {
return err.req;
}
throw err;
}
var d = doXHR(...).addErrback(http_2xx_ok).addCallback(...);
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote: with (the ones that you actually run into in the wild). It's easy to Given the increasing popularity of REST, seems pretty likely you'll start running into a wider range of response codes in the wild. It's kind of disturbing to learn it's that noncompliant; we haven't settled on a library yet, but Mochikit was the front-runner for me. Now I'm back to I dunno, let's put all the names in a hat and pick one, since Wirebird makes use of pretty much the full range of HTTP responses. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
