Re: [Vrs-development] where are we at?

[Chris Smith]

Hi Chaps.
Well, stuff has been progressing, though slowly as my time has been limited 
lately.

I've done a summary of the commonality between SEE and VRS using SEE terms.  
You may have already seen this.
http://www.nfluid.com/dgee/dgee.html

This is my intention for the core framework onto which the VRS and SEE can be 
built.

This is done by providing appropriate resource manager and service manager 
modules to perform SEE or VRS specific behaviour.

The interface to these modules is the same regardless of their functionality.

As you will see, data paths 2, 4 and 7 are uni-directional and this 
'forwarding' of data onto another 'component' was missing from Goldwater.
This has now been done.  Took a bit of thinking about that one.


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.


I've got ilrun bound to a goldwater server so that it can be sent bytecode to 
be executed... however it's a statically linked binary of about 4Mb and will 
have to stay that way until we get to the bottom of the shared library core 
dump problem.


So everyone seems to be waiting for me.  To be honest, I though I'd get the 
example framework (which at least defines the interface) done ages ago.  
Applolgies for that :o(


I was going to write it in C because of time - though it would have been 
really simple.  The C versions of the modules could then be replaced by a 
more functional versions in C# by you guys.  Well, that was the idea.


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.

I'm open to all suggestions to get this working.  We need the DGEE running 
before we can morph it into a SEE or VRS.


Comments on all that?
Chris


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