Server side engine - Options?

[Pedro Alves]

Hello everyone. I've discussed this a while back but since we'd like to
have some proof of concept ready by the end of the week guess it's a
good time to bring this up again.

We need protovis server-side processing. Our main goal is to print the
visualizations. It's not the only use for it but we can leave that out
for now, as this is big enough of a deal for us.

We'd like some guide lines on how to start here. As I see it we have 2
options:

1 - Use a protovis java engine; I know that Jeffrey Heer has been
working on it and I saw references to that engine in this mailing list
but I wasn't able to find it. Not sure it's it's publicly available or
not...

2 - Use rhino on server side. Is this possible? Anyone ever did
something with it? I guess we should try to use
http://groups.google.com/group/envjs - anyone tried it?

Any feedback is greatly appreciated. It's not clear to us at the moment
which is better - 1 or 2.

Thanks

-pedro

[Jamie Love]

There is one approach documented here:

http://code.google.com/p/protovis-js/issues/detail?id=41

I've not yet needed to use any mechanism for doing server side rendering. I suspect there are a few options:

1/ The approach in the link above.

2/ Rhino server side rendering, assuming enough of the DOM exists server side.

3/ Implement on server side JS enough of the DOM API to allow protovis to 'render' and have your implementation generate the correct SVG text.

4/ Convert protovis to generate SVG text in some other manner than the DOM then just use it on the server in a server side JS renderer.

I've not tried the envjs approach, but it'd certainly be my first bet.

--
You received this message because you are subscribed to the Google Groups "protovis" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protovis+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protovis?hl=en.

[Aureliano Calvo]

Another thing that came to my mind is to automatize in a browser running on the server. May be a FFox plugin?

[Pedro Alves]

Depending on a browser isn't an option really. I'll try 2/ 3/ (they are
the same, really).

We'll make some tests and cross fingers ;)

-pedro

> <mailto:prot...@googlegroups.com>.

> To unsubscribe from this group, send email to
> protovis+u...@googlegroups.com

> <mailto:protovis%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/protovis?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "protovis" group.
> To post to this group, send email to prot...@googlegroups.com

> <mailto:prot...@googlegroups.com>.

> To unsubscribe from this group, send email to
> protovis+u...@googlegroups.com

> <mailto:protovis%2Bunsu...@googlegroups.com>.

[Robert Kosara]

One thing you could try is node.js (http://nodejs.org/). It uses Google's V8 JavaScript engine, which works standalone and is very fast. It doesn't have SVG rendering, but you could write bindings to some SVG library (bindings to C code seem to be pretty easy to do with V8). Hooking your bindings into the Protovis code might just be an issue of faking the right global object.

[Jason Davies]

I like the idea of protovis being able to generate raw SVG source
without relying on a DOM (suggestion no. 4 in your list), I imagine
this would be quite easy to do. Then rendering server-side would be a
case of using a JS interpreter e.g. Rhino, node.js or SpiderMonkey and
rendering the SVG into an image using a library such as Apache Batik.

--
Jason Davies

www.jasondavies.com

> > with it? I guess we should try to usehttp://groups.google.com/group/envjs-anyone tried it?

>
> > Any feedback is greatly appreciated. It's not clear to us at the moment
> > which is better - 1 or 2.
>
> > Thanks
>
> > -pedro
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "protovis" group.
> > To post to this group, send email to prot...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > protovis+u...@googlegroups.com<protovis%2Bunsubscribe@googlegroups.c om>

[Pedro Alves]

This is interesting, can you elaborate a bit more on the idea of
removing the dom dependency? Especially the part where you imagine it to
be easy, cause seems to me that dom handling is a bit transverse to all
the code

-pedro

[Jamie Love]

Well, basically there are two points:

1/ Direct DOM manipulation can be slow. Various tests on the 'net indicate that this may no longer be the case, but it definitely was a problem in a project we did early last year. We ended up building the HTML as a string, then setting a node's innerHtml to the string. 

2/ Decoupling the building of the SVG DOM from the browser's DOM API means that  rendering to a system without a DOM would only require that one write an instance of the API which is right for you.

It seems quite possible that #1 is no longer relevant, so the only reason I may suggest for removing the DOM dependency is that, well, tying the beautiful protovis API to the browser's DOM API for rendering is un-necessary, and in not doing so maybe we could open up protovis to other situations easily.

If we made it build SVG strings, then you could use a server side JavaScript engine to generate SVG images as files, and then just serve them. You could also convert the protovis generated SVG to plain images via http://xmlgraphics.apache.org/batik/.  You could embed Rhino in an application and use it + protovis as a graph scripting engine. 

The protovis code isn't actually much dependent on the DOM - the number of lines of code that are used to actually generate/render SVG DOM nodes is quite small so removing the dependency wouldn't be that hard.

Jamie

To unsubscribe from this group, send email to protovis+u...@googlegroups.com.

[Pedro Alves]

Ok, this is not looking good.

We'll keep testing it but we can't seem to make it work using extjs. It
just keeps blowing up on us.

I'll carry on with the tests, but it'd be great to hear feedback from
someone that tried this before.

otoh, if someone can point me to the java engine that would be awsome

-pedro

[Jamie Love]

What doesn't seem to work with extjs? what is the error?

Java engine for what? the javascript interpreter? Google for "rhino javascript".

[Pedro Alves]

I've built a simple package that replicates the issues we're facing:
http://tinyurl.com/18r

Just do:

java -jar env-js.jar -debug -opt -1 test.js
or
java -jar env-js.jar -debug -opt -1 test-p31.js

The error on the second case is:

js: "protovis-d3.1.js", line 6477: uncaught JavaScript runtime
exception: TypeError: Cannot read property "$panel" from null
at protovis-d3.1.js:6477
at protovis-d3.1.js:4967
at protovis-d3.1.js:6415
at protovis-d3.1.js:4919
at protovis-d3.1.js:4733
at test-p31.js:33

I've tested with 2.6, same thing

Thanks

> <mailto:drj...@gmail.com <mailto:drj...@gmail.com>>> wrote:
>
> There is one approach documented here:
>
> http://code.google.com/p/protovis-js/issues/detail?id=41
>
>
> I've not yet needed to use any mechanism for doing server side
> rendering. I suspect there are a few options:
>
> 1/ The approach in the link above.
> 2/ Rhino server side rendering, assuming enough of the DOM
> exists
> server side.
> 3/ Implement on server side JS enough of the DOM API to allow
> protovis to 'render' and have your implementation generate the
> correct SVG text.
> 4/ Convert protovis to generate SVG text in some other
> manner than
> the DOM then just use it on the server in a server side JS
> renderer.
>
> I've not tried the envjs approach, but it'd certainly be my
> first bet.
>
>
>
>
>
> On Tue, Feb 16, 2010 at 10:37 AM, Pedro Alves
> <pmga...@gmail.com <mailto:pmga...@gmail.com>

> <mailto:prot...@googlegroups.com

> <mailto:prot...@googlegroups.com>>.
> To unsubscribe from this group, send email to
> protovis+u...@googlegroups.com
> <mailto:protovis%2Bunsu...@googlegroups.com>

> <mailto:protovis%2Bunsu...@googlegroups.com
> <mailto:protovis%252Buns...@googlegroups.com>>.

> For more options, visit this group at
> http://groups.google.com/group/protovis?hl=en.
>
>
> --
> You received this message because you are subscribed to the
> Google
> Groups "protovis" group.
> To post to this group, send email to
> prot...@googlegroups.com <mailto:prot...@googlegroups.com>

> <mailto:prot...@googlegroups.com

> <mailto:prot...@googlegroups.com>>.
> To unsubscribe from this group, send email to
> protovis+u...@googlegroups.com
> <mailto:protovis%2Bunsu...@googlegroups.com>

> <mailto:protovis%2Bunsu...@googlegroups.com
> <mailto:protovis%252Buns...@googlegroups.com>>.

[Pedro Alves]

IT WORKS!

Kudos to Jamie! We can how tackle printing now! If someone wants the
details just ask.

(Now the only stuff left to fix is IE)

-pedro

[Jamie Love]

Pedro referenced getting it working under Rhino,

I did a bit of work thismorning on helping out -

After a bunch of fiddling, I've got a demo working. Attached is a (1.2Mb) file that has all the components needed to use Rhino to generate SVG server side into a SVG file (Read the README file included).

Enjoy!