search

asciidoctor / asciidoctor-diagram

:left_right_arrow: Asciidoctor diagram extension, with support for AsciiToSVG, BlockDiag (BlockDiag, SeqDiag, ActDiag, NwDiag), Ditaa, Erd, GraphViz, Mermaid, Msc, PlantUML, Shaape, SvgBob, Syntrax, UMLet, Vega, Vega-Lite and WaveDrom.
http://asciidoctor.org
MIT License
439 stars 107 forks source link

Make RJB an optional dependency #48

Closed pepijnve closed 9 years ago

pepijnve commented 10 years ago

Currently RJB is a required dependency of asciidoctor-diagram. It's used when running PlantUML and Ditaa to avoid starting a new JVM instance for each diagram. RJB uses native ruby extension which makes it more difficult to install compared to regular gems.

To make asciidoctor-diagram installation simpler, consider making RJB an optional dependency. When RJB is not available at runtime, fallback to launching a JVM using a subprocess instead. This will be considerably slower than the current RJB based codepath, so we should document that installing RJB can provide a performance improvement.

mojavelinux commented 10 years ago

:+1:

In general, I think it's a good idea to abstract away the calls to RJB even if just to safe guard us from changes to RJB or a possible alternative in the future.

pepijnve commented 9 years ago

If anyone feels adventurous, 163d75c334ea78149dac280ed1852f5f150b08ce removes the dependency on RJB altogether. Instead a JVM process is spawned which connects back to the Ruby process via a TCP connection. The Ruby and Java code then talk to each other via HTTP. There's a bit of overhead in marshalling and unmarshalling the data, but I think that's acceptable if this approach proves more robust than the RJB approach.

mojavelinux commented 9 years ago

Amazing.

This could also be the key to allowing Asciidoctor Diagram to be used purely in a service layer within a Java application server. You could, in theory, expose this as a public API and then extensions like the Chrome extension could call out to it to handle operations performed in Java. Lots of possibilities get opened up with this change.

pepijnve commented 9 years ago

@mojavelinux the java part of the code is currently at https://github.com/pepijnve/asciidoctor-diagram-java. Would you like to put that under the asciidoctor organization as well? The name is a bit misleading at the moment though, so I'm open to suggestions for better names.

mojavelinux commented 9 years ago

Would you like to put that under the asciidoctor organization as well?

Absolutely!

The name is a bit misleading at the moment though, so I'm open to suggestions for better names.

How about we generalize this as a service? In that case, we could name it asciidoctor-diagram-service (or something similarly named). In theory, it should be possible to run this in an application server and expose it through a REST interface. (Diagrams as a Service!)

mojavelinux commented 9 years ago

We could also drop the asciidoctor- prefix if this code is agnostic to client.