ServerJS/System: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (→‎System Interface Proposal A: added sections for proponents and comments)
 
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= System Interface =


= System Interface Proposal A =
All platforms must support a module, "system", that may contain the following attributes.


All platforms support a free variable, "sys", that is an object that may contain the following attributes.  The "sys" variable may be either a global variable, an argument to every module factory function, or inserted into a module scope by some other means.  "sys" may be used for dependency injection in sandboxes, so it may be frozen.  Therefore, the variable must not be reassigned, or modified in interoperable modules, although it may be mutable and reassignable in particular platforms.
If "system" contains any of the following names, they must have the corresponding meaning:
 
If "sys" contains any of the following names, they must have the corresponding meaning:


* stdin: the standard input stream, an object with the same API as a file opened with the mode "r" with no encoding.
* stdin: the standard input stream, an object with the same API as a file opened with the mode "r" with no encoding.
* stdout: the standard output stream, an object with the same API as a file opened with the mode "w" with no encoding.
* stdout: the standard output stream, an object with the same API as a file opened with the mode "w" with no encoding.
* stderr: the standard error stream, an object with the same API as a file opened with the mode "w" with no encoding.
* stderr: the standard error stream, an object with the same API as a file opened with the mode "w" with no encoding.
* environment: an Object containing posix-style or CGI environment variables.
* env: an Object containing posix-style or CGI environment variables.
* arguments: an Array containing the command line arguments for the invoking arguments, not including the interpreter/engine but including the path to the program as it was executed.
* args: an Array containing the command line arguments for the invoking arguments, not including the interpreter/engine but including the path to the program as it was executed. See also the [[ServerJS/Command Line|Command Line page]].
 
Any names not mentioned here or amended into this specification later should begin with "x" and a vendor-specific label as a prefix, like system.xCajaDomita.  This will permit the future standardization of additional names as needed. Please request additional standard names below.
 
= Compliant Implementations =
 
* [http://github.com/tlrobinson/narwhal/ Narwhal]
* [http://flusspferd.org/ Flusspferd] (in 0.7)
* [http://github.com/hns/helma-ng/ Helma NG] (in 0.4)
 
= Additional proposed names =
 
The following names have been proposed but not ratified for inclusion in the System proposal.
 
* print: The "system" MAY have a "print" function that forwards its thisp and arguments to "system.stdout.print" with lazy binding (meaning that, if system.stdout is replaced, print MUST forward to the new stdout).
 
* log: The "system" MAY have a "log" function that accepts a "message" and an optional "label" String.
** The label MAY be one of "log", "debug", "warn", "error", "pass", "fail".
** Any other, unspecified label MUST be in lower-case and begin with "x" and a vendor-specific label like "x-v8cgi-database".
 
* platform: the "system" MAY contain a string with its vendor-specific platform name.
 
* global: the "system" MAY contain a reference to the global object.
 
== Removed proposals ==
 
* fs: a file default file system root object conforming to the File System API
* fs: a file default file system root object conforming to the File System API


Proponents: Kris Kowal
* print (proposal A): The "system" MAY have a "print" function that accepts a "message" and an optional "label" String.
** The label MAY be one of "log", "warn", "error", "pass", "fail".
** Any other, unspecified label MUST be in lower-case and begin with "x" and a vendor-specific label like "x-v8cgi-database".
** '''Counter-argument''' This is infact not printing, but logging. 1) there is lots of logging frameworks, 2) it probably doesn't belong on sys, certainl not called ''print''
*** '''Counter-argument''' However, ''print'' has meant to write a line to stdout in many languages.  That it would frequently be used for logging in non-stdio contexts is not necessarily relevant.
 
= Show of Hands =
 
[[ServerJS/System/ArchivedShowOfHands]]
 
== Relevant Discussions ==


== Comments ==
* [http://groups.google.com/group/serverjs/browse_thread/thread/4f6c16e2f4c14c25/7c10fe164ead35c0?lnk=gst Module System feedback]
* [http://groups.google.com/group/serverjs/browse_thread/thread/749c3777f62cf34 System API Proposal]

Latest revision as of 15:49, 14 August 2009

System Interface

All platforms must support a module, "system", that may contain the following attributes.

If "system" contains any of the following names, they must have the corresponding meaning:

  • stdin: the standard input stream, an object with the same API as a file opened with the mode "r" with no encoding.
  • stdout: the standard output stream, an object with the same API as a file opened with the mode "w" with no encoding.
  • stderr: the standard error stream, an object with the same API as a file opened with the mode "w" with no encoding.
  • env: an Object containing posix-style or CGI environment variables.
  • args: an Array containing the command line arguments for the invoking arguments, not including the interpreter/engine but including the path to the program as it was executed. See also the Command Line page.

Any names not mentioned here or amended into this specification later should begin with "x" and a vendor-specific label as a prefix, like system.xCajaDomita. This will permit the future standardization of additional names as needed. Please request additional standard names below.

Compliant Implementations

Additional proposed names

The following names have been proposed but not ratified for inclusion in the System proposal.

  • print: The "system" MAY have a "print" function that forwards its thisp and arguments to "system.stdout.print" with lazy binding (meaning that, if system.stdout is replaced, print MUST forward to the new stdout).
  • log: The "system" MAY have a "log" function that accepts a "message" and an optional "label" String.
    • The label MAY be one of "log", "debug", "warn", "error", "pass", "fail".
    • Any other, unspecified label MUST be in lower-case and begin with "x" and a vendor-specific label like "x-v8cgi-database".
  • platform: the "system" MAY contain a string with its vendor-specific platform name.
  • global: the "system" MAY contain a reference to the global object.

Removed proposals

  • fs: a file default file system root object conforming to the File System API
  • print (proposal A): The "system" MAY have a "print" function that accepts a "message" and an optional "label" String.
    • The label MAY be one of "log", "warn", "error", "pass", "fail".
    • Any other, unspecified label MUST be in lower-case and begin with "x" and a vendor-specific label like "x-v8cgi-database".
    • Counter-argument This is infact not printing, but logging. 1) there is lots of logging frameworks, 2) it probably doesn't belong on sys, certainl not called print
      • Counter-argument However, print has meant to write a line to stdout in many languages. That it would frequently be used for logging in non-stdio contexts is not necessarily relevant.

Show of Hands

ServerJS/System/ArchivedShowOfHands

Relevant Discussions