November 2009, Google, Inc. announced a new concurrent programming language, Go. Although announced as a lab experimental release, Go’s importance to the community is evidenced by ranking 13th in the March
2010 TIOBE Report. Go presents considerable opportunity for the SVG
community, since Go does not have an official graphical user interface
library and since concurrency lends itself well to UI development.
This paper addresses integrating Go and SVG and is organized along three themes.
- Recent prior work for SVG generation from Go. Most work to date is limited to the generation of static SVG from Go, which is can be displayed after the Go program ends.
- The proposed technique, GAS. GAS provides an interactive UI architecture using SVG and AJAX as the graphical interface to a concurrently executing Go program.
- Possible future trends and directions for Go and SVG including NaCl, browsers extensions, and porting SVG rendering systems natively to Go.
Methods of expressing concurrency with Go and SVG are explored and some concrete
examples using the GAS API’s and Go are presented.
Implementing Concurrency
GAS stands for Go, Ajax, and SVG. In the GAS system, a Go program
employing a FastCGI interface runs behind an HTTP server. SVG renders
in a browser which also runs a JavaScript interpretive environment.
AJAX and Javascript ared use primarily as “glue” to interface to a
server-side running Go application program that is linked with GAS libraries.
On the client, JavaScript events are intercepted and sent via AJAX to
the server, where the GAS libraries deliver the events to the Go
program. A goroutine picks up the event and schedules it via a
Go callback routine. The Go program may respond by initiating
indirect mutations to the SVGDOM.
An SVGDOM abstraction layer in Go is used to facilitate convenient access to the SVGDOM resident in the browser. This is accomplished by a mechanism called
TREAD, which stands for Thunked Remote Executing Ajax DOM. Thus the Go program makes DOM-like API calls which are translated into JavaScript that executes in the browser where SVGDOM mutations can take place.
In the GAS system, SVG rendering relies on interpreted JavaScript for its event handling. Also since events are transmitted over the wire, a GAS application design must make some performance tradeoffs. However, the API interface to GAS closely follows the tradition of DOM programming, and abstracts away from the details of AJAX and FastCGI. Thus a Go programmer can easily develop a running SVG application in Go.
GAS Demonstration
A demonstration of sample Go programs using the GAS system, running under Ubuntu Linux, Apache2, an FastCGI will be shown.
Future Directions
A promising area for future development can be found in NaCl (Native Client).
NaCl is an open-source technology for running native code in web applications.
NaCl is in a early stage of release, and although current versions have issues, the NaCl technology looks very promising to deliver high performance UI experiences in the browser.
The GAS API’s could be adapted to a client-running SVG and Go application
when Go and NaCl integration is available and when SVG rendering via Go and NaCl is possible.
Thus the present GAS API architecture should
function under the framework presented and offer future adaptability to
client SVG deployments once NaCl and Go in the browser becomes viable.
