Re: [DotGNU]The Java Project Spectrum

[Gopal.V]

Hi,
        Seems like there seems to be a *slight* misunderstanding.
All I really want to say is 

"Can't you _SEE_ the solution ?"

> Think,java support problem is an instance of problem "How to support
> Languages(Byte Codes)"
> 
> In this parlance what we are doing now is to write a plug-in for the C# to
> the main system. 
> 
        That is exactly what is being done , If you take a careful
look at the dotGNU website you'll "SEE" (pardon the pun) what 
I mean. Pnet as you see now will be made into a SEE/Andromeda 
plugin .

> So what I means  to say is, could we define an interface to a plug-in so
> that, system gets the thing-that-runs-it (details deferred) when it does not
> know what to do with a new input. It could be source code or some complied
> output.
> 
        IMO this comes in the realm of the SEE. I do not suppose 
that this is to be built into Pnet (and all the other VMs of 
DotGNU). AFAIK, SEE is the program that should be responsible
for this sort of plugin management. The SEE daemon will and
should be the only `setuid root` program dotGNU needs. Thus
it will be able to download and install SEE plugins (just as 
Mozilla does) from a server. I'll leave that to a sort of SEE
admin program which automagically locates the latest updates,
but leaves downloading it and installing it to the discretions
of the Admin User(s). Look at Phpgroupware's application admin
for an idea of what I am talking about.
> 
> Pros
> 1.    This will be truly open.
> 2.    Lot of people will find it easy to port their RAD tools to DotGNU.
> 3.    Lot of people will find it easy to port their executable formats to
> DotGNU.
        I agree that "DotGNU" part , but you can't replace the "DotGNU"
with "Pnet" there. I think Rhys was  talking specifically about Pnet 
and *NOT* "DotGNU" in general. I think Norbert will agree when I say
"Exactly, that's what SEE does for DotGNU".
> Cons
> 1.    If I was a bad guy, first thing I would do is write a bad plug-in
> for the most-used language and infect all the systems. (So we need security,
> like signature or something or define the interface in which it is not
> possible to do bad things)
        I am yet to see Perl or Python download modules from CPAN
or PSF servers on request by a user program. Also automated 
downloading of binary/source code by a user program is not
something encouraged in a secure system . This is typically
prone to a lot of security problems. Most here will agree with 
me that "admin=security" , and the users should come after the 
admin in program installation/updation.

        I guess that we'll think more about this as SEE proceeds.
> ****************************************************************************
> This communication contains information, which is confidential and may also
> be privileged. It is for the exclusive use of the intended recipient(s). If
> you are not the intended recipient(s), please note that any distribution,
> printing, copying or use of this communication or the information in it is
> strictly prohibited. If you have received this communication in error,
> please notify the sender immediately and then destroy any copies of it.
> ****************************************************************************
        Looks like I shall start FDL'ing my mails from now on (just joking)

Gopal.V
-- 
 The difference between insanity and genius is only measured by success
 //===<=>===\\
|| GNU RULEZ ||
 \\===<=>===//