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

[Chris Smith]

Eric - Terrific - it will be a boost to have a code-monkey partner!
Missed you on IRC this weekend too, you dissapeared just before I arrived!
I was in and out like a madman.

On Saturday 30 November 2002 18:06, you wrote:

> Of course...  Where can I find the C code?

| On Thursday 21 November 2002 17:00, Chris Smith wrote:
| I've done a bare bones C implementation for anyone to look at.
| http://www.nfluid.com/download/dgeemsg.tgz
| It should match the spec.  It requires phlib to build as it uses some 
| of the funky stringblock manipulation functions provided.

I've renamed the functions and structs since this release.
I keep flipping between making it part of Goldwater or part of DGEE as it's 
really useful in other areas...... still uming and ahing about this.

> > 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.
> >
> Excellent ... go for it.  I'm all for having a C implementation if you
> can whip it up quick. :-)

Almost done.  It was a good weekend :o)  Not functional yet, but messages 
pass through all the right blocks!

We're planning on a release-bonanza at the beginning of Jan, so I'm heading 
towards that.  There will be a 'private' beta test and break release before 
then to get any build and usage problems ironed out.

Though we need some serious webservice-api thoughts before then if it is 
going to be usable (which is the whole point).
I'll be posting some questions soon.

With regards to the API of the C# message chain implementation, I think that 
the following is probably the way to go, given the things I've been doing 
with the message chunks in the C DGEE framework implementation:

DGEEMessage message = new DGEEMessage();

// Pick up first occurance of ID, regardless of ID
//
DGEEChunk chunk1  = message.getChunk( ID );

// Pick up first occurance validating against ContentType
//
DGEEChunk chunk2  = message.getChunk( ID, ContentType );

// Pick up a specific occurrance
//
DGEEChunk chunk3  = message.getChunk( ID, occurrance );

// Pick up a specific occurrance, validating against ContentType
//
DGEEChunk chunk5  = message.getChunk( ID, ContentType, occurrance );

// Remove chunks
//
message.removeChunk( ID );
message.removeChunk( ID, occurrance );

// Add chunks to message
// (We may want to force a chunk into a particular occurrance, 
//  hence moving the chunks... I've NOT implemented this in the C
//  version as it's slightly tricky and we may not need it.
//  Food for thought.
//
newmessage.addChunk( ID, ContentType, chunk );
newmessage.addChunk( ID, ContentType, occurrance, chunk ); // Perhaps?


Or something like that.  What do *YOU* think??
Not sure I like DGEEMessage now I look back. A bit 'eugh'.  How about 
DGMsgChain and DGMsgChunk or something like that.  Dunno.


It really should adhere to natural C# object conventions (of which I'm not 
completely familiar).

Can I suggest that you start by writing the message and chunk objects with 
dummy methods just to set out the API, oh and a test rig that uses it, and 
then release it. I'd like to see how the API looks in C# when in use, just in 
case I spot something that may be troublesome later on.   And out of interest 
too, 'cos like I said, I've not done much C# code bashing yet.

Glad to have you bashing!

Chris

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