Re: [Vrs-development] Design Tasks Proposal

[Chris Smith]

On Tuesday 26 March 2002 16:42, Tim Terlegård wrote:

> I think the tasks (1-3) you mentioned is a very good start. Should we go
> incrementally, starting with 1 and end it before going to 2?

Well, you could with all best intentions... but they kind of support
each other.  I REALLY need to get the "2. Clustering of LDS's into a VRS" bit 
worked out ASAP as it's holding me up, so I'd like to go with that one first.
I need to know what a VRS will look like!

This will raise some questions that have a baring on (3) and (1).


At the moment, I can't comment on what VRS functionality Goldwater will 
support and what has to be provided by the application layer.  And I've got 
to make sure Goldwater provides the necessary API to allow the application 
layer to do it's job!


> What I think is very important is to keep the website up to date. 

Bill started this project and has been the only web site maintainer.  He's 
done a grand job, but now the finer details are being stretched and bent - 
but nothing concrete as of yet.

> If we all agree about something I think it should be written to the
> specification.

Yep.  First we've got to agree on something!  Hence my call for structured 
discussion!

> That would make ourselves aware of what we earlier decided and newcomers
> will have an up to date view of the project. I also propose to divide the
> information a bit more. There are a few main and important areas: 

Just to link these up with my design task list:

> 1) The goals/purpose of VRS

This is pretty much answerable right now.

> 2) How p2p in VRS is working

This will be answered by my Task (1)

> 3) On which node/nodes data resides and on which node/nodes the 
> services are running, 

Answered by my Task (1)

> 4) Security

Partially answered by my Task (1)
This should probably be a thread in its own right.

> 5) Service discovery. 

My task(3)

If these are split up on several pages it'd be much
> easier to find the information.


> When one knows what VRS should do, then one can start thinking about the
> design.

We know what it will (supposedly) do.
Well, okay Bill and I are a little more enlightened than others.

I think if we should ask Bill to give a brief synopsis of the goals of an LDS
and the goals of the VRS, as he's kind of authoritative on this at the mo.

Then I'd like to take a step back and start to consider HOW the VRS will be 
constructed (we've talked about clusters of LDS's, VRSlets, whether or not
VRS's may cross link etc....)


-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk