[Top][All Lists]
[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