[Vrs-development] DGEE - Intermodule Message Passing

[Chris Smith]

On Friday 15 November 2002 12:16, Chris Smith wrote:

> I've not developed any 'simple' code for the modules in the dgee diagram
> yet as I've been concentrating on a simple data encapsulation that's
> implementable in C, C# or whatever.  This is needed to carry data from
> module to module.
>
> The data encapsulation is very simple.  It allows multiple data components
> to be sent in a single message.  The data componets may be binary, xml,
> text, whatever we want.  It also handles multiple occurances of data, so
> 'arrays' of xml documents for instance may be sent.
>
> It really is very simple under the hood - perhaps someone would like to
> write an implementation of it in C#  ??
>
> I'll document it and submit it for review.

Okay.  Kinda done.
http://www.nfluid.com/dgee/message.html

Don't read too much into what the message encapsulation is supposed to do.  
It *does not* replace XML or any other type of encoding, but allows arbitary 
data chunks such as XML, C# byte code, HTML form post data etc to be packaged 
together and sent as a single message between the internal components of the 
VRS/SEE core (DGEE) (http://www.nfluid.com/dgee/dgee.html).

It's pretty much a fundamental requirement to be able to do this as it means 
that data payloads can be carried through the system untainted until they 
arrive at the required destination module which can (presumably) understand 
them.  Along the way other bits of information may be picked up, and this 
message buffer allows them to be chained together on the fly as a single feed.

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.

My next task will be to hammer together a basic framework of the dgee core in 
C as both a demonstration and illustration of the design for fellow dotGNU 
developers.

The on going task will be to then write the simple framework in C# (as that's 
the way to go).  The message buffer implementation will need to be written in 
C# first though, then we can mix and match C and C# components as we feel fit.

So those of you who are interested, I offer the message thingy up for perusal.
Comments on a post card.

(if you don't see the point of the message buffer, it'll be clear as day when 
I get the framework done - and I'm working on this for the end of next 
week-ish !).

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