Noob questions

[GWBasic]

I'm starting to look through js.io with the intention of implementing
CSP on my server, and I'm coming up with some silly noob questions:

---

1: Does js.io have to reside in the /jsio folder on my server? I see
a lot of .js files in the distribution, and a lot of jsio("import blah
blah blah...") stuff.

1a: So is js.io dynamically choosing dependencies in *production/
release* mode? (As opposed to enabling debugging features

1b: Assuming that in production mode, the libraries loaded are known
ahead of time, what are they?*

* (I'm trying to take advantage of some Javascript optimizations that
my server provides.)

---

2: The "world" sample program index.js uses a bunch of calls to $,
but I'm not sure who's defining it. Is js.io defining $? Is js.io
magically including jQuery or Prototype?

2a: Is there a way to disable / bypass $ so I can use js.io with
existing programs that use Prototype or jQuery?

---

3: The Comet Session Protocol states: "The server is recommended to
serve a fully functioning CSP client, and that client should put a
CometSession constructor in the global namespace. The client should be
located at the url:" (http://orbited.org/blog/files/csp.html, section
3.1.)

Again, regarding the "world" sample program: I can find a csp.js
within the js.io subdirectory, but I can't find a "static" folder. Am
I missing something here?

---

Please forgive my noobiness.

[Michael Carter]

On Fri, Oct 30, 2009 at 2:25 PM, GWBasic <goo...@andrewrondeau.com> wrote:

I'm starting to look through js.io with the intention of implementing
CSP on my server, and I'm coming up with some silly noob questions:

---

1:  Does js.io have to reside in the /jsio folder on my server?  I see
a lot of .js files in the distribution, and a lot of jsio("import blah
blah blah...") stuff.

No, js.io can reside anywhere. When you're in "development mode" it will figure out where the package is located based on the src attribute of the script tag you use to include jsio.js. In "production mode" you will have compiled the scripts into a single file anyway, and it won't need to fetch any additional resources.
 

1a:  So is js.io dynamically choosing dependencies in *production/
release* mode?  (As opposed to enabling debugging features

jsio will dynamically choose dependancies in "production mode" , but it will first look in its pre-compiled cache. You can compile a jsio script with any of the depdenancies you want. For instance, if 95% of your users need jsio.foo, but only 5% need jsio.bar, then it might make sense to just compile jsio.foo into your release, and have the remaining 5% fetch jsio.bar when they actually need it.

1b:  Assuming that in production mode, the libraries loaded are known
ahead of time, what are they?*

the jsio compiler can be given a html file, a .js file, or a .pkg file, which it will use to resolve all dependancies and compile them. If you want to be explicit, you would just create a dependancies.js file that only has imports in it, something like:

jsio('import foo')
jsio('import jsio.bar')

This would let you control exactly whats being compiled by then running the compiler against dependancies.js
 

* (I'm trying to take advantage of some Javascript optimizations that
my server provides.)

---

2:  The "world" sample program index.js uses a bunch of calls to $,
but I'm not sure who's defining it.  Is js.io defining $?  Is js.io
magically including jQuery or Prototype?

The world sample is using sizzle, and the $ is not a global function. Sizzle is just a query selector. You can add it to a local namesapce by importing it, like so:

jsio('from jsio.util.browser import $');

But you can have another script that just uses prototype or jquery. If you want to use sizzle and prototype in the same module, you can do something like this:

jsio('from jsio.util.browser import $ as jsio$');

This would allow you to use both at once with no naming conflicts.
 

2a:  Is there a way to disable / bypass $ so I can use js.io with
existing programs that use Prototype or jQuery?

see above

---

3:  The Comet Session Protocol states:  "The server is recommended to
serve a fully functioning CSP client, and that client should put a
CometSession constructor in the global namespace. The client should be
located at the url:"  (http://orbited.org/blog/files/csp.html, section
3.1.)

Again, regarding the "world" sample program:  I can find a csp.js
within the js.io subdirectory, but I can't find a "static" folder.  Am
I missing something here?

No you aren't missing anything. I believe that our world example (and most of our servers) fail to follow the recommendation.

p.s: for the latest spec, check the csp repo: http://orbited.org/svn/csp/trunk/spec . We'll be releasing a 0.4 spec early next week from the repo. There are a few minor updates there.

 

---

Please forgive my noobiness.

Considering we have no js.io library documentation, your questions are very well informed.

-Michael Carter

[GWBasic]

So what is the "compiler?" Is it just a Javascript minimizer that
concatenates all the files together?

> p.s: for the latest spec, check the csp repo:http://orbited.org/svn/csp/trunk/spec. We'll be releasing a 0.4 spec early