URI Proposal
ES embeddings exist where URIs make no sense, so it's not a good
candidate for the core standard. But we expect the burgeoning Ajax
ecosystem to keep on burgeoning (www.answers.com/main/ntquery?
gwp=13&s=burgeon), and make good use of shared library hosting
arrangements such as those provided by code.google.com and the like.
This should yield innovation and consolidation, as it has already for
some JS libraries, and as it did over the years for C (like JS, C
lacks built-in I/O primitives -- teletypes then or URIs now would not
fit in the core language).
You could make the same argument I'm making here about JSON and a few
other standard library proposals. I will not special-plead on their
behalf. Indeed we've had open issues about the detailed design of the
"right" JSON API on this list, which linger and nag (at me, at any
rate).
ECMA would be foolish to try to standardize too much I/O mechanism
and the like prematurely, but you and others on es4-discuss should
definitely collaborate (and on this list, for now -- we could use the
feedback both ways).
very interesting subject, but this one can raise a lot of issues imho
On 9/8/07, Brendan Eich <brendan at mozilla.org> wrote:
ES embeddings exist where URIs make no sense, so it's not a good candidate for the core standard. But we expect the burgeoning Ajax ecosystem to keep on burgeoning (www.answers.com/main/ntquery? gwp=13&s=burgeon), and make good use of shared library hosting arrangements such as those provided by code.google.com and the like. This should yield innovation and consolidation, as it has already for some JS libraries, and as it did over the years for C (like JS, C lacks built-in I/O primitives -- teletypes then or URIs now would not fit in the core language).
good point, but could it be possible then to define official namespaces for such case ?
I already see per implementation namespaces: AS3, ECMA4, and surely a JS2 coming
could it be possible to establish some rules and/or procedures for people or group willing to submit these kind of shared library ?
for exemple, having a common API defined in the ECMA4 namespace, and specialized or optimized methods per hosts defined by their respective namespace AS3 being able to reuse some native API found in the flash player, JS2 being able to reuse something as NSPR, etc.
[...]
ECMA would be foolish to try to standardize too much I/O mechanism and the like prematurely, but you and others on es4-discuss should definitely collaborate (and on this list, for now -- we could use the feedback both ways).
but even if ECMA does not standardize such libraries, could they at least endorse it or officialize it some way ?
when you see the gazillion libraries out there, either for Ajax, ActionScript, etc. the main common pattern you can see is that people stick to their libs, and do not agregate their findings in one unified library, so in the case of a URI class I could see 4 or 5 differents implementation made by 4 or 5 different group/people with 4 or 5 different API, which is not good.
Sure, one could argue that the most used library would prevail after some time, but what about the cases where the X library got a better URI class than the Y library, but you still crave to use the String class of the Y library, but sadly URI being based on strings once you start to use the Y library you can not use the URI class of the X library, etc...
No offense to Garrett, but I would not define a URI class this way at all,
for ex using getProtocol/setProtocol function defined in the prototype
make no sens to me, I would use a getter/setter and nothing would go
defined in the prototype, just because I think its cleaner to access
the property like that myURI.protocol.
My point is if each one of us go develop on their side an API, and also 4 or 5 other people/group do the same, in the end does ECMA will be able to say "we favour this one for this and that reasons" ? or does ECMA gonna say nothing and let people struggle with the same libraries problem that exists with ES3 ?
zwetan
On 9/9/07, zwetan <zwetan at gmail.com> wrote:
when you see the gazillion libraries out there, either for Ajax, ActionScript, etc. the main common pattern you can see is that people stick to their libs, and do not agregate their findings in one unified library, so in the case of a URI class I could see 4 or 5 differents implementation made by 4 or 5 different group/people with 4 or 5 different API, which is not good.
Sure, one could argue that the most used library would prevail after some time,
Remember BETA vs. VHS?
but what about the cases where the X library got a better URI class than the Y library, but you still crave to use the String class of the Y library, but sadly URI being based on strings once you start to use the Y library you can not use the URI class of the X library, etc...
The current libraries suffer from worse problems. See the YUI connection manager Prototype.js. The URI logic is inextricable. Users get dependent on the libraries which are not namespaced (ES3) and sometimes conflict by using the $ symbol top-level.
No offense to Garrett, but I would not define a URI class this way at all, for ex using getProtocol/setProtocol function defined in the prototype make no sens to me, I would use a getter/setter and nothing would go defined in the prototype, just because I think its cleaner to access the property like that
myURI.protocol.
We can take that a step further and define a QueryString class that has a toString returning the raw queryString, toEncodedString, returning the encoded queryString, and the parameter map functionality defined in the current URI class.
var foo = aURI.query.getParam("foo"); if(foo == null) { aURI.query.addParameterMap( jsonArg ); };
This would be useful for other things, like POST data, for example.
If this were a wiki, you could edit the page directly or create your own.
You can copy-paste-edit my outline here. I suppose I could use my JotSpot wiki page (Jot is another fine example of a bloated library in action, though this has been and is being refactored by google's experts. Hopefully it won't end up being garbage like google Groups.)
Just one quick word: be careful when designing a URI class that it should be able to deal with URNs, too.
I've decided to propose a URI class to deal with the handling of URIs that is so prevalent in Ajax apps and also in Flash and to a lesser extent, Adobe Reader.
I propose this idea here because noticed that there are other places besides the web that can use it (Flash, Reader). A URI class could be implemented in ES to cover all these needs.
I have a proposal page at www.dhtmlkitchen.com/rec/URI.html
I won't copy paste the entire thing here. It prints on 3 pages if you set margin to 0 and scale to 70%.
Is this the appropriate way to make a proposal?
Garrett