URI Proposal

[zwetan]

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 (http://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