A idea whose time has come
psvensson
I felt a shock of recognition. I've heard this once before, from
Márion Valente (http://mv.asterisco.pt/) when we met a couple of
months ago during the SAPO Codebits conference in Lisbon.
I'll let Mário lay out the words for that of course :) but the gist of
it was that there is no common API for different SSJS implementations.
They remain isolated islands when it comes to file access, and the
like. I've been so caught up with the joy of finally doing some SSJS
at all that I've not really thought of the fact that I'm always using
Rhino, and an unhealthy Java dependency.
In a recent mail discussion, I suggested that we try to list the areas
that need to be implemented, see if they already _are_ implemented on
a high level in some existing Ajax toolkit (I'm thinking very much
Dojo here, of course..) and then see which parts we rally have to
implement 'on the metal'. That will then form the necessary API for
all SSJS platforms. Easy as cake, eh? :)
WDYT?
Cheers,
PS
Kevin Dangoor
>
> Reading Kevin's article at http://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/
> I felt a shock of recognition. I've heard this once before, from
> Márion Valente (http://mv.asterisco.pt/) when we met a couple of
> months ago during the SAPO Codebits conference in Lisbon.
I think there are a lot of people thinking along these lines. Tom
Robinson, from yesterday:
http://groups.google.com/group/jack-js/msg/02df426d23679623
"Even if the implementation depends on Java, we should try to
coordinate the user facing APIs."
I figured it's time to funnel all of that energy and thought into
*creating* the world we all want.
> In a recent mail discussion, I suggested that we try to list the areas
> that need to be implemented, see if they already _are_ implemented on
> a high level in some existing Ajax toolkit (I'm thinking very much
> Dojo here, of course..) and then see which parts we rally have to
> implement 'on the metal'. That will then form the necessary API for
> all SSJS platforms. Easy as cake, eh? :)
Before joining Mozilla this month, I was working at SitePen alongside
the Dojo folks and that gave me a good chance to experience Dojo
firsthand. Prior to that, I was the founder of the TurboGears project
in Python.
I really think that the needs of server side code are different enough
than the needs of client side code that we're better off drawing from
Python and Ruby than from Dojo and jQuery. That said, with solid
"medium level" (JDBC-style APIs, a decent File API, etc.) APIs as a
given, there will be all sorts of fertile ground for exploration of
the client/server boundary.
I do think there are server side implementations of most everything
we'd need already, but they are indeed isolated little islands and the
goal is to break off that isolation.
Kevin
Peter Svensson
I think there are a lot of people thinking along these lines. Tom
On Thu, Jan 29, 2009 at 11:12 AM, psvensson <psve...@gmail.com> wrote:
>
> Reading Kevin's article at http://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/
> I felt a shock of recognition. I've heard this once before, from
> Márion Valente (http://mv.asterisco.pt/) when we met a couple of
> months ago during the SAPO Codebits conference in Lisbon.
Robinson, from yesterday:
http://groups.google.com/group/jack-js/msg/02df426d23679623
"Even if the implementation depends on Java, we should try to
coordinate the user facing APIs."
Agreed.
I figured it's time to funnel all of that energy and thought into
*creating* the world we all want.
Before joining Mozilla this month, I was working at SitePen alongside
> In a recent mail discussion, I suggested that we try to list the areas
> that need to be implemented, see if they already _are_ implemented on
> a high level in some existing Ajax toolkit (I'm thinking very much
> Dojo here, of course..) and then see which parts we rally have to
> implement 'on the metal'. That will then form the necessary API for
> all SSJS platforms. Easy as cake, eh? :)
the Dojo folks and that gave me a good chance to experience Dojo
firsthand. Prior to that, I was the founder of the TurboGears project
in Python.
I really think that the needs of server side code are different enough
than the needs of client side code that we're better off drawing from
Python and Ruby than from Dojo and jQuery. That said, with solid
"medium level" (JDBC-style APIs, a decent File API, etc.) APIs as a
given, there will be all sorts of fertile ground for exploration of
the client/server boundary.
I do think there are server side implementations of most everything
we'd need already, but they are indeed isolated little islands and the
goal is to break off that isolation.
OK. One thing on the top of my head is 10gen's Mongo ORM, which feels quite a bit like the db.Model of Google App Engine. It's just been spun off in a separate open source project, and I don't think you can make things simpler than that.
http://www.mongodb.org/
Cheers,
PS
Kevin
Kris Zyp
biggest concern here is that we would take a progressive idea like SSJS
and try to apply antiquated server-side API concepts. I would love to
have Persevere be able to support a common API with SSJS envs, but I
wouldn't want it to have to degrade to old request-response/HTML
generation paradigms and JDBC style APIs. As far as data interaction
(which does seem completely orthogonal to the HTTP interaction to me), I
think we have mostly evolved past JDBC interaction, so I would certainly
be a supporter of some standardized ORM-style API. Dojo has made efforts
in that area (although it has greater expectation for async than would
be needed in the server), and I have attempted to create an API in
Persevere that could be used by other systems in
http://docs.persvr.org/documentation/server-side-js (load, commit,
rollback, remove, getAccessLevel, getId, isPersisted, authenticate,
...). Or perhaps you are simply interested in defining APIs for lower
level servers (and I guess it would simply not apply for Persevere).
Anyway, there is *a lot* (virtually limitless) areas out there that one
could tackle, not sure how much of the world you are wanting to take on
here, and what scope you had in mind here.
Kris
Dion Almaer
There are a LOT of JavaScript libraries out there than do the same thing slightly differently (e.g. toml talking about 15 different "File" APIs). How about looking at what has been done and codifying it, NOT trying to set new ground such as Enterprise JavaScript Beans? :)
Kris Zyp
Dion Almaer wrote:
> Good points Kris. I totally agree. I don't want to copy from the like
> of JDBC, but rather copy from what JavaScript frameworks are already
> doing (e.g. Perserve and others).
>
> There are a LOT of JavaScript libraries out there than do the same
> thing slightly differently (e.g. toml talking about 15 different
> "File" APIs). How about looking at what has been done and codifying
> it, NOT trying to set new ground such as Enterprise JavaScript Beans? :)
I agree, standardization and interoperability efforts can be at their
best when it converges and brings harmony to what existing
implementations are doing. And I assume not many SSJS impls are trying
to create Enterprise JavaScript Beans :). But there is probably a lot of
areas where there are opportunities for convergence in very beneficial ways.
Thanks,
Kris
Robert Schultz
standardized set of interfaces for various tasks.
A standardized 'File' interface for working with files on disk.
One for working with relational databases.
Another for working with parsing XML.
What if we tackled the problem backwards.
Say it's 20 years in the future and you need to write some code that
parses some XML from a file on the disk and then inserts entries into
a relational database.
What would be the PERFECT API you could envision to use.
The simplest, cleanest, most straightforward JavaScript API to
accomplish the tasks mentioned above.
I think it's really important to not be influenced too much by past
efforts.
As JavaScript programmers we have a lot of awesome flexibility in the
language itself.
Some truly great things we can do in terms of dynamic typing,
closures, event oriented approaches, etc.
Then once you have a dream API, and API that would simply feel awesome
to use if it existed, then it's just a matter of implementing it.
There you'll have lots of different implementations. Some will prefer
to use Java, others Spidermonkey or V8.
I've been thinking about server side javascript for a few months now,
even started some code myself with Spidermonkey and another project
with V8 to try some things out.
Kevin Dangoor
> I am certainly a supporter of finding paths for interoperability. My
> biggest concern here is that we would take a progressive idea like SSJS
> and try to apply antiquated server-side API concepts.
I both agree and disagree.
> I would love to
> have Persevere be able to support a common API with SSJS envs, but I
> wouldn't want it to have to degrade to old request-response/HTML
> generation paradigms and JDBC style APIs.
IIRC, Persevere has a way to store its data in a relational database,
doesn't it? Am I correct in assuming that you use JDBC to talk to the
database, rather than offering your own drivers for each database
engine?
That is precisely my point... Something like JDBC or Python's DBAPI is
certainly lower level than one would ideally want to work these days.
However, JavaScript environments don't even have that low level
standard to build upon!
Ideally Persevere would work in Rhino and Spidermonkey equally well
without you having to change a line of code.
> As far as data interaction
> (which does seem completely orthogonal to the HTTP interaction to me), I
> think we have mostly evolved past JDBC interaction, so I would certainly
> be a supporter of some standardized ORM-style API.
A "standardized ORM" is a harder sale than a "standardized RDBMS
access layer". There are those who have more object-oriented engines
like Persevere, there's the Active Record pattern popularized by Rails
and there's the Data Mapper pattern used by SQLAlchemy and Hibernate.
Trying to get people to agree at that level of application
architecture may be a bit premature.
> Dojo has made efforts
> in that area (although it has greater expectation for async than would
> be needed in the server), and I have attempted to create an API in
> Persevere that could be used by other systems in
> http://docs.persvr.org/documentation/server-side-js (load, commit,
> rollback, remove, getAccessLevel, getId, isPersisted, authenticate,
> ...). Or perhaps you are simply interested in defining APIs for lower
> level servers (and I guess it would simply not apply for Persevere).
My personal hope (and I should note that I'm not in charge here...
just facilitating) is that we can start by providing better low level
infrastructure that allows for more high level experimentation. As
mentioned above, I see no reason why Persevere couldn't just be
launched on v8, if the libraries were there.
> Anyway, there is *a lot* (virtually limitless) areas out there that one
> could tackle, not sure how much of the world you are wanting to take on
> here, and what scope you had in mind here.
I gave some notion of my thoughts on scope in my blog post. I want to
see JS reach the state where it's on par (or better, because we avoid
some of the acknowledged mistakes) with Python and Ruby.
Start by providing better infrastructure for server side JS and then
seeing where we can collaboratively build up from there.
Kevin
Kevin Dangoor
>
> It seems what everyone is really talking about, really wanting, is a
> standardized set of interfaces for various tasks.
Yes (and auxiliary tooling like a package repository, etc.)
> A standardized 'File' interface for working with files on disk.
> One for working with relational databases.
> Another for working with parsing XML.
>
> What if we tackled the problem backwards.
>
> Say it's 20 years in the future and you need to write some code that
> parses some XML from a file on the disk and then inserts entries into
> a relational database.
> What would be the PERFECT API you could envision to use.
> The simplest, cleanest, most straightforward JavaScript API to
> accomplish the tasks mentioned above.
Yes.
> I think it's really important to not be influenced too much by past
> efforts.
> As JavaScript programmers we have a lot of awesome flexibility in the
> language itself.
> Some truly great things we can do in terms of dynamic typing,
> closures, event oriented approaches, etc.
Agreed, but I also think it's worth taking the ideas that work well.
For example, WSGI has been very successful in Python land (in much the
same way that the Servlet spec has been successful for Java), as a way
to connect servers and applications. WSGI is lower level than people
would typically want to work. But that's okay... it's existence as a
low level spec has enabled all kinds of interoperable servers, apps
and middleware components that can be plugged in.
So, I agree that we want great APIs, but we want great APIs that allow
for experimentation on all kinds of other ideas that we're not going
to think of right now.
> I've been thinking about server side javascript for a few months now,
> even started some code myself with Spidermonkey and another project
> with V8 to try some things out.
Great! And this is one of the reasons that I set this group up. It
turns out that there are quite a few people out there building
independently who could all benefit from a bit of shared
infrastructure.
Kevin
Peter Svensson
Also, I feel that my ORM idea should be translated down to low level API, so that one could use the SSJS ORM framework of choice.
Thanks!
Cheers,
PS
Chris Zumbrunn
my opinion be nice especially because it would allow higher level
modules to be shared between different server-side javascript
environments. One problem that has slowed this from happening in the
past has been that in Java-based environments like Helma, Sling and
Xjs, Rhino makes the direct scripting of Java packages so easy, that
some stakeholders don't believe the added burden of maintaining an
additional API layer in javascript is reasonable for the benefit they
would get from it.
Let me provide some pointers to current server-side javascript library
projects in the realm of the Helma project and to other efforts for a
standard library for JS that haven't been mentioned yet:
The current Helma 1 versions come with two libraries containing
several modules. The HelmaLib provides modules for core functionality
such as Database, File, Ftp, Http, Smtp and SSH, some that extend
built-in prototypes, and a few others. The Jala library adds further
modules such as DNS, MP3 and XML-RPC and utility modules such as i18n,
image manipulation, captcha, HtmlDocument, RemoteContent, Podcast, Rss
and other XML related modules.
http://dev.helma.org/wiki/HelmaLib/
http://dev.orf.at/trac/jala/wiki/JalaModules
Modules are included either via a configuration file or at runtime via
a method call. A module is only loaded once, even if included multiple
times. In the context of Helma 1, modules are loaded into the global
scope and they need to be nice and restrict themselves to a save
namespace.
For Helma NG, the way modules are included is changed to eliminate any
possible namespace conflicts. Each module in Helma NG lives in its own
scope and can selectively import other modules or portions thereof
into its own scope. Here again, when modules are imported in different
scopes, each module is only actually loaded once.
http://dev.helma.org/ng/
http://dev.helma.org/ng/Modules+and+Scopes/
There has been some discussion with the goal of a unified library/
modules architecture between different projects over in the Helma NG
group. One of the major goals in Peter Michaux's xjs project is to
provide a standard library and a shared module loading mechanism.
http://groups.google.com/group/helma-ng/browse_thread/thread/79afcdef68a2aa55
http://peter.michaux.ca/articles/module-management-cpan-gems-and-xjs
http://groups.google.com/group/helma-ng/browse_thread/thread/b4db68575a3fa729
Chris
Starr Horne
> certainly lower level than one would ideally want to work these days.
> However, JavaScript environments don't even have that low level
> standard to build upon!
should be to create a consistent, low level platform that can then be
built upon by others.
One problem that I see with current SSJS implementations is that they
tend to focus too much on being web stacks. It's a JS-as-php or JS-as-
coldfusion approach. And personally, I think it's limited and
shortsighted.
A much more powerful approach would be to fill out JS as a decent
multi-purpose language like python. Provide a single interpreter with
god's blessing (ala cpython). Provide a compact, well tested, well
documented standard library. Then get out of people's way and let them
build whatever ORM or web framework they like.
Ycros
be the platform upon which people can build their fancy high-level
frameworks.
Kevin Dangoor
> A much more powerful approach would be to fill out JS as a decent
> multi-purpose language like python. Provide a single interpreter with
> god's blessing (ala cpython).
In this particular case, JS has an unusual position in that it doesn't
really need a single blessed interpreter... there are several good
ones available and a spec they need to conform to. They're just really
missing a fleshed out stdlib and the ecosystem that comes along with
that.
JS is actually getting a lot of benefit from having competing interpreters.
Kevin
Malte
JavaScript Enterprise Edition :)
http://joose-js.blogspot.com/2008/10/js2ee-javascript-enterprise-edition.html
We are currently using it to develop application logic inside the
Demandware platform (which is a SaaS solution for ecommerce websites)
and it goes really well (The software is using Rhino internally).
While being overkill on the client side in many cases, it feels like
Joose can really help make JS more standardized and expressive on the
server side.
Bye
Malte
On 29 Jan., 18:02, Dion Almaer <dalm...@gmail.com> wrote:
> Good points Kris. I totally agree. I don't want to copy from the like of
> JDBC, but rather copy from what JavaScript frameworks are already doing
> (e.g. Perserve and others).
>
> There are a LOT of JavaScript libraries out there than do the same thing
> slightly differently (e.g. toml talking about 15 different "File" APIs). How
> about looking at what has been done and codifying it, NOT trying to set new
> ground such as Enterprise JavaScript Beans? :)
>
>
> > I am certainly a supporter of finding paths for interoperability. My
> > biggest concern here is that we would take a progressive idea like SSJS
> > and try to apply antiquated server-side API concepts. I would love to
> > have Persevere be able to support a common API with SSJS envs, but I
> > wouldn't want it to have to degrade to old request-response/HTML
> > generation paradigms and JDBC style APIs. As far as data interaction
> > (which does seem completely orthogonal to the HTTP interaction to me), I
> > think we have mostly evolved past JDBC interaction, so I would certainly
> > be a supporter of some standardized ORM-style API. Dojo has made efforts
> > in that area (although it has greater expectation for async than would
> > be needed in the server), and I have attempted to create an API in
> > Persevere that could be used by other systems in
> > ...). Or perhaps you are simply interested in defining APIs for lower
> > level servers (and I guess it would simply not apply for Persevere).
> > Anyway, there is *a lot* (virtually limitless) areas out there that one
> > could tackle, not sure how much of the world you are wanting to take on
> > here, and what scope you had in mind here.
>
> > Kris
>
> > Kevin Dangoor wrote:
>
> > >> Reading Kevin's article at
Kris Zyp
Kevin Dangoor wrote:
> On Thu, Jan 29, 2009 at 11:53 AM, Kris Zyp <kri...@gmail.com> wrote:
>
>> I am certainly a supporter of finding paths for interoperability. My
>> biggest concern here is that we would take a progressive idea like SSJS
>> and try to apply antiquated server-side API concepts.
>>
>
> I both agree and disagree.
>
>
>> I would love to
>> have Persevere be able to support a common API with SSJS envs, but I
>> wouldn't want it to have to degrade to old request-response/HTML
>> generation paradigms and JDBC style APIs.
>>
>
> IIRC, Persevere has a way to store its data in a relational database,
> doesn't it? Am I correct in assuming that you use JDBC to talk to the
> database, rather than offering your own drivers for each database
> engine?
>
> That is precisely my point... Something like JDBC or Python's DBAPI is
> certainly lower level than one would ideally want to work these days.
> However, JavaScript environments don't even have that low level
> standard to build upon!
>
> Ideally Persevere would work in Rhino and Spidermonkey equally well
> without you having to change a line of code.
>
That's fine, good to know exactly what you were looking for. However, in
Persevere, one of the benefits is that the code paths are so short
between querys/JS property accesses and database queries. Adding more
layers of abstractions always sounds like a nice idea, but it's naive to
think that you can maintain the same performance, and I wouldn't be
likely to run Persevere's object mapping system on top of JS DBAPI. This
partly due to performance but also because the leakiness of the ORM
abstraction when in implemented in JS vs at the VM level. However, I
would probably willing to implement a DBAPI on top of the ORM layer
though ;).
Kris
Starr Horne
> really need a single blessed interpreter... there are several good
> ones available and a spec they need to conform to. They're just really
> missing a fleshed out stdlib and the ecosystem that comes along with
> that.
one am grateful. :)
The only reason I mentioned having a standard interpreter for
'marketing' reasons. There
should be a default that new users can apt-get and start using
immediately, even if it's not the best
interpreter for a specific application.
This does raise an interesting question. What's the best way to make a
standard library that's
usable across multiple JS engines? The way I see it, we have two
options.
1) Create a single library then provide adapters for each of the JS
engines.
2) Make an airtight spec, then implement the library for each JS
engine
The big complication, of course is the fact that some JS interpreters
are written in Java and
some in C.
What do you think?
JS engines,
Malte Ubl
>
>> In this particular case, JS has an unusual position in that it doesn't
>> really need a single blessed interpreter... there are several good
>> ones available and a spec they need to conform to. They're just really
>> missing a fleshed out stdlib and the ecosystem that comes along with
>> that.
>
>
> True. JS interpreters just keep getting faster and faster. And I for
> one am grateful. :)
>
> The only reason I mentioned having a standard interpreter for
> 'marketing' reasons. There
> should be a default that new users can apt-get and start using
> immediately, even if it's not the best
> interpreter for a specific application.
>
> This does raise an interesting question. What's the best way to make a
> standard library that's
> usable across multiple JS engines? The way I see it, we have two
> options.
>
> 1) Create a single library then provide adapters for each of the JS
> engines.
> 2) Make an airtight spec, then implement the library for each JS
> engine
Why do you think one would need a compatibility lib? To access the
underlying API?
In my experience the actual implementations are amazingly compatible
when it comes to the language and it's edges.
Ycros
> This does raise an interesting question. What's the best way to make a
> standard library that's
> usable across multiple JS engines? The way I see it, we have two
> options.
>
> 1) Create a single library then provide adapters for each of the JS
> engines.
> 2) Make an airtight spec, then implement the library for each JS
> engine
then all you need to do is get the test runner running on your target
interpreter - and then you just fix all the tests. This approach seems
to work well for the various Python implementations (well, that and
having good documentation).
Tom Robinson
should work across interpreters.
But it's the lower level things where you need to poke holes through
the interpreter into the underlying system where the compatibility
issues arise: access to the filesystem, database, network, etc.
-Tom
Robin Berjon
> The only reason I mentioned having a standard interpreter for
> 'marketing' reasons. There
> should be a default that new users can apt-get and start using
> immediately, even if it's not the best
> interpreter for a specific application.
I don't think that's needed even for "marketing" reasons. People will
get the one that best fits their needs (e.g. a Java one if they want
to integrate with Java, or the one that is easiest to install for
their platform) and failing that they'll get the one they find when
Googling. It's not a big issue in itself.
What we do need is interoperability between those multiple
implementations. For that I think we need three things:
- a clear specification of what constitutes CoreJS (or however we
call it). This can be like documentation but it might be worth making
it tighter than documentation usually is trading readability for
strictness;
- a thorough test suite;
- a well-defined extension mechanism to add third-party libraries.
The latter may seem superfluous for interoperability but it's not. If
there is no well-defined way of adding a library then vendors will be
very tempted to build extensions straight into their implementations.
And once that happens, you're going down the browser wars again.
> This does raise an interesting question. What's the best way to make a
> standard library that's
> usable across multiple JS engines? The way I see it, we have two
> options.
>
> 1) Create a single library then provide adapters for each of the JS
> engines.
> 2) Make an airtight spec, then implement the library for each JS
> engine
You need both. You write (2) and use feedback from (1) (preferably
multiple instances of 1) to interatively fix the spec until everyone
is happy.
> The big complication, of course is the fact that some JS interpreters
> are written in Java and
> some in C.
That's an issue if we want to integrate libraries from C (well, the
system) or Java (or various other languages). I don't think that's an
issue for the core standard (i.e. the *small* part that produces a
useful platform). But it's going to be an issue for extensions. I
think that people should be allowed to bridge to whatever other
language they want, and we need to deal with that. One way I think
this could work is by making it clear in the extensions packaging
(using some metadata) that an extension requires a given library and
of what type, or if it's pure JS. That way people would know which
extensions they can install on which implementation, and also a
package manager (I'm thinking something like cpan, pear, or gem) could
pick the right extension if there are multiple implementations of it.
--
Robin Berjon
Robineko (http://robineko.com/)
mvalente
On Jan 29, 4:12 pm, psvensson <psvens...@gmail.com> wrote:
> Reading Kevin's article athttp://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-n...
> Márion Valente (http://mv.asterisco.pt/) when we met a couple of
> months ago during the SAPO Codebits conference in Lisbon.
>
discussed
it with a group of local hackers back in 2005.
http://mv.asterisco.pt/2007/Jul/cat.cgi?Server%20Side%20Javascript
I was, of course, laughed out of the room :-)
> I'll let Mário lay out the words for that of course :) but the gist of
> it was that there is no common API for different SSJS implementations.
>
platform (ie. Rhino). But if you want to use an independent
interpreter
(ie. Spidermonkey, V8 or Squirrelfish) its a whole mess. Just for
files
you different ways of instantiating the object, different methods,
differrent
semantics....
This stuff needs to be standardized if we want SSJS to go head to
head
with PHP, Python and Ruby (notice I didnt mention Rails :-)
> They remain isolated islands when it comes to file access, and the
> like. I've been so caught up with the joy of finally doing some SSJS
> at all that I've not really thought of the fact that I'm always using
> Rhino, and an unhealthy Java dependency.
>
and memory footprint. Yes, memory is cheap. The silicon one. Mine
is not. And all the Java baggage (beans, EE, JSRs, JDBC) does take
a lot of brainpower.
> In a recent mail discussion, I suggested that we try to list the areas
> that need to be implemented, see if they already _are_ implemented on
> a high level in some existing Ajax toolkit (I'm thinking very much
> Dojo here, of course..) and then see which parts we rally have to
> implement 'on the metal'. That will then form the necessary API for
> all SSJS platforms. Easy as cake, eh? :)
>
looking
to get out of SSJS: a language/interpreter/API on which to build (or
have
someone build :-) a Zope-like web framework:
---------------
No staging, not really. Like you said before, I just have stuff that
I want to get done and I'd like it to be in JS. But I'd like
something
that replicates the good stuff in my previous Python/Zope
environment:
http://www.zope.org/WhatIsZope/ZopeArchitecture
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZopeArchitecture.stx
So basically:
- an OO database, capable of storing full JS objects; access done via
REST HTTP and objects represented and delivered as JSON docs
- an appserver, capable of running the retrieved objects from the DB
and present results of computation as REST accessible, JSON format
docs
- a JS-based webserver to support both the previous components and
other "stuff" (like delivering the HTML pages/views that will
access
the appserver through AJAX calls)
That would be about it. I know have in github/starbucks the basis for
the first component (OO db) and am working/thinking-hard about the
2nd
(appserver). My focus right now is on a "proof of concept", no
worries
about code quality or performance.
---------------
Like I said, I have started to build/hack a proof of concept, based
on the
jslibs spidermonkey-extended platform. With the plain understanding
that I'm writing to an API that isnt available anywhere else (ie.
code wont
be portable to any other JS platform).
-- MV
mvalente
On Jan 29, 4:27 pm, Kevin Dangoor <dang...@gmail.com> wrote:
> "Even if the implementation depends on Java, we should try to
> coordinate the user facing APIs."
>
> I figured it's time to funnel all of that energy and thought into
> *creating* the world we all want.
>
from Mozilla and I'm glad that its now being done and that Kevin is
on board (at onetime TurboGears was my option to switch away from
Zope; and then JS sidetracked me ;-)
> I really think that the needs of server side code are different enough
> than the needs of client side code that we're better off drawing from
> Python and Ruby than from Dojo and jQuery. That said, with solid
> "medium level" (JDBC-style APIs, a decent File API, etc.) APIs as a
> given, there will be all sorts of fertile ground for exploration of
> the client/server boundary.
>
system.
> I do think there are server side implementations of most everything
> we'd need already, but they are indeed isolated little islands and the
> goal is to break off that isolation.
>
language is spoken at the island. Or better, have a standard way to
speak to each island. I really dont care whether V8 implementation
of File is bad, better than Spidermonkey's, or equal to Squirrelfish:
I
just want to know that I can do "var f = new File();" and it'll be
the same
in each one.
-- MV
mvalente
> OK. One thing on the top of my head is 10gen's Mongo ORM, which feels quite
> a bit like the db.Model of Google App Engine. It's just been spun off in a
> separate open source project, and I don't think you can make things simpler
> than that.
>
- I dont think Mongo is an ORM
- I dont think that an ORM should be our worry; our worry should be
the
ability of people to write an ORM using Javascript
- as far as thing goes I would prefer CouchDB as a model
- I hate ORMs :-)
-- MV
mvalente
On Jan 29, 4:53 pm, Kris Zyp <kris...@gmail.com> wrote:
> I am certainly a supporter of finding paths for interoperability. My
> biggest concern here is that we would take a progressive idea like SSJS
> and try to apply antiquated server-side API concepts. I would love to
> have Persevere be able to support a common API with SSJS envs,
>
ideas
or any high level stuff but just put enough in place that one could
take
the source to Persevere and run it on any one of the JS interpreters
(C based, Rhino based, etc)
>As far as data interaction
> (which does seem completely orthogonal to the HTTP interaction to me), I
> think we have mostly evolved past JDBC interaction, so I would certainly
> be a supporter of some standardized ORM-style API.
should
be left for people to build with the JS basics. If some standardized
way of
doing data interaction is to be standardized upon then I would most
definitely propose that it be a REST-based JSON-formatted way. Let
the
RDBMSs and ORMs and whatnot provide that sort of interface (either
native or through a gateway/adapter)
-- MV
mvalente
> access layer".
standard REST-based JSON-formatted access layer" :-)
> Trying to get people to agree at that level of application
> architecture may be a bit premature.
>
-- MV
mvalente
> > It seems what everyone is really talking about, really wanting, is a
> > standardized set of interfaces for various tasks.
>
> Yes (and auxiliary tooling like a package repository, etc.)
>
and lived a
long time before having such a thing). But I think that if its to be
done, it should
be done by Mozilla. There's already some basis for it (FF .xpi files
and the extensions
repository)
-- MV
mvalente
> I agree with Kevin here and I think the purpose of any SSJS standard
> should be to create a consistent, low level platform that can then be
> built upon by others.
>
> multi-purpose language like python. Provide a single interpreter with
> god's blessing (ala cpython). Provide a compact, well tested, well
> documented standard library. Then get out of people's way and let them
> build whatever ORM or web framework they like.
that there
was only one, but I also see advantages in having multiple
interpreter
versions. As long as they implement the same API.
-- MV
Peter Svensson
freenode #serverjs
Cheers,
PS
mvalente
> standard library that's
> usable across multiple JS engines? The way I see it, we have two
> options.
>
> 1) Create a single library then provide adapters for each of the JS
> engines.
> 2) Make an airtight spec, then implement the library for each JS
> engine
>
JS engine owner :-)
I think thats what this Mozilla initiative and this group is all
about: defining
a spec for (mostly) serverside functionality to be implemented by
each JS
engine (much like the spec for Array or Object).
I say mostly because I think that some of the spec definitions
should then
influence (or be influenced by) the clientside JS (ex: a Socket class
should
be the same at serverside and clientside; on the other hand it should
probably
follow the Web Sockets standard...)
-- MV
Robin Berjon
>>> It seems what everyone is really talking about, really wanting, is a
>>> standardized set of interfaces for various tasks.
>>
>> Yes (and auxiliary tooling like a package repository, etc.)
>
> I'm not that sure about the package repository (Python has thrived
> and lived a
> long time before having such a thing).
I know a fair bunch of people, myself included, who played a bit with
Python in its earlier days but didn't go farther because it didn't
have a package repository. When done right (like CPAN) it's a killer
feature.
> But I think that if its to be
> done, it should
> be done by Mozilla. There's already some basis for it (FF .xpi files
> and the extensions
> repository)
I think it should be done by whoever does it well enough first :) I
pinged the OpenJSAN folks to see if they might be interested.
Kris Zyp
mvalente wrote:
>
> On Jan 29, 4:53 pm, Kris Zyp <kris...@gmail.com> wrote:
>
>> I am certainly a supporter of finding paths for interoperability. My
>> biggest concern here is that we would take a progressive idea like SSJS
>> and try to apply antiquated server-side API concepts. I would love to
>> have Persevere be able to support a common API with SSJS envs,
>>
>>
>
> Yes, I think that this should be the goal. Not to define any old
> ideas
> or any high level stuff but just put enough in place that one could
> take
> the source to Persevere and run it on any one of the JS interpreters
> (C based, Rhino based, etc)
>
>
FWIW, I would envision Persevere probably being more on the side of an
implementor of the APIs than a consumer, but it would probably be on
both sides to some degree.
>
>
>> As far as data interaction
>> (which does seem completely orthogonal to the HTTP interaction to me), I
>> think we have mostly evolved past JDBC interaction, so I would certainly
>> be a supporter of some standardized ORM-style API.
>>
>
> I do not agree with this one. I think that any ORM-style interaction
> should
> be left for people to build with the JS basics. If some standardized
> way of
> doing data interaction is to be standardized upon then I would most
> definitely propose that it be a REST-based JSON-formatted way. Let
> the
> RDBMSs and ORMs and whatnot provide that sort of interface (either
> native or through a gateway/adapter)
>
I think you are right that it would be best for this group to avoid
tacking ORM standardization, or RDBMS standardization probably. It looks
like there are more than enough issues to tackle at the moment.
And in regards to ORM, unfortunately you can't create an ORM in JS that
is anywhere near the quality of what you can do at the JS VM level. The
whole point of an ORM is to provide a means for objects to be bound to
data, such that they actually look like objects. If you take the
conservative approach of avoiding getters and setters you can't even
close, anything that would take some interaction with a data store
requires an API. If you do you getters and setters you are better off,
but still have very leaky abstractions and poor performance (getters and
setters in most JS VMs are about 10-50x slower, whereas writing native
code can actually be faster). The high performance air-tight
abstractions are one of the key benefits of Persevere, this level of
quality simply could not be achieved as a JS library.
Kris
Peter Michaux
> - I dont think that an ORM should be our worry; our worry should be
> the ability of people to write an ORM using Javascript
Agreed!
Peter
Peter Michaux
>
>
>> > It seems what everyone is really talking about, really wanting, is a
>> > standardized set of interfaces for various tasks.
>>
>> Yes (and auxiliary tooling like a package repository, etc.)
>>
>
> I'm not that sure about the package repository (Python has thrived
> and lived a
> long time before having such a thing).
I think the repository is very important. My guess is Perl would
likely have died by now without CPAN. When someone asks "why Perl?"
most of the time the answer is "CPAN". So it isn't the Perl language
that is so persuasively wonderful, it is the community around it.
> But I think that if its to be
> done, it should
> be done by Mozilla. There's already some basis for it (FF .xpi files
> and the extensions
> repository)
I think think that a brand name like Mozilla hosting a repository
would give JavaScript a big boost and would ease the minds of
developers wanting to use JavaScript more but looking for a canonical
community. The developer would feel as though he is using something
that is not just a one-person side project that might die and leave
him hanging.
Peter
Kevin Dangoor
> That's fine, good to know exactly what you were looking for. However, in
> Persevere, one of the benefits is that the code paths are so short
> between querys/JS property accesses and database queries. Adding more
> layers of abstractions always sounds like a nice idea, but it's naive to
> think that you can maintain the same performance, and I wouldn't be
> likely to run Persevere's object mapping system on top of JS DBAPI. This
> partly due to performance but also because the leakiness of the ORM
> abstraction when in implemented in JS vs at the VM level. However, I
> would probably willing to implement a DBAPI on top of the ORM layer
> though ;).
> Kris
Something interesting to consider here, though, is that while it may
seem like using a JS DBAPI would hamper performance, if you can move
JSPersevere from Rhino to Spidermonkey or v8 or jscore and then get
JITted JavaScript, the performance might actually improve. (Note: I
just made up "JSPersevere" because Persevere itself is written in
Java, not JavaScript, right? So, I'm just making up an example of a
JavaScript package that may previously have been using JDBC directly
but changes to using the JS DBAPI.)
Kevin
--
Kevin Dangoor
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
Kris Zyp
That would be nice, but like I mentioned on another thread, really one
of the core benefits of Persevere is to provide true object-data
bindings, (with dynamic property mapping to storage and even type
checking) so that people can interact with data simply using JavaScript,
without any APIs needed. Persevere users can interact with objects and
data is loaded and saved as needed. This simply can't be done as a JS
library (short of having catch-all getters and setters, but that is a
long ways off).
It's also worth noting that even the king of JS performance, V8, with
all it's amazing JITing is still vastly slower than Java (about 4-5x on
some of my tests). The JVM has seen years of intense optimizations by
Sun. The fact that I can run the workhorse cycle-intensive low-level
operations in Java means that Persevere would still be vastly faster
than a pure JS solution running on the fastest JS engine. I love
front-to-back JS. Not sold on top-to-bottom JS :).
That being said, I would still be happy to see a standardized JS DBAPI
even if Persevere doesn't necessarily utilize it for it's object-data
bindings.
Kris
> Kevin
>
>
Ross Boucher
> It's also worth noting that even the king of JS performance, V8, with
> all it's amazing JITing is still vastly slower than Java (about 4-5x
> on
> some of my tests).
It's also worth noting that even though Rhino is really really slow,
probably as much as an order of magnitude slower than JavaScriptCore
or V8, it's still faster than Ruby. In fact, running Jack on Jetty is
faster than running Rack on Mongrel.
Raw speed, at the end of the day, doesn't have to be the primary
concern. Just look at how popular Ruby has already become as a server
language. So, I'm skeptic when I hear people say that JavaScript is
too slow to do X and a lower level API is needed. At the very least, I
think its important to start with the basics, and only once those have
been agreed upon, move to more complex things.
Sebastian Deutsch
Ross Boucher schrieb:
- but if your concept works all is gonna be refactored with queue
servers and erlang ;-) Maybe we should learn from that.
>
> >
--
Sebastian Deutsch
---------------------------------------------------------------
www.9elements.com
Kortumstr. 19-21
44787 Bochum
Tel: 0234 - 689 41 88
Mobil.: 0177 - 331 21 98
Skype: sebastian.deutsch
Xing: https://www.xing.com/profile/Sebastian_Deutsch
--------------------------------------------------------------------------
Davey Waterson
In terms of equivalent technology PHP is the one to beat, those benchmarks were
on the FF3.0 codebase so dont even reflect the latest speedkicks from the JIT.
performance is not a concern of the API it's for the implementors.
Starr Horne
> - a well-defined extension mechanism to add third-party libraries.
Personally I think rubygems is a good model. Having dependencies
listed in the package metadata would be useful not only for
installation purposes, but also to determine if a specific package
could be run in the browser as well as on the server.