[xwiki-devs] SPAWN and external services
Hello, Sergiu criticized that a MathTran (a TeX-daeomon over the web) solution for formulae is bad because it relies on an external service or a complex installation... probably correct and the rest of his argument (in particular the wish for MathML) is more than valid! But, I realize that scientific documents, the goal of spawn, right?, are often made of external services. Consider the success of TeXmacs, one of the great features is its ability to connect to external systems, precisely. Typically, the following artifacts are sensible products of external services: - plots of functions - plots of data-sets - presentation of data-sets - advanced visualizations (e.g. chemical diagrams, construction plans, interactive geometry constructions...). I don't think we want all that to be solved internally in spawn, using external services is a must and, on a web-system, those should be web-services. In many cases, the XWiki source may contain info to regenerate fully the artifact (this is the case of many TeXmacs session I think), in other cases external interactions are needed. The service has to be running when authoring, for sure, but it should not need to when running. Or at least breakage of it should not impact viewers. That leads me to think that a good approach would be to store the products in a more managed way, e.g., as attachments, than in a cache where it can go away for size reasons. Comments welcome. paul
What about the HotEqn plugin? ( http://www.atp.ruhr-uni-bochum.de/VCLab/software/HotEqn/HotEqn.html ) I found out about HotEqn because I was playing around with http://freemind.sourceforge.net/ and looking at http://code.xwiki.org/xwiki/bin/view/Applications/MindMapApplication Freemind's Insert->LaTeX command inserts "prototype" HotEqn node into the mindmap. Given that MindMap is a xwiki application, seems like it would be a very easy way to play around w/ rendering complex math equations inside Xwikil. Regarding MathTran -- I can understand the criticism against using a complex external service. How do you test the overall system for correctness or regressions? And do you really want to introduce a major external dependency when you don't even have control over the source/dev process of that external dependency? -- Niels. http://nielsmayer.com PS: I'm a TeX user since 1983. LaTeX since 1984/5.... Back then, i could just walk over to Don Knuth's office and ask for help. :-) For somebody with his well-deserved computer-science god-status, he was incredibly helpful and friendly to a completely clueless 18 year old.... On Sat, Mar 8, 2008 at 11:53 AM, Paul Libbrecht <[email protected]> wrote:
Hello,
Sergiu criticized that a MathTran (a TeX-daeomon over the web) solution for formulae is bad because it relies on an external service or a complex installation... probably correct and the rest of his argument (in particular the wish for MathML) is more than valid!
But, I realize that scientific documents, the goal of spawn, right?, are often made of external services.
Consider the success of TeXmacs, one of the great features is its ability to connect to external systems, precisely.
Typically, the following artifacts are sensible products of external services: - plots of functions - plots of data-sets - presentation of data-sets - advanced visualizations (e.g. chemical diagrams, construction plans, interactive geometry constructions...).
I don't think we want all that to be solved internally in spawn, using external services is a must and, on a web-system, those should be web-services. In many cases, the XWiki source may contain info to regenerate fully the artifact (this is the case of many TeXmacs session I think), in other cases external interactions are needed.
The service has to be running when authoring, for sure, but it should not need to when running. Or at least breakage of it should not impact viewers.
That leads me to think that a good approach would be to store the products in a more managed way, e.g., as attachments, than in a cache where it can go away for size reasons.
Comments welcome.
paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Niels Mayer -
Paul Libbrecht