Re: [Axiom-developer] Axiom API

[Bill Page]

Quoting Waldek Hebisch <address@hidden>:

> ... 
> I do not know what TeXmacs expect,

TeXmacs expects exchange of information via pipes (most
external programs communicate with TeXmacs this way) or
by calls to a dynamically linked library. 

http://www.texmacs.org/tmweb/manual/webman-write-itf.en.html

> but I know what Axiom was designed to do:  external program
> are supposed to connect to a socket and send command through
> it.  Terminal is really meant only for direct user interface (possibly
> also for debugging). 

I understand, however I am stopped by an almost complete lack
of any documentation. There is not even a very simple example
of "send one command, get the result and display it". Of course
this is embedded somewhere in the hyperdoc code but it is not
sufficiently accessible for me to motivate me to devote enough
time to understand it and extract such an example. 

Your reply gives me hope that such documentation may soon
be available! :-)

> I belive that if TeXmacs does not want to use HyperDoc
> protocol (which gives _full_ access to Axiom capabilities)
> we can add extra protocol. 

First we need to write down what is the HyperDoc protocol!

I understand that there may also be some currently unused
interface that is part of the br-saturn module (previously used
with the techexplore browser interface). I am sure that every
thing required by the TeXmacs interface is available here --
somewhere. 

I small complication is that desire to be able to present
graphics generated by Axiom inside the TeXmacs document
(as figures). As you know these graphics are generated by
another program external to AXIOMsys that requires the
X-windows libraries to render the result on screen and in
the format of a postscript file. 

In any case, it seems clear that an API library could be
developed that would interface with Axiom (and graphics?)
via sockets and talk to TeXmacs (and other external programs,
e.g. the Axiom Wiki webserver and even emacs) via a
convenient and efficient dynamic library. 

All of these  possibilities are lying dormant because of the
simple lack of documentation and time. 

Regards,
Bill Page.