[Vrs-development] GDEE Message Buffer Implementation (Was Re: where are we at?)

[Chris Smith]

On Monday 25 November 2002 18:17, Eric Altendorf wrote:

> > It really is very simple under the hood - perhaps someone would
> > like to write an implementation of it in C#  ??

We need a C# class object that implements a 'message buffer'.
It has methods to add data chunks to the buffer and read data chunks from the 
buffer.  It needs to deal with multiple occurances, and removal of occurances.

The C implementation has been provided as an example - a reference suite if 
you like.  It is missing the 'remove' function though.

> I could do that if you think it would be useful for development of the
> various modules (network server, service manager, resource manager).

Give it a go.  I'd exmaine the C code as pseudo code if I were you, to see 
how the message buffer is constructed.  Obviously a message buffer created 
with the C implementation should be readable and decodable by the C# 
implementation, and vice versa.  They must be functionally identical.

> > Before C# bits can be written we need a nice C# Goldwater 'class'.
> > I'm willing to divert my attention from doing the C framework to
> > doing the goldwater C# 'class' (which shouldn't take long - but it
> > has to be correct as it may be difficult to change it later as it
> > will define the GW interface!). If I then write down the black-box
> > interface that's in my head for modules A-D in the dgee, then
> > perhaps we could develop the framework together and much faster.
>
> OK, I think I need some elaboration here.  Do you mean a C# class that
> provides a front-end interface to GW, so that our various VRS modules
> and managers can talk via GW?

Yes.

In reality, now that I've got a C implementation of the message buffer, I'm 
probably going to write modules A-D in C as they'll only work out to about 
30-40 lines each and provide that code as a 'working' reference for each 
modules interface specification.  

We've all got something to 'see' and work from.

ie 
A. would just be Apache, or just a simple command line client.
B. Checks calls 'C' to verify that the requested service is available and 
passes the request onto 'D' if it is, else it returns a failure.
C. Confirms that a service is available for 'B' or returns a requested 
webservices byte code for 'D' 
D. Requests webservice byte code from 'C', executes it and returns the result 
to 'A'


'C' can just look in a directory on disc to see the the compiled webservice 
is there.....

Easy Peasy. No managment functions, no admin, no security, nothing. Just a 
simple demo of data path.

re-writing each in C# will be a doddle, but doing it this way gives me time 
to think about the C# GW API classes a bit.


By all means give the message buffer implementation a go... some one do it! 
make sure all numbers are stored in little endian format etc.
I imagine an implementation that provices something like:

message = new DGEEMessage();
message = new DGEEMessage( byte *stream ); // Instantiate from stored buffer
message.addChunk( ID, Content-Type, data_buffer, length );

long  len  = 0;
byte *data = 0;
data = message.getChunk( ID, Content-Type, &len );

byte *stream = message.getStream();

Or even split it up a bit by having a chunk object and a buffer object:

DGEEChunk chunk;
chunk = message.getChunk( ID, ContentType );
printf( "Chunk Length      : %ld\n", chunk.length()      );
printf( "Chunk Content-Type: %s\n",  chunk.contentType() );
byte *data = chunk.data();

I perfer the latter to be honest, having a buffer and chunk objects is far 
more objecty......

Note that passing the ContentType to getChunk is just for validation 
purposes, it is an optional value -> see the C implementation.  This might be 
a really stupid idea, but allows data for a particular 'ID' to be encoded in 
several formats, which will probably be required somewhere!

Chris "must stop designing off the top of my head...."

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk