[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Dgmx and the metadata problem
From: |
Chris Smith |
Subject: |
Re: [DotGNU]Dgmx and the metadata problem |
Date: |
Mon, 13 Jan 2003 19:51:20 +0000 |
On Monday 13 January 2003 11:34, Peter Minten wrote:
> Hi folks,
>
> I've looked into the dgmx webservice definition format and must say I like
> it a lot. The idea of putting metadata in a separate file is great,
> especially since it solves a problem with languages that don't have
> metadata support build in (like Ruby and Python (AFAIK)). For those
> languages you could simply precompile the metadata into dgmx and load it at
> runtime.
This is one of the main reasons I did the dgmx thing.
Others are
- Documentation can be generated without having to go near the VM
- Upfront checking of methods and parameter signatures before going
near the VM (Where possible)
- Ownership of a webservice can checked before perfoming and admin tasks
on it (like downloading it localy or removing it)
- Helps with the marshalling of parameters outside the webservice - if
required.
etc
> I suggest that we use the following convention for that: Metadata is always
> put in comment form, with a one line comment sign (#) if possible or with a
> one line comment with multiline comment delimiters (/* */), if an metadata
> attribute does not fit on one line a contiuation is signalized using
> '\'.The metadata is written in C# attribute form
> ([PublishedMember(description="foo")]).
> -- Cut --
> Then I could simply generate the metadata using a little metadata compiler
> like: 'dgmxgen --ruby state.rb'. At runtime the Webservice would load
> state.dgmx and use it's information to publish it's stuff.
This works for me.
However, in something like C, I wonder what weight there is in defining
static structs of attr info before each 'method' so that the data is at least
'reflectable' at runtime to provide last minute method signature checking and
marshalling etc. This would need preprocessing too in order to assemble a
table of 'attribute' data and method pairs that could be traversed. I've
done something similar before that could be adapted - including the
preprocessor.
We could do whatever provides the best functionality on a per-language basis?
- so long as they're all pretty similar in form?
Just an idea. Comments work. Having it in the runtime though _may_ have
it's advantages.
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk