Re: [DotGNU]Dgmx and the metadata problem

[Chris Smith]

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