Re: [DotGNU]Webservice Goals

[James Michael DuPont]

> > > 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 !)
I wonder if SEE cannot provide this, and if not, what
does it provide?

> 
> > > 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 ?)
The C# can specify interfaces, methods and parameters.
Its meta-data is accessable via reflection. You can
get a API to the interface via reflection. The PerlNet
from active state uses C# as an IDL for perl. I think
it is really good idea. The CSDOC will allow for even
more information to be specified in the documentation.
The attributes are accessable via the metadata or
reflection as well right? Then they can be used.

> 
> > Good idea (though I prefer OpenOffice over
> StarOffice (AFAIK OpenOffice
> > is open source, StarOffice isn't)).
> 
> IMO office is secondary .... developer framework
> first !
The question is if we have the foundation for building
anything at all right now..

> 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..
Well if you have no way of calling IL without linking
the il_runtime statically then there is a problem. If
you dont address this, you will loose support. 

You can implement a perl_engine object that uses
pinvoked to talk to the c perl engine. That would not
require linking, but you can then not call IL from
perl without starting a new process.

Forget about the perl2Il compiler for now, just
getting calling between standard perl is enough work. 

 
> The latter seems to be easier (from what mdupont
> says,) ie using a
> execvp to invoke cscc and cache the results ... 
Ok course, just cscc the csharp, and then use the pnet
runtime to execute the code via a DLL. The same can be
used for many scripting languages or not?

> 
> But still the perl interface would allow people to
> use ilrun as a
> scripting engine for say "Quake IV" (myrridian: huh
> ?) ....
A perl interface will allow for perl users to use pnet
to talk to anyone via IL, to embed csharp and to get
lots and lots of users.

> 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)....
That does not matter for me, you pay the price to get
the added features. 

> 
> I'm not quite hot about integrating stuff like this
> ... due to the 
> thread safety concerns ... (== too much like work !)
Perl 5.8 is now supposed to be thread safe.

> 
> > 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 ?
Yes.

> Aren't we're already low on pnet runtime/compiler
> developers?
Well the more language interfaces you support the more
add on modules you get, even if they are interfaces to
other languages. If you dont support scripting
interfaces at all you are dooming yourself.

> 
> > > 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.
There is not any difference, as soon as you *link* the
two, you are opening yourself up to licensing issues
even via convoluted means. You cannot get around it.

> 
> > > 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)
That is not enought, but a good start.

> 
> > > 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. 
Not in mine. Why does ruby provide it? Why is ruby so
powerful? Be consistent, dont jump to conclusions.


> 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 ?)
The graphs are heavy, I have written queries on the
database to get them out. The introspector is very
verbose, but it can be used for function headers.
Stallman said that he has only problems with full
function bodies, but not with headers. that Is why he
gave his blessing for gcc_xml, if you want me to beef
up those features I can look into them.

> 
> > 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 ...

And work on the interfaces between the runtime while
that is happening. The point is that the perl people
and python and ruby are all thinking about IL
generation. Do you want to open pnet up as a general
il generator? sublicense parts of the compiler that
generate it? If you work out your calling and
interface issues now, you can translate to IL later. 


> 
> > 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...
What parts can be used? What about a C to IL compiler
that uses the gcc and outputs IL? A perl to IL that
uses perl and iterfaces to IL?
These are all big projects that have many questions to
be answered. Dont block the creating of interfaces
that people want and need.



=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/