jessyink-team team mailing list archive

[Marc Eberhard <eberhardma@xxxxxxxxxxxxxx>]

Dear Hannes & team,

finally found some time to look at the new design.

The idea to utilize the various hooks in the SVG elements to call JavaScript
functions and to pass a "this" pointer sounds very good.

To which extent the actual JavaScript code should be in one block or
distributed depends on the intended use for JessyInk, I guess.

I can see several possibilities at this point:

   1. Single standalone SVG file containing the document content and
   JavaScript code
   2. SVG file with content, but the JavaScript code is at a different URI
   and is downloaded by the browser when the SVG is parsed
   3. SVG file with content. loaded via an external framework, like a GWT
   application

At the moment only (1) is being used, but I can see advantages for the other
two options. Option (2) would allow to completely separate content and
script. The script URI can be simply the name of the script. This would
allow to put several SVG presentations into the same directory with a single
copy of the script. It will work both with a local file open in the browser
and a remote URL open via a webserver. The advantage would be that the
script can be updated without having to open all SVG presentation files in
Inkscape. The disadvantage is of course that there are two files to copy,
the SVG file and the script. Finally, the last option would allow to
implement the JessyInk functionality in Java and use GWT to compile this
into very portable JavaScript code working with most browsers.

Obviously, for option (1) it doesn't matter if the script is in one block or
not. For options (2) and (3) the script would need to remain a single block.

So, the big questions is: Should JessyInk remain an add-on to an SVG file,
which provides additional functionality needed for presentations or should
it evolve more into an online application that can manage presentations over
the web? This could include repositories with presentations (including the
possibility to save modified presentations in realtime). If the
implementation of the functionality takes advantage of the possibilities in
GWT, it could even evolve into a small tool to edit and prepare
presentations. Inkscape would then be used to edit individual items for the
slides, like diagrams. These are then uploaded into the presentation via a
GWT interface. The actual assembly is done online. The advantage of this
would be that more than one person can contribute to a presentation, much
like Google documents. I'm personally quite interested in exploring the
possibilities of combining SVG and GWT for an online GUI.

It probably all depends on the anticipated use of JessyInk. My intention is
to move my lecture slides from a memory stick onto a webserver and implement
the functionality to automatically save changes on this server. It would
mean that I can add something to slides or insert new slides as needed
during the lecture and have them immediately available to all students in
the class. Obviously, the students will have read-only access to the
material while I have read-write access. But it still means that the current
version is automatically available at the end of the lecture and I don't
need to copy any files. At the moment I have to use a real whiteboard and
everything I write onto it is lost at the end of the lecture. I would like
to capture this in the future and make it available online with as little
effort required from my side as possible.

All the best,
Marc
________________________________________________________

email: m.a.eberhard@xxxxxxxxxxx, marc.eberhard@xxxxxxxxxxxxx
web:   http://www.aston.ac.uk/~eberhama/