vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] dev language for vrs


From: Chris Smith
Subject: Re: [Vrs-development] dev language for vrs
Date: Tue, 16 Jul 2002 11:05:02 +0100

On Monday 15 July 2002 18:41, Eric Altendorf wrote:
> Of course, if we have GW APIs for different languages, it would make
> it pretty easy to write parts of the VRS in different languages,
> since they'll talk to each other via GW anyway.  Perhaps we'll want
> to write most of the system in C#, but the core of the RM in C or C++
> for efficiency; and perhaps we'll want to write some high-level
> diagnostic system utilities in a scripting language like Perl.

Yeah - my thoughts really.  One of the design goals of GW was to make it 
development-language independant.
Bits that need to be done efficiently are best done in C or C++ at a push.
The project is going to be pretty modular, so I'd choose the best language 
for each job in hand.

> Is that a correct view of the GW language API's, Chris?

Pretty much.
However messages passed across the GW API are un-typed binary chunks - so you 
can pass whatever you want around.  We'll need some sort of structured data 
buffer that every langage (java/c#/c/c++) will be able to decode.
XML is a goodie - but I don't like the parsing overhead that that incurs.
I've been using flattened linked-list trees (perhaps compiled from XML input 
before sending) (all done with relative offsets stored LSB) so different 
architectures can walk them and extract parameters etc.

Of course, not every component will use this 'data buffer', for instance the 
component that returns data from the RM will probably just want to return a 
binary chunk.

My idea was that Goldwater would supply one or two useful 'off the shelf' 
message structuring functions, but leave it up to the developer to use what 
they want - including developing their own.

So we still have this task to do, though it's not too difficult, and I just 
haven't had the time.

Whatever gets done, data assembled by a perl gw component needs to be 
readable and understandable by a Java component etc.....

chris

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]