oplot-development — mailinglist for communication between oplot-developers

[Oplot-development] Communication between Oplot and Octave

[Hans O. H. <ro...@ro...>]

I am currently working on designing a new protocol for Oplot and have come up with the following draft. 
The protocol itself is very simple. Upon connection between oplot and octave, a header indicating the different fundamental datasizes is sent to oplot. For example:
struct header {
unsigned int magic; 
unsigned int apiversion;
unsigned int intsize;
unsigned int doublesize; 
};

Commands sent has the following syntax (the byte sizes are listed below the syntax): 
CMD #ARGS[ DataType Data .. N]
1     1      1      1..X

The CMD (one byte) includes:
SET 
GET
FIGURE
LINE
AXES
...

ERROR - Used when an error has occured on the oplot side
RETURN - Is the return value of the CMD executed by the 

This protocol applies both ways, but oplot only sends the commands ERROR or RETURN (with datavalues) back to octave. 

Datatypes (the byte values listed are examples and are subject for change):
Matrix: 'M'
String: (zero-terminated) 'S'
Double: 'D'
Structs: 'T'
...

Example: 
Assumptions:
SET has the byte value 1
GET - 2
FIGURE - 3
ERROR - FF
RETURN - DD

octave:1> figure;
...
03 00 --> oplot
DD 01 --> octave

octave:2> get(0,'CurrentFigure')
...
02 02 'D' 00 00 00 00 00 00 00 00 'S' 'C' 'u' 'r' 'r'... 00 --> oplot
DD 01 'D' 00 00 00 00 00 00 F0 3F

Implementation details:
I have planned to split this problem into the following classes:
pParser - handles the parsing of the data from the channels
pChannel - designed to be flexible, and to allow *all* communication 	   methods


	pPipeChannel - stdin/stdout or named pipes
	pUDSChannel - unix domain sockets
	pSHMChannel - shared memory implementation
	pTCPChannel - tcp/ip channel
	...

and a special class, pOctaveModule which manages octave specific functions. 

Where should the errorchecking of arguments go? The current status is that the octave modules do this (see oset.cc), but it is very tempting to send all arguments to oplot, which then do all the errorchecking. I think this might be easier to maintain, and the octave modules will just have a "pass-it-over-to-oplot-and-let-oplot-take-care-of-it"-role. 
Another subject is in the process of sending the arguments. 
Should all arguments be converted into a very-big-n-ugly char string before being sent to oplot, or should they be converted one-by-one and then sent to oplot. The latter one, saves memory but we might fall in the trap that we come across an octave_value which is not supported by our communicationlayer. The first one, uses a big chunk of memory, but all arguments have then been sucessfully converted. 


Receving the arguments. 
The arguments need to be placed in a list/vector and then processed when all arguments have been received (and converted to the proper datatypes). 


-- 
Salvo Errore Et Omissione

"Even more amazing was the realization that God has Internet access.  I
wonder if He has a full newsfeed?"
(By Matt Welsh)

[Oplot-development] Welcome to the mailinglist for Oplot-development.

[Ole J. H. <wat...@ya...>]

Hi.

We hope you all will give good ideas for further development of Oplot.

Best Regards,
Oplot-developers.