[Top][All Lists]

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

Re: [DotGNU]Webservice Goals

From: Gopal V
Subject: Re: [DotGNU]Webservice Goals
Date: Sun, 16 Jun 2002 22:30:16 +0530
User-agent: Mutt/1.2.5i

If memory serves me right, Peter Minten wrote:

Note: This a long mail , I'm 

> If this can be done that would be (obviously) a Good Thing :-).
"Good Thing (TM)"

> > The type of linkage security of the kernel can provide
> > that type of safty, also inside a static lib, but the
> > IL interface will have to verify each method invoked
> > from outside for the validity of the function call.
> Any volunteers to tackle this? :-)

Well QA is the toughest part of development .... (ie not me !)

> > C# is also fine for an IDL language as far as I can tell.

I don't think so (but the method attributes may provide an inline
IDL format ?)

> Good idea (though I prefer OpenOffice over StarOffice (AFAIK OpenOffice
> is open source, StarOffice isn't)).

IMO office is secondary .... developer framework first !

> Of course Perl can be used as scripting language, any language that can
> be used with IL can be used as a scripting language for that matter.

Well won't my GPl'd python module allow A , B or C to violate the 
GPL by doing eval ("import %s" % (sys.argv[1])) ? and a clone module ?

Of course it does ! 

I wouldn't like to put holes into ilrun licensing , but scripting IL
seems to be a problem.... I would rather prefer a good Perl2IL compiler
to a inline:csharp module..

The latter seems to be easier (from what mdupont says,) ie using a
execvp to invoke cscc and cache the results ... 

But still the perl interface would allow people to use ilrun as a
scripting engine for say "Quake IV" (myrridian: huh ?) ....

IMO, this is a tough proposition ... unlike inline:c or inline:c++
the output format for C# is not native . So a double VM heavy system
is something I wouldn't want to use (not to mention perl's own cpu 
guzzling capabilites)....

I'm not quite hot about integrating stuff like this ... due to the 
thread safety concerns ... (== too much like work !)

> Steering Comittee: can we make it a DotGNU recommendation to provide an
> IL interface for extensibility. So to say: 'programs should be
> extensible using scripting languages that can connect to IL bindings'?

This is a possible direction of thought ... but is it worth the effort ?
Aren't we're already low on pnet runtime/compiler developers?

> > What about reusing bits of DIA by providing a C#
> > language interface and publishing that to the Ruby via
> > a DOTGNU scripting languge data gateway?

Well running ruby from an IL app is an interesting possibilty ..
which allows us to remain inside GPL ... ie if we code so that
we leave no loopholes.

> > The abilitiy to extract needed meta data from source
> > code to enhance the editor.

Well csdoc anyone ? (I think some dtd mods may be needed 
to make a nice little index)

> > Inclusion of full code completion via embedding the
> > csccc and gcc compilers for providing parse trees via
> > the DOTGNU compiler metadata gateway.

A whole AST is too dangerous and too much information in
my opinion. 

(we could always generate a .syms file , and I don't want
30 sec gaps when I press [CTRL]+P ;-)

In hindsight , I tried your introspector for generating C#
code for PInvoke . I found the AST a bit too heavy for the
parser when I needed just the types and function prototypes
(it seems similar here ?)

> To put this in a speech:
> "We will not make old software obsolete like Microsoft is bound to do,
> instead we lift it up into the future of the web. We will not strive to
> have one language for development, but instead we welcome all languages
> into our mids. We will be secure even the code we build on isn't."

Well IMO IL was designed as a compile to IL language. So rather than 
going on to "Script" the runtime, we should build on existing parsers
and build an ILCodegen for each ...

> The only thing needed to get this operation started is the green light
> of the DotGNU community. The sooner these plans get accepted by DotGNU,
> the sooner we will have those neat killer apps ready.

IMO we should have started on alternative compilers loooong ago...
I've been thinking about a webapp language for about 3 days which
uses an inline <?csharp ?> PI to enclose C# code . This is extracted
and compiled by the cscc .. 

This was the result of /me trying to generate "unreadable" code for
printing HTML code ... ie like that pnetcgi I hacked loooong ago.
All that remains is to write a headerparser and queryparser to become
an alternative CGI language, add a session object initialized 
automagicaly....  you understand what I'm leading about ?

What I do is run that init.d pnet script and chmod +x the binary .... 
and we have a CGI IL program... (set me thinking ....)

It's d*mn easy , I wonder why nobody did this before ! 

The difference between insanity and genius is measured by success

Description: Text document

Attachment: 1.chtml
Description: Text document

reply via email to

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