MozillaWiki - User contributions [en]

ServerJS/HTTP Client/A

2009-09-04T03:07:30Z

IsaacSchlueter: /* Example Implementation */

Proposal A, Draft 1

'''Status: Proposal'''

The "http-client" module exposes an HTTPClient constructor that creates an HTTP Client object.

== Constructor: HTTPClient(settings) ==

If called as a simple function, then return a new HTTPClient(settings).

Set all protected members to the default values.

If a settings object is included, call this.set(settings).

== Object Methods ==

All methods return "this" except where otherwise specified.

=== set([settings object | key, value]) ===

Set the body, headers, method, or url, or any combination thereof in the settings object. Attribute validity is enforced (see valid settings on members, below.)

=== setHeader(key, val) ===

Set a header on the header object in a case-insensitive manner. That is, if the user sets "content-type", and then later sets "Content-Type", then the first setting is lost.

=== setHeaders(headers:Object) ===

Set a bunch of headers expressed as name-value pairs.

=== write(data:toByteString-able) ===

Append data to the outgoing request. (That is, to the iterable body object.)

Implementers MAY require the body object to expose a push() method, and call this push() method to append data to the request.

=== connect() ===

Open the connection to the URL using the method supplied. If the method or url is missing, throw an error.

After connecting, write() will have no effect.

Calling connect() SHOULD NOT block the application, but MUST initiate the HTTP request.

=== read() ===

Read the request and return a JSGI-style object consisting of <code>{status:Integer, headers:Objecct, body:Iterable<ByteString>}</code>.

Calling read() SHOULD NOT block the application until the request is completed, but it MUST open the input stream such that the data can be read.

=== finish() ===

Alias for .connect().read()

== Static Methods ==

=== decode(response[, encoding]) ===

Return a response object where the body has been wrapped in a decoder middleware.

For example:

<pre>resp.body = {forEach : function (block) {
raw.forEach(function (i) {
block(i.decodeToString(encoding));
});
}};</pre>

Make a best-guess attempt to determine the appropriate encoding based on the response headers if no encoding is specified. The ultimate fallback encoding SHOULD be UTF-8.

=== unDecode(response) ===

Replace the decoded body with the original body. This is useful when the decoded content is clearly invalid and the consumer wants to backtrack.

== Members ==

All members below are required and SHOULD be protected.

=== body ===

An iterable (that is <code>forEach</code>-able) object where forEach iterates over items with a <code>toByteString</code> method.

Implementers MAY require that the body member expose a <code>push</code> method in order for the write function to operate properly.

Default value: []

=== headers ===

A hash of request headers. Care SHOULD be taken to ensure that keys are added in a case-insensitive manner.

Default value: {"X-Requested-With" : "CommonJS HTTP Client"}

=== method ===

The request method as a string.

Default value: "GET"

=== url ===

URL as a string

Default value: none

== Example Implementation ==

* Isaac's Narwhal fork: [http://github.com/isaacs/narwhal/blob/master/lib/http-client.js code], [http://github.com/isaacs/narwhal-playground/blob/master/http-client.js usage], [http://github.com/isaacs/narwhal-playground/blob/master/http-client-blocking-test.js concurrent demonstration]

ServerJS/HTTP Client/A

2009-09-04T03:06:32Z

IsaacSchlueter:

ServerJS/HTTP Client/A

2009-09-04T03:03:01Z

IsaacSchlueter: /* Example Implementation */

Proposal A, Draft 1

'''Status: Proposal'''

The "http-client" module exposes an HTTPClient constructor that creates an HTTP Client object.

== Object Methods ==

All methods return "this" except where otherwise specified.

=== set([settings object | key, value]) ===

Set the body, headers, method, or url, or any combination thereof in the settings object. Attribute validity is enforced (see valid settings on members, below.)

=== setHeader(key, val) ===

Set a header on the header object in a case-insensitive manner. That is, if the user sets "content-type", and then later sets "Content-Type", then the first setting is lost.

=== setHeaders(headers:Object) ===

Set a bunch of headers expressed as name-value pairs.

=== write(data:toByteString-able) ===

Append data to the outgoing request. (That is, to the iterable body object.)

Implementers MAY require the body object to expose a push() method, and call this push() method to append data to the request.

=== connect() ===

Open the connection to the URL using the method supplied. If the method or url is missing, throw an error.

After connecting, write() will have no effect.

Calling connect() SHOULD NOT block the application, but MUST initiate the HTTP request.

=== read() ===

Read the request and return a JSGI-style object consisting of <code>{status:Integer, headers:Objecct, body:Iterable<ByteString>}</code>.

Calling read() SHOULD NOT block the application until the request is completed, but it MUST open the input stream such that the data can be read.

=== finish() ===

Alias for .connect().read()

== Static Methods ==

=== decode(response[, encoding]) ===

Return a response object where the body has been wrapped in a decoder middleware.

For example:

<pre>resp.body = {forEach : function (block) {
raw.forEach(function (i) {
block(i.decodeToString(encoding));
});
}};</pre>

Make a best-guess attempt to determine the appropriate encoding based on the response headers if no encoding is specified. The ultimate fallback encoding SHOULD be UTF-8.

=== unDecode(response) ===

Replace the decoded body with the original body. This is useful when the decoded content is clearly invalid and the consumer wants to backtrack.

== Members ==

All members below are required and SHOULD be protected.

=== body ===

An iterable (that is <code>forEach</code>-able) object where forEach iterates over items with a <code>toByteString</code> method.

Implementers MAY require that the body member expose a <code>push</code> method in order for the write function to operate properly.

Default value: []

=== headers ===

A hash of request headers. Care SHOULD be taken to ensure that keys are added in a case-insensitive manner.

Default value: {"X-Requested-With" : "CommonJS HTTP Client"}

=== method ===

The request method as a string.

Default value: "GET"

=== url ===

URL as a string

Default value: none

== Example Implementation ==

* Isaac's Narwhal fork: [http://github.com/isaacs/narwhal/blob/master/lib/http-client.js code], [http://github.com/isaacs/narwhal-playground/blob/master/http-client.js usage]

ServerJS/HTTP Client/A

2009-09-04T03:02:40Z

IsaacSchlueter:

Proposal A, Draft 1

'''Status: Proposal'''

The "http-client" module exposes an HTTPClient constructor that creates an HTTP Client object.

== Object Methods ==

All methods return "this" except where otherwise specified.

=== set([settings object | key, value]) ===

Set the body, headers, method, or url, or any combination thereof in the settings object. Attribute validity is enforced (see valid settings on members, below.)

=== setHeader(key, val) ===

Set a header on the header object in a case-insensitive manner. That is, if the user sets "content-type", and then later sets "Content-Type", then the first setting is lost.

=== setHeaders(headers:Object) ===

Set a bunch of headers expressed as name-value pairs.

=== write(data:toByteString-able) ===

Append data to the outgoing request. (That is, to the iterable body object.)

Implementers MAY require the body object to expose a push() method, and call this push() method to append data to the request.

=== connect() ===

Open the connection to the URL using the method supplied. If the method or url is missing, throw an error.

After connecting, write() will have no effect.

Calling connect() SHOULD NOT block the application, but MUST initiate the HTTP request.

=== read() ===

Read the request and return a JSGI-style object consisting of <code>{status:Integer, headers:Objecct, body:Iterable<ByteString>}</code>.

Calling read() SHOULD NOT block the application until the request is completed, but it MUST open the input stream such that the data can be read.

=== finish() ===

Alias for .connect().read()

== Static Methods ==

=== decode(response[, encoding]) ===

Return a response object where the body has been wrapped in a decoder middleware.

For example:

<pre>resp.body = {forEach : function (block) {
raw.forEach(function (i) {
block(i.decodeToString(encoding));
});
}};</pre>

Make a best-guess attempt to determine the appropriate encoding based on the response headers if no encoding is specified. The ultimate fallback encoding SHOULD be UTF-8.

=== unDecode(response) ===

Replace the decoded body with the original body. This is useful when the decoded content is clearly invalid and the consumer wants to backtrack.

== Members ==

All members below are required and SHOULD be protected.

=== body ===

An iterable (that is <code>forEach</code>-able) object where forEach iterates over items with a <code>toByteString</code> method.

Implementers MAY require that the body member expose a <code>push</code> method in order for the write function to operate properly.

Default value: []

=== headers ===

A hash of request headers. Care SHOULD be taken to ensure that keys are added in a case-insensitive manner.

Default value: {"X-Requested-With" : "CommonJS HTTP Client"}

=== method ===

The request method as a string.

Default value: "GET"

=== url ===

URL as a string

Default value: none

== Example Implementation ==

* Isaac's Narwhal branch on github: [http://github.com/isaacs/narwhal/blob/master/lib/http-client.js code], [http://github.com/isaacs/narwhal-playground/blob/master/http-client.js usage]

ServerJS/HTTP Client/A

2009-09-04T02:58:16Z

IsaacSchlueter:

Proposal A, Draft 1

'''Status: Proposal'''

The "http-client" module exposes an HTTPClient constructor that creates an HTTP Client object.

== Object Methods ==

All methods return "this" except where otherwise specified.

=== set([settings object | key, value]) ===

Set the body, headers, method, or url, or any combination thereof in the settings object. Attribute validity is enforced (see valid settings on members, below.)

=== setHeader(key, val) ===

Set a header on the header object in a case-insensitive manner. That is, if the user sets "content-type", and then later sets "Content-Type", then the first setting is lost.

=== setHeaders(headers:Object) ===

Set a bunch of headers expressed as name-value pairs.

=== write(data:toByteString-able) ===

Append data to the outgoing request. (That is, to the iterable body object.)

Implementers MAY require the body object to expose a push() method, and call this push() method to append data to the request.

=== connect() ===

Open the connection to the URL using the method supplied. If the method or url is missing, throw an error.

After connecting, write() will have no effect.

=== read() ===

Read the request and return a JSGI-style object consisting of <code>{status:Integer, headers:Objecct, body:Iterable<ByteString>}</code>.

=== finish() ===

Alias for .connect().read()

== Static Methods ==

=== decode(response[, encoding]) ===

Return a response object where the body has been wrapped in a decoder middleware.

For example:

<pre>resp.body = {forEach : function (block) {
raw.forEach(function (i) {
block(i.decodeToString(encoding));
});
}};</pre>

Make a best-guess attempt to determine the appropriate encoding based on the response headers if no encoding is specified. The ultimate fallback encoding SHOULD be UTF-8.

=== unDecode(response) ===

Replace the decoded body with the original body. This is useful when the decoded content is clearly invalid and the consumer wants to backtrack.

== Members ==

All members below are required and SHOULD be protected.

=== body ===

An iterable (that is <code>forEach</code>-able) object where forEach iterates over items with a <code>toByteString</code> method.

Implementers MAY require that the body member expose a <code>push</code> method in order for the write function to operate properly.

Default value: []

=== headers ===

A hash of request headers. Care SHOULD be taken to ensure that keys are added in a case-insensitive manner.

Default value: {"X-Requested-With" : "CommonJS HTTP Client"}

=== method ===

The request method as a string.

Default value: "GET"

=== url ===

URL as a string

Default value: none

ServerJS/HTTP Client/A

2009-09-04T02:57:15Z

IsaacSchlueter: adding members

Proposal A, Draft 1

'''Status: Proposal'''

The "http-client" module exposes an HTTPClient constructor that creates an HTTP Client object.

== Object Methods ==

All methods return "this" except where otherwise specified.

=== set([settings object | key, value]) ===

Set the body, headers, method, or url, or any combination thereof in the settings object. Attribute validity is enforced (see valid settings on members, below.)

=== setHeader(key, val) ===

Set a header on the header object in a case-insensitive manner. That is, if the user sets "content-type", and then later sets "Content-Type", then the first setting is lost.

=== setHeaders(headers:Object) ===

Set a bunch of headers expressed as name-value pairs.

=== write(data:toByteString-able) ===

Append data to the outgoing request. (That is, to the iterable body object.)

Implementers MAY require the body object to expose a push() method, and call this push() method to append data to the request.

=== connect() ===

Open the connection to the URL using the method supplied. If the method or url is missing, throw an error.

After connecting, write() will have no effect.

=== read() ===

Read the request and return a JSGI-style object consisting of {status:Integer, headers:Objecct, body:Iterable<ByteString>}.

=== finish() ===

Alias for .connect().read()

== Static Methods ==

=== decode(response[, encoding]) ===

Return a response object where the body has been wrapped in a decoder middleware.

For example:

<pre><code>resp.body = {forEach : function (block) {
raw.forEach(function (i) {
block(i.decodeToString(encoding));
});
}};</code></pre>

Make a best-guess attempt to determine the appropriate encoding based on the response headers if no encoding is specified. The ultimate fallback encoding SHOULD be UTF-8.

=== unDecode(response) ===

Replace the decoded body with the original body. This is useful when the decoded content is clearly invalid and the consumer wants to backtrack.

== Members ==

All members below are required and SHOULD be protected.

=== body ===

An iterable (that is <code>forEach</code>-able) object where forEach iterates over items with a <code>toByteString</code> method.

Implementers MAY require that the body member expose a <code>push</code> method in order for the write function to operate properly.

Default value: []

=== headers ===

A hash of request headers. Care SHOULD be taken to ensure that keys are added in a case-insensitive manner.

Default value: {"X-Requested-With" : "CommonJS HTTP Client"}

=== method ===

The request method as a string.

Default value: "GET"

=== url ===

URL as a string

Default value: none

ServerJS/HTTP Client/A

2009-09-04T02:52:47Z

IsaacSchlueter: Initial draft

ServerJS/HTTP Client/A

2009-09-04T02:36:30Z

IsaacSchlueter: Created page with 'nothing here yet.'

nothing here yet.

ServerJS/HTTP Client

2009-09-04T02:35:57Z

IsaacSchlueter:

= HTTP Client API =

Server side programs often need to grab information via HTTP. There should be an API that makes this as easy as possible.

There are certainly other protocols that deserve support, but each protocol has its own purpose and interface and will be documented separately if it will become part of the stdlib.

== Requirements/Proposals ==

[[ServerJS/HTTP_Client/A|HTTPClient Proposal A]]

== Prior Art ==

* [http://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest] is already the standard JS API for HTTP.
* [http://www.ejscript.org/products/ejs/doc/api/gen/ejscript/ejs.io-Http.html Here] is an extended HTTP API from Ejscript.
* v8cgi has a [http://code.google.com/p/v8cgi/wiki/API_HTTP HTTP] class
* Helma NG has a [http://dev.helma.org/trac/helma/browser/helma-ng/trunk/modules/helma/httpclient.js helma/httpclient module] ([http://helma.zumbrunn.com/reference/helma.Http.html Helma 1 reference docs]).

ServerJS/HTTP Client

2009-09-04T02:35:25Z

IsaacSchlueter: add link to proposal

= HTTP Client API =

Server side programs often need to grab information via HTTP. There should be an API that makes this as easy as possible.

There are certainly other protocols that deserve support, but each protocol has its own purpose and interface and will be documented separately if it will become part of the stdlib.

== Requirements/Proposals ==

[[HTTP_Client/A]]

== Prior Art ==

* [http://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest] is already the standard JS API for HTTP.
* [http://www.ejscript.org/products/ejs/doc/api/gen/ejscript/ejs.io-Http.html Here] is an extended HTTP API from Ejscript.
* v8cgi has a [http://code.google.com/p/v8cgi/wiki/API_HTTP HTTP] class
* Helma NG has a [http://dev.helma.org/trac/helma/browser/helma-ng/trunk/modules/helma/httpclient.js helma/httpclient module] ([http://helma.zumbrunn.com/reference/helma.Http.html Helma 1 reference docs]).

User:IsaacSchlueter

2009-09-04T00:31:49Z

IsaacSchlueter:

Isaac Schlueter is a programmer who lives in Silicon Valley. He is currently involved with [[ServerJS|the CommonJS group]], and works on [http://yuilibrary.com/ YUI] during the day.

User:IsaacSchlueter

2009-09-04T00:31:21Z

IsaacSchlueter: Created page with 'Isaac Schlueter is a programmer who lives in Silicon Valley. He is currently involved with the CommonJS group, and works on http://yuilibrary.com/ YUI during th…'

Isaac Schlueter is a programmer who lives in Silicon Valley. He is currently involved with [[ServerJS|the CommonJS group]], and works on [[http://yuilibrary.com/ YUI]] during the day.

ServerJS/ProposalProcess

2009-09-04T00:25:39Z

IsaacSchlueter: practically impractical!

'''STATE: DISCUSSION'''

We adopt a [http://www.perlfoundation.org/perl5/index.cgi?jfdi JFDI] policy regarding adding proposals to CommonJS.

As long as the page makes the level of acceptance clear with a line at the top, it's not a problem.

== State 1: "Proposed" ==

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

== State 2: "Discussion" ==

"Let's talk about my idea!"

Send a message to [http://groups.google.com/group/commonjs CommonJS] with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

If you have an opinion, share it now. If you don't care one way or the other, then stay out of it.

=== Silence is not consent. ===

''Some'' discussion must occur for the idea to progress to "official accepted" status. If someone suggests something, and no one responds, then the idea remains open indefinitely.

If you suggest something, and no one else speaks up in favor of it, that doesn't mean it's a bad idea. However, this is probably something that you should just put in your own application, and it most likely does not belong in the CommonJS specification. This bit of inertia prevents us from building specifications no one wants.

The flip side of this: if someone suggests something, and you think it's a good idea, ''Speak up!''

=== Unanimity is Suspect ===

There may be cases when everyone involved in the discussion is in favor of the proposal. This probably means that someone's voice isn't being heard.

In the case of a completely one-sided discussion, make some effort to figure out who might be against it, and try to ping them directly, or at least wait until they weigh in on it before considering the issue closed. It could be that they didn't feel strongly in the first place, or that they've been swayed by the arguments from the other side. But there was probably a reason for their initial resistance, and it should be heard.

== State 3: "Decided" ==

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

== State 4: "Implemented" ==

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.

A proposal ''only'' reaches this state by virtue of being implemented in more than one library. At this point, it is considered a standard, and implementers can rest assured that it will not change without good reason.

ServerJS/Process

2009-09-04T00:23:21Z

IsaacSchlueter: Add link to Proposal Process proposal

The goal of this project is to have something that people can run and build web frameworks and applications on.

The process needs to support that goal, plus the goal of having a specification that allows people to make other JS interpreters/platforms compatible.

There are two parts to the process:

<ol><li>Creating the specs and code<li>Handling disagreements</ol>

Number 1 is how things get done. Number 2 is how we ensure that number 1 is able to continue in face of inevitable disagreements.

* [[ServerJS/ProposalProcess|CommonJS Proposal Process]]

(to be continued...)

== Prior Art ==

* [http://www.python.org/dev/peps/pep-0001/ Python Enhancement Proposal] (PEP). This process is not completely applicable, because Python has a dictator that keeps things from spiraling out of control.
* [http://srfi.schemers.org/ Scheme Requests For Implementation]
* [http://en.wikipedia.org/wiki/Request_for_Comments#RFC_production_and_evolution Request for Comments] (RFC)
* [http://www.apache.org/foundation/voting.html Apache Voting]

== Related Discussions ==

* [http://groups.google.com/group/commonjs/browse_thread/thread/280c8b0375783604 Organisation and Making Decisions]

ServerJS/Process

2009-09-04T00:19:39Z

IsaacSchlueter: fix broken link

The goal of this project is to have something that people can run and build web frameworks and applications on.

The process needs to support that goal, plus the goal of having a specification that allows people to make other JS interpreters/platforms compatible.

There are two parts to the process:

<ol><li>Creating the specs and code<li>Handling disagreements</ol>

Number 1 is how things get done. Number 2 is how we ensure that number 1 is able to continue in face of inevitable disagreements.

(to be continued...)

== Prior Art ==

* [http://www.python.org/dev/peps/pep-0001/ Python Enhancement Proposal] (PEP). This process is not completely applicable, because Python has a dictator that keeps things from spiraling out of control.
* [http://srfi.schemers.org/ Scheme Requests For Implementation]
* [http://en.wikipedia.org/wiki/Request_for_Comments#RFC_production_and_evolution Request for Comments] (RFC)
* [http://www.apache.org/foundation/voting.html Apache Voting]

== Related Discussions ==

* [http://groups.google.com/group/commonjs/browse_thread/thread/280c8b0375783604 Organisation and Making Decisions]

ServerJS/Process

2009-09-04T00:18:22Z

IsaacSchlueter:

The goal of this project is to have something that people can run and build web frameworks and applications on.

The process needs to support that goal, plus the goal of having a specification that allows people to make other JS interpreters/platforms compatible.

There are two parts to the process:

<ol><li>Creating the specs and code<li>Handling disagreements</ol>

Number 1 is how things get done. Number 2 is how we ensure that number 1 is able to continue in face of inevitable disagreements.

(to be continued...)

== Prior Art ==

* [http://www.python.org/dev/peps/pep-0001/ Python Enhancement Proposal] (PEP). This process is not completely applicable, because Python has a dictator that keeps things from spiraling out of control.
* [http://srfi.schemers.org/ Scheme Requests For Implementation]
* [http://en.wikipedia.org/wiki/Request_for_Comments#RFC_production_and_evolution Request for Comments] (RFC)
* [http://www.apache.org/foundation/voting.html Apache Voting]

== Related Discussions ==

* [http://groups.google.com/group/serverjs/browse_thread/thread/280c8b0375783604 Organisation and Making Decisions]

ServerJS/ProposalProcess

2009-09-04T00:15:18Z

IsaacSchlueter:

'''STATE: DISCUSSION'''

We adopt a [http://www.perlfoundation.org/perl5/index.cgi?jfdi JFDI] policy regarding adding proposals to CommonJS.

As long as the page makes the level of acceptance clear with a line at the top, it's not a problem.

== State 1: "Proposed" ==

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

== State 2: "Discussion" ==

"Let's talk about my idea!"

Send a message to [http://groups.google.com/group/commonjs CommonJS] with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

If you have an opinion, share it now. If you don't care one way or the other, then stay out of it.

=== Silence is not consent. ===

''Some'' discussion must occur for the idea to progress to "official accepted" status. If someone suggests something, and no one responds, then the idea remains open indefinitely.

If you suggest something, and no one else speaks up in favor of it, that doesn't mean it's a bad idea. However, this is probably something that you should just put in your own application, and it most likely does not belong in the CommonJS specification. This bit of inertia prevents us from building specifications no one wants.

The flip side of this: if someone suggests something, and you think it's a good idea, ''Speak up!''

=== Unanimity is Suspect ===

There may be cases when everyone involved in the discussion is in favor of the proposal. This probably means that someone's voice isn't being heard.

In the case of a completely one-sided discussion, make some effort to figure out who might be against it, and try to ping them directly, or at least wait until they weigh in on it before considering the issue closed. It could be that they didn't feel strongly in the first place, or that they've been swayed by the arguments from the other side. But there was probably a reason for their initial resistance, and it should be heard.

== State 3: "Decided" ==

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid practical reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

== State 4: "Implemented" ==

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.

A proposal ''only'' reaches this state by virtue of being implemented in more than one library. At this point, it is considered a standard, and implementers can rest assured that it will not change without good reason.

ServerJS/ProposalProcess

2009-09-03T23:44:25Z

IsaacSchlueter: Input from Kris Kowal

STATE: DISCUSSION

I propose that we adopt a [http://www.perlfoundation.org/perl5/index.cgi?jfdi JFDI] policy regarding adding proposals CommonJS.

As long as the page makes the level of acceptance clear with a link at the top, it shouldn't be a problem.

== State 1: "Proposed" ==

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

== State 2: "Discussion" ==

"Let's talk about my idea!"

Send a message to [http://groups.google.com/group/commonjs CommonJS] with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

If you have an opinion, share it now. If you don't care one way or the other, then stay out of it.

=== Silence is not consent. ===

''Some'' discussion must occur for the idea to progress to "official accepted" status. If someone suggests something, and no one responds, then the idea remains open indefinitely.

If you suggest something, and no one else speaks up in favor of it, that doesn't mean it's a bad idea. However, this is probably something that you should just put in your own application, and it most likely does not belong in the CommonJS specification. This bit of inertia prevents us from building specifications no one wants.

The flip side of this: if someone suggests something, and you think it's a good idea, ''Speak up!''

=== Unanimity is Suspect ===

There may be cases when everyone involved in the discussion is in favor of the proposal. This probably means that someone's voice isn't being heard.

In the case of a completely one-sided discussion, make some effort to figure out who might be against it, and try to ping them directly, or at least wait until they weigh in on it before considering the issue closed. It could be that they didn't feel strongly in the first place, or that they've been swayed by the arguments from the other side. But there was probably a reason for their initial resistance, and it should be heard.

== State 3: "Decided" ==

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid practical reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

== State 4: "Implemented" ==

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.

A proposal ''only'' reaches this state by virtue of being implemented in more than one library. At this point, it is considered a standard, and implementers can rest assured that it will not change without good reason.

ServerJS/ProposalProcess

2009-09-03T23:42:29Z

IsaacSchlueter: Input from Kris Kowal

ServerJS/ProposalProcess

2009-09-03T19:55:10Z

IsaacSchlueter:

ServerJS/ProposalProcess

2009-09-03T19:52:03Z

IsaacSchlueter:

STATE: PROPOSED

I propose that we adopt a [http://www.perlfoundation.org/perl5/index.cgi?jfdi JFDI] policy regarding adding proposals CommonJS.

As long as the page makes the level of acceptance clear with a link at the top, it shouldn't be a problem.

== State 1: "Proposed" ==

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

== State 2: "In Discussion" ==

"Let's talk about my idea!"

Send a message to [http://groups.google.com/group/commonjs CommonJS] with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

Speak now or forever hold your peace.

== State 3: "Decided" ==

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid practical reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

== State 4: "Implemented" ==

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.

ServerJS/ProposalProcess

2009-09-03T19:51:23Z

IsaacSchlueter: A modest proposal for proposals

STATE: PROPOSED

I propose that we adopt a [http://www.perlfoundation.org/perl5/index.cgi?jfdi JFDI] policy regarding adding proposals CommonJS.

As long as the page makes the level of acceptance clear with a link at the top, it shouldn't be a problem.

== State 1: "Proposed" ==

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

== Stage 2: "In Discussion" ==

"Let's talk about my idea!"

Send a message to [http://groups.google.com/group/commonjs CommonJS] with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

Speak now or forever hold your peace.

== Stage 3: "Decided" ==

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid practical reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

== Stage 4: "Implemented" ==

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.