Re: [DotGNU]DotGNU task list

[Jonathan P Springer]

On Wed, Feb 06, 2002 at 04:52:51AM -0800, Bill Lance wrote:
> 
> --- Sarath B Nair <address@hidden> wrote:
> > --- Bill Lance <mailto:address@hidden> wrote
> > >if you wish to write a customized program module,
> > >then run that remotely.
> > 
> > This is what i mean. 
> > Ideally i should be able to assign different
> > components of the assembly to
> > different servers(hosting *this* service).
> >
> 
> Hummm ... that may be possible in the VRS model, but I
> doubt that it would be practical.  The main purpose of
> the VRS is to expose services to a network,
> presumabaly for others to use.  Also, if it going to
> actually execute in the VRS, it will have to be able
> to be compiled to an intermediate byte code,
> presumable with Pnet.  The VRS incures significant
> overhead to accomplish it's distributed processing and
> storage task..  If this is a purely private function,
> and you have resources similar to those needed for a
> VRS, (for the forseeable future, this means a
> resonably current Linux system) I would think you'de
> be better off with more traditional approachs.
> 

I don't want to lose sight of the "address@hidden" distributed computing
possibilities of the architecture.  Since much of what DotGNU envisions
requires P2P-like distributed networking, distributed processing
services are a distinct possibility.  For example:

1.  I want to be rich.

2.  I devise some sort of Monte Carlo derivative modelling scheme and
code it in some sort of VRS/DEE aware implementation.

3.  Part of that implementation is the function 
"myReturnType ReallyComplexAlgorithm(MyInput1 i1, MyInput2 i2)".

4.  I call some (hypothetical) service
"distributedComputation(ReallyComplexAlgorithm, distributedInputs[])".

5.  The distributed computation starts doling the computations (RPCXML's
containing bytecode and input?) out through a network of P2P-connected 
VRS/DEEs.  The algorithm for distribution is left as an exercise for 
the student :-).

6.  The returns come back (perhaps as events?), the core program
processes them and displays them to me, I invest in stock and lose my
shirt.

7.  Voila!  The cause of good has been served.

Just a (peyote) vision for what this could do to harness all those idle
processors with TCP/IP addresses.

-js

-- 
-Jonathan P Springer <address@hidden>
------------------------------------------------------------------------------
"A standard is an arbitrary solution to a recurring problem." - Joe Hazen