Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

JS context serialization?

2 views
Skip to first unread message

Jesse Thompson

unread,
Apr 10, 2007, 3:34:04 PM4/10/07
to perl-ja...@perl.org
Say, would anyone know if it would be possible or easy to serialize a
JavaScript runtime environment or context into a string, to save state
as to all the data in that environment? I don't fully understand how
the "compile" option works so I can't say if that is comparable.

What I am thinking is, my project would like to be able to run scripts
in the browser when the browser is compatible with the JS
requirements, and run them on the server otherwise. Doing this rises a
ton of technical challenges that I am addressing, but among them is
the fact that the JS on client is stateful.

When you click something to interact with it, the JS handles the
request, and the state of the web page and of all the JS data remains
intact awaiting your next request.

If you try emulating this server side however, the server first serves
you the page (and emulates whatever JS initialization there is) and
then sends you the page state at that point. If I could serialize the
JS context at this point and store it, then after the user clicks to
interact with something I could retrieve the serial and restore it as
a context in order to continue servicing the request. A restored
context would remember all of the JS information, and in my workflow
the page state is stored as a dom or e4x object so that is saved as
well.

Is that something that "compile" already does by chance, or if not is
there any other functionality that could accomplish it?

Thanks for your consideration. :)

- - Jesse Thompson
Webformix

Jesse Thompson

unread,
Jul 1, 2007, 5:51:09 PM7/1/07
to perl-ja...@perl.org
Ok. Re-reading my original post on "JS context serialization" I
believe it may have been too rambling. Let me try to be more concise.

In a web browser, Javascript runs interactively. When you first reach
a page, javascript starts up and js files get loaded, functions get
defined, etc. You create an environment.

Next, the user interacts with that environment. They click a button,
they type in some text. The environment records what they do and it
reacts to the user. The environment slowly changes over time.

In theory, using JavaScript.pm we should be able to do this server
side too. We should be able to re-use a majority of our client side
javascript code and pretend the server is a very slow part of the
client. This is faboo for handicapped web browsers like Konquerer. But
there is one major hurdle.

When the client accesses a server side page, JavaScript.pm starts up.
Js files get loaded, functions get defined. We have a new environment,
just like in client side. Except.... Once we pass control back to the
client we are in trouble. When the client presses a button or enters
some text it emits a brand new page request to the server, and there
is no way we can still have the "environment" we created the first
time around ready to handle the user's request. The environment cannot
survive from one page load to the next. It cannot be stateful.

What we need is a way to "serialize" an environment. That is just a
fancy way of saying we freeze dry the entire Javascript universe we
created into a string so it can be stored into a database for future
retrieval. Then, we "unserialize" or thaw out the data on the next
page request from the same user.

Does Javascript.pm have a way to serialize and unserialize an entire
context, for this and similar uses?

Thanks. :)

- - Jesse Thompson
http://www.webformix.com/

0 new messages