dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] Re: [DotGNU]Network SEE architecture, v2


From: Eric Altendorf
Subject: Re: [Vrs-development] Re: [DotGNU]Network SEE architecture, v2
Date: Tue, 8 Oct 2002 10:17:36 -0700
User-agent: KMail/1.4.1

On Tuesday 08 October 2002 03:14, Chris Smith wrote:
>
> I can't get it out of my head that the SEE and VRS are very similar
> beasts:

I would agree.  

> Basically, a single node in a VRS looks like a SEE.  How
> executables/data is stored is very much 'local' in the true SEE
> sense, and distributed in the VRS sense.  How/where data is stored
> is handled by the Resource Manager of the VRS and will be entirely
> local if the VRS contains a single node. I see no reason why an
> 'equivelent' Resource Manager could not be substituted for the VRS
> default to provide the entirely local storage and
> forward-to-another-SEE-node behaviour required by the true SEE.

I would agree here too; the main difference between the SEE system and 
the VRS system seems to be the VRS's notion of an RM (a shared 
distributed filesystem).


> I think we should all team up as there is already architecure in
> place for the VRS that provides all the stuff the SEE is looking to
> require.

Agreed again!  Let's figure out if there are any irreconcilable 
differences between the network SEE project and the VRS project; if 
not, I'd say they both stand a much better chance of success if they 
team up.  "Together we stand, divided we fall" and all that. :-)

> However, the architecure used by the VRS has not been ported to M$
> as it uses SysV IPC (message queues and the like) and shared
> memory.  Something needs to be done about that, any volunteers????
> :o)

I'm completely out of my depth here, but is that something Cygwin 
doesn't provide?

Eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi


reply via email to

[Prev in Thread] Current Thread [Next in Thread]