Re: [DotGNU]Ignoring C#

[Norbert Bollow]

Kamil Klimkiewicz <address@hidden> wrote:

> > Hence the plan to make sure that the same code that runs on a
> > server with a distributed architecture will also run in
> > an "Secure Execution Environment" on the end user's PC.
> 
> In this way DotGNU web services will be incompatybile with .NET's.

The vision is that the capabilities of the DotGNU platform shall
be a strict superset of the capabilities of the Microsoft-based
platforms.  That gives hosting companies and application service
providers an incentive to prefer DotGNU software over Microsoft
software.

> Because .NET web services can be executed only throught ASP.NET (since
> they are ASP.NET scripts but written in any supported language).

Obviously the DotGNU platform must provide this kind of
execution as a "compatibility interface".

> I think it would be nice when any clients could use services from both
> platforms in the same time.

Sure.

When you have DotGNU software both in the client and in the
server, then you get the additional option of downloading the
executable bytecode and executing it locally.

If either the client or the server or both run Microsoft
software, then you're stuck to do things the Microsoft way.
I think that's fair enough.

> I have another question: will be DotGNU web services based on
> HTTP/XML, such like .NET's are? I think this solution is very good.

The discussion has been going in this direction, but I don't
think that a decision has been made yet.

> Of course this is just my vision, and it isn't perfect. It's mostly
> based on .NET's webservices. I don't know what is your vision of
> implementig web services on DotGNU, so tell me.

This isn't entirely clear yet... here are my current ideas:

I think the current idea is to have a stand-alone daemon (which
on a unix-based system would run as a non-priveleged process in
a changeroot jail).

The client starts a TCP connection to the daemon, and the daemon
starts a thread for communicating with this daemon.  This thread
checks whether the client is authorized to access the requested
service.

If authorized, the daemon checks whether the client asks to
execute the service, or to download executable bytecode for
local execution.

The second case is relatively trivial.. the daemon simply sends
the requested bytecode to the client and then the thread exists.

If server-side execution has been requested, then the daemon
checks whether the requested executable is available in native
machine code or not.  (A compiler that translates bytecode to
native machine code may be available for some but not all
bytecode formats).

Then execution of the requested service happens in a separate
process.  (Depending on the result of the previous check, this
means either executing a native executable file, or executing
the bytecode via a virtual machine implementation like a
bytecode interpreter or JITer).

The deamon thread remains alive until the child process has
terminated, so that the daemon thread can signal the child
process e.g. in case of a breakdown of the TCP connection, etc.

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet  (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month http://cisto.com
Business Coaching for Internet Entrepreneurs ---> http://thinkcoach.com
Tel +41 1 972 20 59      Fax +41 1 972 20 69      address@hidden