Re: [DotGNU]Webservice Goals

[Gopal V]

If memory serves me right, James Michael DuPont wrote:
> > 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?

I was specifically in concern for thread safety... I've
spent a whole night trying to figure out why libxml# dumps
a core ... and it turns out be the GC's fault ... multiple
references and all that .. Which means I had to mark and 
sweep in Sync with the GC ... mark whenever I want ,
and sweep up when I do a Finalize()

Stuff like that cannot be accomplished/checked by SEE ...
My idea of SEE has been more of a permissions DAEMON 
(the third version of SEE) . Something than answers callbacks
to the security checks in VM .

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

Well the tough way !... 

> The attributes are accessable via the metadata or
> reflection as well right? Then they can be used.

Yes, we could have a ExposeIDLAttribute to specify
the exact IDL we want . (rather than rely on dynamic
stuff)

> The question is if we have the foundation for building
> anything at all right now..

Well we do have a foundation for 2 things ... I've tried 
to blaze a path through 2 less visited area of pnet . 

1) Wrapping Native libs
    libxml# should be a reasonable guide for anyone wrapping
data based Native libs ... I'm still unsuccessfull with call
back based systems (SEGFAULT in libgc)

2) Implement Scripting engine support
    Partial success with Python 

These two are IMO the way to go from here ... I'm working 
on the third big step ie a IL compiler for some language.

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

As I said I'm statically linking the VM with an 
-export-dynamic flag.

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

Well a new process is needed anyway ... (ILExecProcessCreate ...)

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

Guessed so ;-)
 
> 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?

Yes it can easily be used ... but the real issue is the
marshaller/unmarshaller .. "(T)V" seems easy but get to
"(T*bii[vSystem.Int32;)oSystem.String;" and life seems
more complicated than ... 

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

Lots of users might do good ... but how many perl users
would want to use OO code ? (sic)

> That does not matter for me, you pay the price to get
> the added features. 

The problem is .. perl has too many libs to actually 
use C# . That's where ruby comes in . IMO ruby has a
bit fewer libs that I would like it to have  (compared 
to python) .

A perl programmer would like to use the familiar crypts
of perl and obfuscate the whole stuff (so that his boss
cannot fire him without dumping his whole work .... etc)

> Perl 5.8 is now supposed to be thread safe.

But sync'ing the two VM threads ! (yuck) or are you
just going to spinlock it ;-)

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

Well ... IMO ... supporting CLR completely itself is 
salvation... 

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

Yes there is as long as you preserve the IL or Object
style execution and hide the Engine internals , you're
reverting to the normal mode of execution of the engine.
ie running IL programs . The module needs to be GPL'd
but the scripts using it will get only what a normal
C# program provides to the programmer ....

So in a sense the script and engine are loosely aggregated.
(like grep and sed in an earlier examples).

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

Well a scripting language and a compiled language has
differences .... Python provides the compiler in a similar
fashion. See the py_compile module .

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

Well the options are not upto me ... And Btw, I think
anyone can write a GPL'd compiler based on pnet or
GPL'd module based on ilrun. The only request put
forward is "Don't expose more than you need to".

I seem to have set a bad example with my python module,
which access runtime methods. The typical practice would
be to wrap this in an OO shell which hides the runtime
engine from exploitation. (with a nice getattr .... and
non exported VM funcs)

IMO anyone crazy enough to link ilrun (for which unlike CSCC
or GCC speed counts the most) through a couple of interfaces ,
deserves what he gets !. This penalty ensures FreeSoftware
based on pnet will be the best of the group ... 

But still I would like the opinion of DotGNU SC on this .
(especially rhys)

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

If you want it , if you need it ..... just do it !

I'm for improving pnet , but in ways which does not divert
development away from the free side of things . Writing a
scripting extension which allows you to handle the VM
internals is dangerous , though not illegal. But abstracting
out the VM internals into an OO format , removes that
danger.

If you ask me , the VM is open for scripting because it is
designed to run ! ... the compiler is closed with scripting
because the real uses are smaller in this case , especially
when we do have reflection (Ref: introspector) . So I would
advise that you would proceed VM way, rather than compiler.

Of course, I'm waiting for rhys's "I'm tired of this" mail.
Someone needs to say "go go go" or "stop right there" now or 
forget this forever.

Gopal
-- 
The difference between insanity and genius is measured by success