URI Proposal

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

URI Proposal

Garrett Smith
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 http://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

--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: URI Proposal

Brendan Eich-2
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).

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).

/be

On Sep 7, 2007, at 2:29 PM, Garrett Smith wrote:

> 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 http://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
>
> --
> Programming is a collaborative art.
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: URI Proposal

zwetan-3
very interesting subject, but this one can raise a lot of issues imho


On 9/8/07, Brendan Eich <[hidden email]> 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
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: URI Proposal

Garrett Smith
On 9/9/07, zwetan <[hidden email]> 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.)

> 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
>


--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: URI Proposal

David Teller-3
In reply to this post by Garrett Smith
Just one quick word: be careful when designing a URI class that it
should be able to deal with URNs, too.

Cheers,
 David

On Fri, 2007-09-07 at 14:29 -0700, Garrett Smith wrote:

> 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 http://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
>
--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss