Re: [DotGNU]DotGNU - Four important areas

[Myrddian]

> 
> DotGNU core platform
> ====================
> DotGNU bytecode specification, DotGNU bytecode interpreter,
> DotGNU bytecode->machine code compiler (may be based on gcc),
> a compiler from a subset of one popular programming language
> (perhaps Java?) to DotGNU bytecode.

This should be more of an option, byte code is not entirely important
more important at the moment is Authentication. Not to mention
the Dsitributed Systems/ Framework.

In theory what I had in mind was that we should use GCC to generate
DotGNU bytecode (that's why FSF support is important, I think 
I also mentioned it on some of my docos)

If we are to build a Bytecode runtime enviroment, I was hoping
to go for a CLI derived Bytecode in hopes that we could quickly
make DotGNU understand CLI. My understanding of Java Bytecode
is that is tightly bound to the Language, considering that what I was
a little silly in that DotGNU bytecode can represent any language.
I dont if CLI fits that bill, but from what I can see it's also bound
to C# making it unacceptable for that task (But we could make it 
more generic if we need to)

Java is a great platform, what we could possibly do is port the
DotGNU frame work and authentication system to the Java Platform
hopefully in such a way that any Java interpreter can understand.

Also for DotGNU Byte code I was hoping for  compiling the program
while it loads this way we dont write slow interpreters. 

 
> DotGNU secure execution environment
> ===================================
> Can download DotGNU bytecode (or other stuff for which an
> emulation is available - that should include .NET stuff) from the
> network and execute it in a secure manner.

Good point, emulation is a horrible word it usually implies that the system
would be slow. But the fact that a secure execution enviroment should be
available is a good one. In theory what I had originally in mind was
that if we should choose to use CLI, the only barrier on implementing
.NET compatability would be the Components which make up .NET. That is
Libs, ActiveX, Passport, etc. But it seems to me that CLI might not 
fit the bill at all.

 
> DotGNU distributed execution environment
> ========================================
> Like an operating system for a "distributed computer" consisting
> of several instances of the "DotGNU secure execution environment"
> that are running on several computers.  This system must be able
> to take care of replicating databases across all the parts of
> this "distributed computer" and propagating updates.
 
> DotGNU virtual identities server
> ================================
> Something that gives end-users a lot of convenience in filling
> out registration forms etc, while at the same time giving the
> end-user full control about what data will be supplied.

This should be our primary focus, well Authentication/Authorization
As any program using the DotGNU platform/framework should have 
Authentication working.
 
 
> The part with the distributed execution environment is
> especially tricky, and these difficulties will to a large extent
> shape how the core platform and secure execution environment
> need to be designed.
> 
> Suppose the "distributed computer" temporarily breaks into
> two parts due to network problems, then each part should be able
> to proceed on its own.  Now when the network connection is
> restored, there will be conflicting database transactions.  They
> must be detected and resolved.
> 
> This implies that every program which is run on the "distributed
> computer" must log its transactions in a manner that allow it
> to roll-back whatever it did and recompute its results when
> notified by the distributed execution environment that at the
> first time it did not have the proper data.  (Such distributed
> batabases are suitable for many applications which need high
> availability, but they won't be suitable for applications were
> the cost of transaction roll-back can be very high like e.g. in
> real-time trading at a stock exchange).
> 
> The core system must be designed with goal of providing good
> support for this transaction logging and roll-back functionality.

Ok Why dont we create a sub-system to deal with this problem?
Or why not design it to have a three way peer communication,
that is one part falls due to some connection problem it routest
the transactions via another peer which can possibly connect.

Make it behave like a router, in which each DotGNU system could
have a peer router to pass transactions on.
 

__________________________________________
Myrddian <address@hidden(nospam)au>
-------------------------------------------
"I stayed up all night playing poker with tarot cards. I got a full house
 and four people died". 

                   -- Steven Wright