More narwhal "alternate" platforms
4 views
Skip to first unread message
nlloyds
Jun 24, 2009, 10:22:37 PM6/24/09
to Jack and Narwhal
I'm looking into getting Narwhal running on the following platforms:
- Jaxer
- WScript (Windows CLI)
- ASP ("classic")
A few questions:
For WScript, narwhal would run from the command line, as it does with
Rhino and other platforms. bin/narwhal is a Bash script, and wouldn't
run on stock Windows. Would I make a bin/narwhal.bat or something?
I'll probably start with this on my branch once I get that far, but
would would be the preference of others on needing an additional binary
(ies - tusk.bat, sea.bat, etc.?)?
ASP and Jaxer are "page based", for lack of a better term, and would
require something like:
<script runat="server" src="narwhal.js"></script>
<script runat="server">var File = require("file").File; ... </script>
On each script loaded (though there might be ways to load the library
into memory on startup.)
AFAIK, none of the existing platforms work like this, so how would
Narwhal handle these? It would be useful to have access to require,
system, and the Narwhal library on both of these platforms, and
implementing platform drivers (is that the preferred nomenclature?)
would be fairly trivial.
Thanks,
Nathan
- Jaxer
- WScript (Windows CLI)
- ASP ("classic")
A few questions:
For WScript, narwhal would run from the command line, as it does with
Rhino and other platforms. bin/narwhal is a Bash script, and wouldn't
run on stock Windows. Would I make a bin/narwhal.bat or something?
I'll probably start with this on my branch once I get that far, but
would would be the preference of others on needing an additional binary
(ies - tusk.bat, sea.bat, etc.?)?
ASP and Jaxer are "page based", for lack of a better term, and would
require something like:
<script runat="server" src="narwhal.js"></script>
<script runat="server">var File = require("file").File; ... </script>
On each script loaded (though there might be ways to load the library
into memory on startup.)
AFAIK, none of the existing platforms work like this, so how would
Narwhal handle these? It would be useful to have access to require,
system, and the Narwhal library on both of these platforms, and
implementing platform drivers (is that the preferred nomenclature?)
would be fairly trivial.
Thanks,
Nathan
Kris Kowal
Jun 24, 2009, 10:37:54 PM6/24/09
to jac...@googlegroups.com
On Wed, Jun 24, 2009 at 7:22 PM, nlloyds<nll...@gmail.com> wrote:
>
> I'm looking into getting Narwhal running on the following platforms:
>
> - Jaxer
> - WScript (Windows CLI)
> - ASP ("classic")
>
> A few questions:
>
> For WScript, narwhal would run from the command line, as it does with
> Rhino and other platforms. bin/narwhal is a Bash script, and wouldn't
> run on stock Windows. Would I make a bin/narwhal.bat or something?
> I'll probably start with this on my branch once I get that far, but
> would would be the preference of others on needing an additional binary
> (ies - tusk.bat, sea.bat, etc.?)?
>
> I'm looking into getting Narwhal running on the following platforms:
>
> - Jaxer
> - WScript (Windows CLI)
> - ASP ("classic")
>
> A few questions:
>
> For WScript, narwhal would run from the command line, as it does with
> Rhino and other platforms. bin/narwhal is a Bash script, and wouldn't
> run on stock Windows. Would I make a bin/narwhal.bat or something?
> I'll probably start with this on my branch once I get that far, but
> would would be the preference of others on needing an additional binary
> (ies - tusk.bat, sea.bat, etc.?)?
I believe so. You might run into issues with the file system module.
If you're targetting windows, any help in testing and getting the file
system library up to speed for that platform would be appreciated.
> ASP and Jaxer are "page based", for lack of a better term, and would
> require something like:
>
> <script runat="server" src="narwhal.js"></script>
> <script runat="server">var File = require("file").File; ... </script>
I think that for Jaxer and ASP, you can bypass bin/narwhal (which just
finds itself and calls platforms/*/bin/narwhal-*), and you can bypass
platforms/*/bin/narwhal-* (which just finds the engine and executes
platforms/*/bootstrap.js) and go straight to platforms/*/bootstrap.js.
<script runat="server"
src="/path/to/narwhal/platforms/jaxer/bootstrap.js"></script>
bootstrap.js is responsible for creating an initial "system" object
with temporary versions of "isFile", "read", and a few other things,
then evaling "narwhal.js", which returns a function, and passing the
"system" object to that function. Voila.
For client scripts, I'll probably be setting something up like this:
<script src="//url/to/modules.js?main/module"></script>
Or, for cacheability, using a bit of Jack middleware for hosing
bundles with a loader:
<script src="//url/to/modules/main/module.js"></script>
Kris Kowal
nlloyds
Jun 25, 2009, 12:05:06 AM6/25/09
to Jack and Narwhal
Kris,
On Jun 24, 9:37 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
> I believe so. You might run into issues with the file system module.
> If you're targetting windows, any help in testing and getting the file
> system library up to speed for that platform would be appreciated.
I'm sure it will be an adventure :). JScript/WScript does, however,
provide a surprising amount of functionality with the ActiveXObjects
(Scripting.FileSystemObject), and I was reading up on WScript's stdin/
out/args handling and it may be doable. I think the two biggest
hurdles might be:
- In the file object, the difference between /path/to/file and c:\path
\to\file. Resolving these difference might be helpful since Rhino and
others can run on Windows, too.
- In handling errors, it's tough to beat any useful information out of
JScript. The (pre-serverJS) script loader I'm using now points to the
line that the loaded script was eval'd when an error happens, so there
might be some trickery afoot.
> I think that for Jaxer and ASP, you can bypass bin/narwhal (which just
> finds itself and calls platforms/*/bin/narwhal-*), and you can bypass
> platforms/*/bin/narwhal-* (which just finds the engine and executes
> platforms/*/bootstrap.js) and go straight to platforms/*/bootstrap.js.
Great! I'll give it a try.
> For client scripts, I'll probably be setting something up like this:
>
> <script src="//url/to/modules.js?main/module"></script>
>
> Or, for cacheability, using a bit of Jack middleware for hosing
> bundles with a loader:
>
> <script src="//url/to/modules/main/module.js"></script>
For Jaxer, It would be sweet to set it up using Narwhal for
runat="server" and the modules.js loader for runat="client", and be
able to use both transparently. Though I'm more confident in Jack/
Narwhal's future at the moment than that of Jaxer (just a feeling.)
On the ASP side, I feel like a caveman around here (Your world
frightens and confuses me!) On a commercial ASP product I work on,
I've slowly convinced my team the JScript is better than VBScript, and
we're moving toward aligning our internal framework to ServerJS and
moving to a more modern, open, platform in the future. Hopefully I can
help contribute to this effort while on that path.
Thanks for your help.
Nathan
On Jun 24, 9:37 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
> I believe so. You might run into issues with the file system module.
> If you're targetting windows, any help in testing and getting the file
> system library up to speed for that platform would be appreciated.
provide a surprising amount of functionality with the ActiveXObjects
(Scripting.FileSystemObject), and I was reading up on WScript's stdin/
out/args handling and it may be doable. I think the two biggest
hurdles might be:
- In the file object, the difference between /path/to/file and c:\path
\to\file. Resolving these difference might be helpful since Rhino and
others can run on Windows, too.
- In handling errors, it's tough to beat any useful information out of
JScript. The (pre-serverJS) script loader I'm using now points to the
line that the loaded script was eval'd when an error happens, so there
might be some trickery afoot.
> I think that for Jaxer and ASP, you can bypass bin/narwhal (which just
> finds itself and calls platforms/*/bin/narwhal-*), and you can bypass
> platforms/*/bin/narwhal-* (which just finds the engine and executes
> platforms/*/bootstrap.js) and go straight to platforms/*/bootstrap.js.
> For client scripts, I'll probably be setting something up like this:
>
> <script src="//url/to/modules.js?main/module"></script>
>
> Or, for cacheability, using a bit of Jack middleware for hosing
> bundles with a loader:
>
> <script src="//url/to/modules/main/module.js"></script>
runat="server" and the modules.js loader for runat="client", and be
able to use both transparently. Though I'm more confident in Jack/
Narwhal's future at the moment than that of Jaxer (just a feeling.)
On the ASP side, I feel like a caveman around here (Your world
frightens and confuses me!) On a commercial ASP product I work on,
I've slowly convinced my team the JScript is better than VBScript, and
we're moving toward aligning our internal framework to ServerJS and
moving to a more modern, open, platform in the future. Hopefully I can
help contribute to this effort while on that path.
Thanks for your help.
Nathan
Tom Robinson
Jun 25, 2009, 3:27:06 AM6/25/09
to jac...@googlegroups.com
On Jun 24, 2009, at 7:22 PM, nlloyds wrote:
>
> I'm looking into getting Narwhal running on the following platforms:
>
> - Jaxer
> - WScript (Windows CLI)
> - ASP ("classic")
>
> A few questions:
>
> For WScript, narwhal would run from the command line, as it does with
> Rhino and other platforms. bin/narwhal is a Bash script, and wouldn't
> run on stock Windows. Would I make a bin/narwhal.bat or something?
> I'll probably start with this on my branch once I get that far, but
> would would be the preference of others on needing an additional
> binary
> (ies - tusk.bat, sea.bat, etc.?)?
running the Rhino platform on Windows too, so it would be excellent if
someone with more Windows experience than myself could tackle this ;)
>
> ASP and Jaxer are "page based", for lack of a better term, and would
> require something like:
>
> <script runat="server" src="narwhal.js"></script>
> <script runat="server">var File = require("file").File; ... </script>
>
> On each script loaded (though there might be ways to load the library
> into memory on startup.)
>
> AFAIK, none of the existing platforms work like this, so how would
> Narwhal handle these? It would be useful to have access to require,
> system, and the Narwhal library on both of these platforms, and
> implementing platform drivers (is that the preferred nomenclature?)
> would be fairly trivial.
Christoph are working on might actually work in Jaxer since it's
Mozilla based.
You certainly could have a separate Jaxer platform, but if it can be
consolidated into an existing platform without any compromises then I
would do that.
>
> Thanks,
>
> Nathan
> >
nlloyds
Jun 25, 2009, 10:00:32 AM6/25/09
to Jack and Narwhal
Tom,
On Jun 25, 2:27 am, Tom Robinson <tlrobin...@gmail.com> wrote:
> As Kris mentioned, yes. The Windows shell scripts should be useful for
> running the Rhino platform on Windows too, so it would be excellent if
> someone with more Windows experience than myself could tackle this ;)
I wouldn't say I'm some kind of bat file expert, but I'll give it a
shot.
> The mozilla/xpcom/xulrunner platform that Zachary, Irakli, and
> Christoph are working on might actually work in Jaxer since it's
> Mozilla based.
>
> You certainly could have a separate Jaxer platform, but if it can be
> consolidated into an existing platform without any compromises then I
> would do that.
Trying Cristoph's mozilla branch didn't work out of the box, and it
looks like Jaxer's Mozilla might not have all of the same Components
as the platform his is targeting. Jaxer does have some higher level
objects (http://www.aptana.com/reference/jaxer/api/) than those used
in these, so it might be simpler to have a separate platform.
On that same note, would there be any good ways to share platform-
specific code? I have JScript in mind, where the scripting engines are
the same on WScript and ASP, but there are minor differences (ASP has
no STDIN/OUT and needs to map web server directories to paths on disk,
but not much more) and I would hate to make two almost identical
platforms. Any thoughts?
BTW, everyone has been really helpful so far on this group. Now if I
can just get some time to actually write some code I can have some
fun.
Thanks,
Nathan
On Jun 25, 2:27 am, Tom Robinson <tlrobin...@gmail.com> wrote:
> As Kris mentioned, yes. The Windows shell scripts should be useful for
> running the Rhino platform on Windows too, so it would be excellent if
> someone with more Windows experience than myself could tackle this ;)
shot.
> The mozilla/xpcom/xulrunner platform that Zachary, Irakli, and
> Christoph are working on might actually work in Jaxer since it's
> Mozilla based.
>
> You certainly could have a separate Jaxer platform, but if it can be
> consolidated into an existing platform without any compromises then I
> would do that.
looks like Jaxer's Mozilla might not have all of the same Components
as the platform his is targeting. Jaxer does have some higher level
objects (http://www.aptana.com/reference/jaxer/api/) than those used
in these, so it might be simpler to have a separate platform.
On that same note, would there be any good ways to share platform-
specific code? I have JScript in mind, where the scripting engines are
the same on WScript and ASP, but there are minor differences (ASP has
no STDIN/OUT and needs to map web server directories to paths on disk,
but not much more) and I would hate to make two almost identical
platforms. Any thoughts?
BTW, everyone has been really helpful so far on this group. Now if I
can just get some time to actually write some code I can have some
fun.
Thanks,
Nathan
Kris Kowal
Jun 25, 2009, 11:37:50 AM6/25/09
to jac...@googlegroups.com
On Thu, Jun 25, 2009 at 7:00 AM, nlloyds<nll...@gmail.com> wrote:
> On that same note, would there be any good ways to share platform-
> specific code? I have JScript in mind, where the scripting engines are
> the same on WScript and ASP, but there are minor differences (ASP has
> no STDIN/OUT and needs to map web server directories to paths on disk,
> but not much more) and I would hate to make two almost identical
> platforms. Any thoughts?
> On that same note, would there be any good ways to share platform-
> specific code? I have JScript in mind, where the scripting engines are
> the same on WScript and ASP, but there are minor differences (ASP has
> no STDIN/OUT and needs to map web server directories to paths on disk,
> but not much more) and I would hate to make two almost identical
> platforms. Any thoughts?
You may have multiple platforms. For example, Rhino's system object
says {"platform": "rhino", "platforms": ["rhino", "default"]}. Yours
should presumably look like {"platform": "jaxer", "platforms":
["jaxer", "foo", "default"]} to share components with other "foo"
projects. Narwhal composes the platforms into a library search path
giving priority to the first platform in the array, like:
narwhal/platforms/jaxer/lib
narwhal/platforms/foo/lib
narwhal/platforms/default/lib
narwhal/lib
And uses the same order when looking for jars/, packages/, and bin/ directories.
Our current practice is to bifurcate modules with both pure-js
components and platform components into a bar.js module in lib or the
defaults platform and a bar-platform.js module in jaxer/lib or
foo/lib.
Kris Kowal
nlloyds
Jun 27, 2009, 1:03:01 AM6/27/09
to Jack and Narwhal
On Jun 25, 9:00 am, nlloyds <nllo...@gmail.com> wrote:
> Trying Cristoph's mozilla branch didn't work out of the box, and it
> looks like Jaxer's Mozilla might not have all of the same Components
> as the platform his is targeting. Jaxer does have some higher level
> objects (http://www.aptana.com/reference/jaxer/api/) than those used
> in these, so it might be simpler to have a separate platform.
After looking at the Jaxer.File object (in /jaxer/framework/src/
> Trying Cristoph's mozilla branch didn't work out of the box, and it
> looks like Jaxer's Mozilla might not have all of the same Components
> as the platform his is targeting. Jaxer does have some higher level
> objects (http://www.aptana.com/reference/jaxer/api/) than those used
> in these, so it might be simpler to have a separate platform.
File.js), it looks like it's just a wrapper around JSLib, which is a
wrapper around Mozilla's component interface. I started making my
Jaxer Narwhal branch (http://github.com/smith/narwhal/tree/jaxer)
another wrapper around those, but others are doing lower level stuff
that can provide more capabilities than what the Jaxer object provides
out of the box.
For those of you targeting mozilla-based platforms: any thoughts on
making an "official" mozilla platform work with everyone's target
(Firefox, XULRunner, Jaxer, etc.) and building out each platform
specifically on top of that base? Cristoph's branch is using an
extensions component that Jaxer seems to choke on; that's why I'm
looking here.
I'm diving a bit deep here, so any opinions would help (not out of
ocean mammal metaphors yet, though.)
Thanks,
Nathan
Zachary Carter
Jun 27, 2009, 12:47:28 PM6/27/09
to jac...@googlegroups.com
Irakli's xulrunner branch should work, though IIRC it may depend on
some Mozilla 1.9.1 functionality. It's intended to be a generic
platform for all Mozilla/XPConnect based platforms.
--
--
Zach Carter
http://zach.carter.name
some Mozilla 1.9.1 functionality. It's intended to be a generic
platform for all Mozilla/XPConnect based platforms.
--
Zach Carter
http://zach.carter.name
nlloyds
Jun 28, 2009, 1:50:40 PM6/28/09
to Jack and Narwhal
Zachary,
On Jun 27, 11:47 am, Zachary Carter <zack.car...@gmail.com> wrote:
> Irakli's xulrunner branch should work, though IIRC it may depend on
> some Mozilla 1.9.1 functionality. It's intended to be a generic
> platform for all Mozilla/XPConnect based platforms.
The xulrunner branch worked for me.
It looks like Irakli's xulrunner and Cristoph's mozilla are almost
identical, except Cristoph's uses the extension manager which is not
available on Jaxer. It still would be nice to try and eliminate any
duplication.
My Jaxer branch (http://github.com/smith/narwhal/tree/jaxer) "works",
but it limited mostly to what is implemented on Irakli's branch. It
still needs to be included on every page as I haven't been able to get
it to work as a Jaxer extension yet. It should work out well using
lower-level mozilla functionality for most things and the higher level
Jaxer APIs where convenient.
Most of the work needed now, as far as I can tell, will be on the
xulrunner platform, so hopefully I can help out some on that.
Thanks,
Nathan
On Jun 27, 11:47 am, Zachary Carter <zack.car...@gmail.com> wrote:
> Irakli's xulrunner branch should work, though IIRC it may depend on
> some Mozilla 1.9.1 functionality. It's intended to be a generic
> platform for all Mozilla/XPConnect based platforms.
It looks like Irakli's xulrunner and Cristoph's mozilla are almost
identical, except Cristoph's uses the extension manager which is not
available on Jaxer. It still would be nice to try and eliminate any
duplication.
My Jaxer branch (http://github.com/smith/narwhal/tree/jaxer) "works",
but it limited mostly to what is implemented on Irakli's branch. It
still needs to be included on every page as I haven't been able to get
it to work as a Jaxer extension yet. It should work out well using
lower-level mozilla functionality for most things and the higher level
Jaxer APIs where convenient.
Most of the work needed now, as far as I can tell, will be on the
xulrunner platform, so hopefully I can help out some on that.
Thanks,
Nathan
Christoph Dorn
Jul 9, 2009, 9:01:07 PM7/9/09
to jac...@googlegroups.com
Sorry about my late reply. I was away camping for 10 days.
> It looks like Irakli's xulrunner and Cristoph's mozilla are almost
> identical, except Cristoph's uses the extension manager which is not
> available on Jaxer. It still would be nice to try and eliminate any
> duplication.
>
I will be looking at the merged xulrunner platform [1] and updating my
fork with any required patches to arrive at a single xulrunner base
platform.
> Most of the work needed now, as far as I can tell, will be on the
> xulrunner platform, so hopefully I can help out some on that.
>
That would be great. As far as I know there is still a lot missing.
Christoph
[1] - http://github.com/tlrobinson/narwhal/tree/master/platforms/xulrunner
Reply all
Reply to author
Forward
0 new messages