Re: [DotGNU]error installing dotgnu (DGEE)

[Chris Smith]

On Wednesday 14 May 2003 18:57, Gopal V wrote:

> > are various shell scripts and tools that read them - they could be in a
> > config file, but then it gets very complicated to process.
>
> Why ? ... let's all
>
> if test -z $DGEE_HOME ; then \
>       . @prefix@/share/dgeeenv.sh \
> ;fi

I was refering the to pros and cons of using environment variables.  If I we 
didn't use env variables, then it gets complicated..... I was not saying that 
testing DGEE_* in scripts was complicated :o)


> That's ok .. because the generated file is editable ... But still I think
> we can do better than that , especially generating the correct names for
> methods using the [WebMethod] value rather than the C# name of the method
>
> :-)

The webervice attribute allows you to specify the 'propper' name for the 
webservice, thus overriding the name of the method currently.

> Bah ! Python does not need client stubs ! ...
>
> import xmlrpclib
> server = xmlrpclib.Server("http://localhost/wstest.dgmx";);
> print server.MyMethod("0wn3r");
>
> should work just fine :-)

Yep, but some sort of tool which takes a dgmx file from the website and gives 
you the python client segment is useful.

> What I might really like are web interfaces to this ... ie using
> HTML Forms for entry of parameters of C# methods :-)

I'm already thinking about this - but it only works where you have simple (ie 
flat) input and output variables.

> http://localhost/wstest.dgmx?protocol=html
> http://localhost/wstest.dgmx?protocol=soap
> http://localhost/wstest.dgmx?protocol=xmlrpc
>
> Etc ... and allow format decoding that way ?

There might be some weight in this.
However the dgee is able to discover what type of request encoding is being 
used and treat it appropriately at the moment, luckily, so we do not have to 
be explicit on the request call.
But this is a clear and clever way to ensure that requests that could be 
missinterpreted get treated properly.

Chris