Re: [whatwg] Fakepath revisited
On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com wrote: implementing fakepath would require teaching every web developer to use foo.value.substr(12) or foo.files[0] instead of foo.value. Confusing and unintuitive behavior like this makes HTML more difficult to learn, and this added cost of learning should not be ignored either. IE7 (and IE8 in quirks and compat view modes) and earlier versions of Firefox (and earlier versions of WebKit?) exposed the full path, so Web developers already had to hack out a substring to get the file name. -- Simon Pieters Opera Software
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 12:35 AM, Simon Pieterssim...@opera.com wrote: On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com wrote: implementing fakepath would require teaching every web developer to use foo.value.substr(12) or foo.files[0] instead of foo.value. Confusing and unintuitive behavior like this makes HTML more difficult to learn, and this added cost of learning should not be ignored either. IE7 (and IE8 in quirks and compat view modes) and earlier versions of Firefox (and earlier versions of WebKit?) exposed the full path, so Web developers already had to hack out a substring to get the file name. Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. On Sat, Sep 5, 2009 at 7:46 PM, timelesstimel...@gmail.com wrote: On Sat, Sep 5, 2009 at 12:27 PM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Also, we could settle this. A sizable non-exhaustive list of problematic sites could end this discussion soon. Just sayin'. Let's get biblical. Precisely how sizable is sufficient for us not to destroy Sodom ? The fact is that we want users to be able to upgrade routers. Routers that users don't upgrade to later firmware are security nightmares. Firefox recently announced a feature to encourage users to upgrade Flash. Saying that we don't want our users to upgrade their routers would sound disingenuous right about now. And routers are interesting things, there have been some fairly cool attacks on them using browsers (kinda like Flash). From what I've seen, home router firmwares are rarely updated even though they should be. Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. A specific list of affected routers would go a long way to help us determine the frequency and severity of their vulnerabilities, and whether firmware updates are available to resolve them. Incidentally, it would be really cool if the routers automatically downloaded and installed their own updates. Automatic updates would provide much more consistent security than asking end users to regularly check for and install updates on their own. Sometimes it'd be nice if people were willing to trust browser vendors. Sometimes we aren't going to be able to release all of our research. But really, if there's a business case strong enough to prevent us from doing something we've announced we intended to do, and that something would have reduced our code complexity, you can be sure that it meant there was a reason. In all likelihood, the engineers hate the fact that they're doing it, but there's a reason, and it had to be pretty darn good for engineering to cave. (Speaking as an engineer who does not enjoy caving, but who is glad to be able to ship a product once in a while.) Essentially, you are choosing to trade long-term good design for short-term compatibility. It's the quick and easy path, and it's not a good idea. It would be like writing specifications for the IE7 (or IE6) rendering engine and then declaring them to be the new standard. Sure, sites that were only tested in IE7 would continue to work perfectly, and you could throw in some cool new features too, but it wouldn't fix the bugs that make IE7 hard to work with in the first place. IE8 tries to offer the best of both worlds by having a Compatibility View button--why can't fakepath just be another part of this one-click workaround? I know that I don't get to write the standard; the decision is ultimately not up to me. If the major browser vendors agree to standardize on fakepath then myself and other web developers will just have to live with it. All I can do is share my perspective and hope it makes a difference. -Alex
Re: [whatwg] HTML 5 buttons and constraint validation
Il giorno 07/set/2009, alle ore 06.56, Alex Vincent ha scritto: There's a possible disconnect between input type=button/ and button/. The former is barred from constraint validation, but the latter is not. (Section 4.10). Is this intentional? I guess it's a mistake; actual implementation of willValidate flag on WebKit assumes that both of them (button and type=button) are barred from validation. -- Bye, Michelangelo
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 3:24 AM, Alex Henriealexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. ~TJ
Re: [whatwg] Fakepath revisited
Am Montag, den 07.09.2009, 10:10 -0500 schrieb Tab Atkins Jr.: Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? Also, I have all my important files in C:\fakepath\ you insensitive clod ! ;) Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Fakepath revisited
On Mon, 07 Sep 2009 17:38:39 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? File.name -- http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie alexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Unix also allows filenames to contain newlines, unprintable characters, trailing whitespace, and strings of bytes that don't represent any characters at all in common encodings. Not to mention that file extensions are often omitted. If web authors aren't prepared to deal with all those, then getting confused by backslashes isn't going to be a huge additional problem, I imagine. At least in your case the script will be left with a valid Windows filename, even if it's not the same one as on the user's filesystem. Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. IIRC, the problem is that you can't upload the new firmware to the router at all, so the manufacturer can't release an update to fix it. It can only make sure it's fixed in new models. Essentially, you are choosing to trade long-term good design for short-term compatibility. Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. Any standard that demands incompatibility with existing content will be ignored by implementors, as XHTML was, and thus useless to authors. That's the fact of the matter, whether we like it or not. New APIs can be introduced, but old ones can't be changed in incompatible ways.
Re: [whatwg] More prohibited characters for unquoted attributes are needed
On Mon, Sep 7, 2009 at 1:34 PM, Geoffrey Sneddon foolist...@googlemail.com wrote: Apparently Hixie had previously said he didn't want to change this as it will become a non-issue over time. I think it does matter due to the security issues it presents in existing UAs. Conforming markup (using elements/attributes allowed in HTML 4.01) should not cause JS to execute in one browser but not in another. I agree with you as an author. I wrote an HTML output function in MediaWiki assuming that what the standard says is known to be interoperable, which is apparently wrong. If I hadn't been keeping up with HTML 5, I would have introduced an XSS vulnerability because of some browsers' handling of `. If the problem will go away with time, then perhaps a later version of the standard could make such unquoted attributes conforming, once there's no more problem with them.
Re: [whatwg] More prohibited characters for unquoted attributes are needed
On 6 Sep 2009, at 12:35, Aryeh Gregor wrote: See some research here: http://code.google.com/p/html5lib/issues/detail?id=93 It seems like in addition to whitespace and '= , the characters U+ through U+0020 should be banned from unquoted attribute values, as well as U+0060 (backtick `), for the sake of compatibility. Apparently Hixie had previously said he didn't want to change this as it will become a non-issue over time. I think it does matter due to the security issues it presents in existing UAs. Conforming markup (using elements/attributes allowed in HTML 4.01) should not cause JS to execute in one browser but not in another. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 9:41 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 07 Sep 2009 17:38:39 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? File.name -- http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Think about how this will affect web development 20 years from now. Inexperienced web developers will try to use the more intuitive property foo.value, not realizing that they should use foo.files[0].name instead. They may not know that foo.files[0].name exists, or they may assume that it behaves the same as foo.value. Some of those developers will think that the compatibility problems that led to fakepath still exist, and will use foo.value.substr(foo.value.lastIndexOf(\\) + 1) despite the potential problems if the filename actually contains a backslash. In all, HTML will be harder to learn and bad designs will continue to be made. Actually, I just realized one reason why Firefox's omission of fakepath hasn't caused widespread compatibility problems. Think about it: if there are no backslashes in the file name, then foo.value.substr(foo.value.lastIndexOf(\\) + 1) will work perfectly happily with both C:\fakepath\upload.txt and upload.txt, because lastIndexOf will return -1 if no backslashes are found. Clearly, the affected web pages are doing a bit more than just trying to extract the file name or extension. Can you please share the list of web pages you found that are affected by this problem, so that we can see exactly what they're trying to do? On Mon, Sep 7, 2009 at 9:56 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie alexhenri...@gmail.com wrote: Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. IIRC, the problem is that you can't upload the new firmware to the router at all, so the manufacturer can't release an update to fix it. It can only make sure it's fixed in new models. You know, if the manufacturers cared they could release a program that updated the router without using the broken web interface. Essentially, you are choosing to trade long-term good design for short-term compatibility. Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. Any standard that demands incompatibility with existing content will be ignored by implementors, as XHTML was, and thus useless to authors. That's the fact of the matter, whether we like it or not. New APIs can be introduced, but old ones can't be changed in incompatible ways. CSS2 demanded incompatibility with IE6 and IE7's previous implementations. IE8 resolved these problems and IE8 users haven't taken to the streets of Redmond with pitchforks yet. I'm asking the same thing: take good behavior from Firefox, Safari, and Chrome and get it working in IE and Opera too. It's not impossible, and it's well worth it in the long term. -Alex
Re: [whatwg] Fakepath revisited
Oops... the following was meant to be a reply to all but I hit reply instead; so here it goes a copy for the list: On Mon, Sep 7, 2009 at 8:43 PM, Eduard Pascualherenva...@gmail.com wrote: On Mon, Sep 7, 2009 at 5:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 7, 2009 at 3:24 AM, Alex Henriealexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. ~TJ That wouldn't work. There is an important ammount of browsers that include the full path in the value. So web authors would need to know *a lot* of guesswork if they are to hack a substring from such value. They have to figure out whether they'll be getting a plain file name, a file name with a path, or a fakepath, and treat each case separately. If a site tries to just substring(12), it will break on any non-HTML5 browser (except on the corner case where the value contains a full path and it is exactly 12 characters long). If they try to split on \, they will break when a file on a non-Windows system contains that character. To put things on a more obvious shape, imagine the following scenarios: A file named up\load.txt (on a non-Windows OS) is given from an HTML5 browser. We get a value=C:\fakepath\up\load.txt. A file named load.txt, and located at C:\fakepath\up\ from a browser that includes full path. We get a value=C:\fakepath\up\load.txt. Two different file-names end up yielding the same value string. So, basically, it is impossible to reliably recover the name of the file from only the value string: there will be ambiguous cases. While the examples above may seem corner cases, they are just intended to show off the ambiguity issue. Ok, so some (horribly-designed) sites break without fakepath. Since the HTML5 spec likes so much to include explicit algorythms, is there any reliably algorythm that web authors can use to recover the actual filename? (Without having to assume that everybody switches immediatelly to HTML5-compliant browsers, of course.) If there isn't, then every other site (including all the decently-designed ones) that need/use the filename would break. What would be the point to keep compatibility with some bad-sites if it would break many good sites? Regards, Eduard Pascual
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 2:41 PM, Alex Henrie alexhenri...@gmail.com wrote: CSS2 demanded incompatibility with IE6 and IE7's previous implementations. IE8 resolved these problems and IE8 users haven't taken to the streets of Redmond with pitchforks yet. IE6 and 7 weren't even compatible with CSS1 in many ways. On the other hand, all other browsers overwhelmingly were. It would have been impossible to do anything that didn't either break IE, or break everyone else, *dramatically* (as in everyone has to rewrite all their pages dramatically). Since the behavior of everyone else was already specced, and IE's wasn't, and IE was the one that implemented the spec incorrectly to start with, the decision there was to stick with the already-specced stuff, and IE changed to accommodate it. I don't know why you think there wasn't massive backlash against Microsoft for their incompatible changes, either. IE7 adoption was very slow, and one reason I've often seen given is lack of compatibility with intranet sites. You might want to read this post by Chris Wilson: http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html One quote that stood out for me: IE7 did cause widespread disruption, as a case in point. I championed making those widespread changes to improve our standards compliance. In all seriousness, I've managed to hang on to my job, but sometimes I think only just. I cannot go to my team and say 'hey, we're gonna break the web again (and again and again), but it's okay because it's for a good cause.' The world doesn't work that way. I wouldn't be responsibly doing my job - that one where half a billion web users rely on my team to not hose compatibility with their banking web site, even if their bank doesn't know how to properly use CSS 'float'. In other words, Microsoft realizes it messed up with IE7 and wants to avoid a repeat experience if at all possible. Notice what elaborate compatibility measures they've added to IE8, making it behave almost exactly like IE7 in many cases. I'm asking the same thing: take good behavior from Firefox, Safari, and Chrome and get it working in IE and Opera too. It's not impossible, and it's well worth it in the long term. That's a fine position, but in the end, if the implementors won't implement it, it's not going to go anywhere.
Re: [whatwg] Fakepath revisited
On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. We can sacrifice *some* compatibility for *some* long-term goals. We do it all the time, even Microsoft. It's all about tradeoffs. In this case, I'd like to see a list of specific routers, sites etc that triggered the implementation of fakepath in Opera and IE. I'd like to crosscheck with our Bugzilla to understand why we haven't felt the need to do this in Firefox. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Date/time field types - min, max, popup UI.
On Mon, Sep 7, 2009 at 6:45 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 08 Sep 2009 00:40:02 +0200, Sigurd Magnusson sig...@silverstripe.com wrote: In looking at the HTML 5, I have noticed an opportunity to provide additional elements to support date and time field types. (Or, if I am mistaken, it may simply be an opportunity to improve documentation of an existing feature). Whereas most field types have a Min and Max attribute, this does not appear to be true of date/time fields. What makes you think they do not apply there? They do, according to this handy-dandy chart: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#input-type-attr-summary The UI question is more vexing. Like a lot of features in HTML 5, how useful these features will be to authors looks like it will depend a lot on how consistently good the UI is that browsers implement. If even one major browser has bad UI, or if the UIs prove to be inflexible, that might kill a lot of the interest that many authors have in using the new input types.
Re: [whatwg] Date/time field types - min, max, popup UI.
Aryeh, ok, thanks for clarifying that. I also note now that http://www.whatwg.org/specs/web-apps/current-work/#date-state shows max and min can be written as date strings. Phew about that. But I'm glad you agree with the UI. I also don't think that the 'blank text box with a calendar icon to the right' is the most optimal way of asking the normal human being to choose a date -- except where this question is on a compact form, or where the question is optional or unimportant and so shouldn't dominate the web page. I feel this textbox with icon UI has arisen based on the limited time available to most website developers and the fact that developers wished to use a text input to ensure the data is part of a standard GET/POST submission. Sig On 8/09/2009, at 11:44 AM, Aryeh Gregor wrote: On Mon, Sep 7, 2009 at 6:45 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 08 Sep 2009 00:40:02 +0200, Sigurd Magnusson sig...@silverstripe.com wrote: In looking at the HTML 5, I have noticed an opportunity to provide additional elements to support date and time field types. (Or, if I am mistaken, it may simply be an opportunity to improve documentation of an existing feature). Whereas most field types have a Min and Max attribute, this does not appear to be true of date/time fields. What makes you think they do not apply there? They do, according to this handy-dandy chart: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#input-type-attr-summary The UI question is more vexing. Like a lot of features in HTML 5, how useful these features will be to authors looks like it will depend a lot on how consistently good the UI is that browsers implement. If even one major browser has bad UI, or if the UIs prove to be inflexible, that might kill a lot of the interest that many authors have in using the new input types.
[whatwg] Criticism of pushState (was Global Script proposal)
Dimitri Glazkov wrote:
But more to the point, I think globalScript is a good replacement for
the pushState additions to the History spec.
I'm not sure I agree. pushState lets you change the URI very quickly,
without doing any kind of navigation at all. To emulate a pushSate
with globalScript, you'd have to save and restore the whole document,
and the browser would still have to do at least one network request,
unless you were only changing the hash of the URI.
I am becoming
somewhat convinced that pushState is confusing, hard to get right, and
full of fail. You should simply look at the motivation behind building
JS-based history state managers -- it all becomes fairly clear.
Could you elaborate on these points? It seems to me that pushState
attacks a specific problem and delivers a simple solution which is
much better than the current workarounds (using the URL's hash to
identify a page and store state). Yes, it's nontrivial to develop an
AJAX app which uses pushState and works correctly with bookmarking and
page refreshes. On the other hand, pushState makes this a lot easier
than it would be otherwise.
My big issue with pushHistory is that it messes with the nature of the
Web: a URL is a resource you request from the server. Not something
you arrive to via clever sleight of hand in a user agent.
Like it or not, this ship has already sailed. When I load Gmail, I'm
taken to https://mail.google.com/mail/#inbox, but my browser never
sends #inbox to the server as part of the HTTP request. Pandora and
Facebook do something like this too. Perhaps the new intuition is
that a URL tells you how to get back to where you were.
So, you've managed to pushState your way to
a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks
it. What are you going to do know?
When reading this message in Gmail, my browser shows that I'm at
https://mail.google.com/mail/#label/WhatWG/{guid} . If I bookmark
this page and go back to it, Gmail takes me back to this exact
message. There's no actual resource named #label/WhatWG/{guid} on
Google's servers, but the URL I bookmarked is sufficient to identify
where I was, and Gmail's servers were intelligent enough to take me
there.
Maybe you think that Gmail's URLs should name real resources; maybe
they should look like
https://mail.google.com/mail.cgi?label=WhatWGmessage={guid} or
something. I'm not convinced this is better, but even if it suits
you, pushState still helps you navigate between mail.cgi?label=WhatWG
and mail.cgi?label=Drafts without a page refresh.
I think pushState API is really useful, but what do I know? We're
going to land it in Firefox trunk Real Soon Now, so developers and
members of this list will be able to play with it and decide for
themselves whether it's the right API to solve the problem at hand.
-Justin
Re: [whatwg] Criticism of pushState (was Global Script proposal)
PushState is also useful for e.g. making sure that the referer header
contains useful information. Not to say that there aren't other ways to
accomplish that, but it is one thing that Global Context won't give you.
2009/9/7 Justin Lebar justin.le...@gmail.com
Dimitri Glazkov wrote:
But more to the point, I think globalScript is a good replacement for
the pushState additions to the History spec.
I'm not sure I agree. pushState lets you change the URI very quickly,
without doing any kind of navigation at all. To emulate a pushSate
with globalScript, you'd have to save and restore the whole document,
and the browser would still have to do at least one network request,
unless you were only changing the hash of the URI.
I am becoming
somewhat convinced that pushState is confusing, hard to get right, and
full of fail. You should simply look at the motivation behind building
JS-based history state managers -- it all becomes fairly clear.
Could you elaborate on these points? It seems to me that pushState
attacks a specific problem and delivers a simple solution which is
much better than the current workarounds (using the URL's hash to
identify a page and store state). Yes, it's nontrivial to develop an
AJAX app which uses pushState and works correctly with bookmarking and
page refreshes. On the other hand, pushState makes this a lot easier
than it would be otherwise.
My big issue with pushHistory is that it messes with the nature of the
Web: a URL is a resource you request from the server. Not something
you arrive to via clever sleight of hand in a user agent.
Like it or not, this ship has already sailed. When I load Gmail, I'm
taken to https://mail.google.com/mail/#inbox, but my browser never
sends #inbox to the server as part of the HTTP request. Pandora and
Facebook do something like this too. Perhaps the new intuition is
that a URL tells you how to get back to where you were.
So, you've managed to pushState your way to
a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks
it. What are you going to do know?
When reading this message in Gmail, my browser shows that I'm at
https://mail.google.com/mail/#label/WhatWG/{guid} . If I bookmark
this page and go back to it, Gmail takes me back to this exact
message. There's no actual resource named #label/WhatWG/{guid} on
Google's servers, but the URL I bookmarked is sufficient to identify
where I was, and Gmail's servers were intelligent enough to take me
there.
Maybe you think that Gmail's URLs should name real resources; maybe
they should look like
https://mail.google.com/mail.cgi?label=WhatWGmessage={guid} or
something. I'm not convinced this is better, but even if it suits
you, pushState still helps you navigate between mail.cgi?label=WhatWG
and mail.cgi?label=Drafts without a page refresh.
I think pushState API is really useful, but what do I know? We're
going to land it in Firefox trunk Real Soon Now, so developers and
members of this list will be able to play with it and decide for
themselves whether it's the right API to solve the problem at hand.
-Justin
