vrs-development
[Top][All Lists]
Advanced

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

[Vrs-development] Re: Discussion plans and GW stuff


From: Chris Smith
Subject: [Vrs-development] Re: Discussion plans and GW stuff
Date: Mon, 29 Jul 2002 18:25:27 +0100

Great.
This is exactly the design/development path I was hopeing to follow.
Ie define the RM Interface, and hide the internals.  Work can then both move 
on to other things and can proceed to flesh out the RM guts.

You're quite right about the VRS _not_ being restricted to the design limits 
of Goldwater.  That was never the idea.  I basically offered Goldwater to the 
internet community and Bill jumped on it as it solved the whole distributed 
nature of the VRS by allowing it to behave and exist as a single entity as 
well as looking like a collection of nodes, depending on which hat you were 
wearing.

The finite size issue was raised early on, but discounted because a single 
VRS was not designed to get too large (there will probably be performance 
side effects if it does).

Now if that design goal is to change (ie to allow infinite sized VRS's) then 
several design decisions will have to change.  And I'm not against this.

Goldwater is exceptionally extensible.  The new domain handling uses and 
extends the internal architecture very very cleanly, and I'm very pleased 
with it.  It has taken a lot of effort, but is effort that was required 
anyway becasue Goldwater needs a distributed architecture that works this way 
regardless of the VRS.

Sure we can provide other transports for inter-goldwater application messages 
if we like.  However they won't integrate so tightly with the base 
architecture, I have no idea if they will integrate nicely with the 
transaction manager (which will have to be added), or if performance will be 
as good (and there are lots of contention issues!).

There are lots of cool things that the goldwater domain handling does for the 
application.  For instance, it keeps track of domains coming and going, and 
lets the application layer 'feel' this happening, and even control it.

I think it may boil down to _what_ messages we need to send about, and 
whether they can be made to operate within a 'virtual infinite node space' 
even though it is ever-so finite.......  How we create a 'virtual infinite 
node space' is another matter again :o)

But additional transports can be done, you just need clear goals and a 
concrete design - an a knowledge of the GW architecture.  It's not trivial, 
but it certainly is straightforward.  A design goal of the Middleware.


Oh and _Nothing_ was taken the wrong way :o)

Can we leave off the Domain stuff for now and concentrate on writing the 
requirements etc.  When we have a clear picture of what we're doing we can 
pick it up again (at which point you'll have domain-ready goldwater in your 
hands).

Chris


On Monday 29 July 2002 16:36, Ian wrote:
> Chris,
>
> There are two things I'd like to address. This is a long email, but
> important. so if it gets boring, please go get a cup of coffee and then
> come back to read it =).
>
> The first is the discussion plans you listed. Eric and I met on saturday
> for a brief meeting. We just basically talked about what each of the
> Managers' functionality was. The reason for that was I thought it would
> be best if we decided to start designing. So we came up with the about
> the same lists that you did.
>
> I think it would be wise to meet before we completely finish the design.
> Eric and I were talking about writing a list of requirements for the
> part we're working on.
>
> For example:
>
> Resource(Repository?) Manager
>
> Stage 1 (initial rollout)
> a) Unsychronized, non-consistent data repository
> b) File system structure implemented
> c) No security (ie users of the LDS can go into the
>
> The goal is to lay out the connections between the RM and all other
> Managers. also it is to implement the structure and API for the
> distributed file system so other parts of the VRS can use it to develop.
> As I like to say, all under-the-hood intelligence is not there in this
> iteration.
>
> Stage 2 ---> Infinity
> a) Sychronization
> b) Consistency
> c) Anonymity
> d) Scalability
> e) Security
> f) Auditing ? (this was never mentioned but i just thought of it)
>
> The reason there is only stage 2 after the initial rollout is because we
> dont have a timeline. I understand that this is an open source project
> and we dont have developers on this 24/7. we should really have a plan
> if for no other reason than realize that we're behind our own made up
> schedule. it will also give us and everyone else a sense of where each
> of us are in the whole picture.
>
> So I was thinking about doing the RM, and Eric said he would check out
> the Service Manager. He also said he would work on the CM, but I assume
> you were going to do most of that because of Goldwater's involvement in
> there. On the design specs Bill had mentioned the use of a Network Port
> Manager. The idea seemed necessary because for no other reason than to
> manage the port usage of all the webservices (EODs) in the SM. Anyways,
> talk to Eric about the CM.
>
>
> The second thing I'd like to talk about is Goldwater. I went to the site
> and read all the documentation on Goldwater (well.. ok some of it I only
> skimmed.) I think I have a good idea of what it does. The questions that
> Eric and I keep running up against while we were trying to list
> requirements and define how each part worked was "Does GW already do
> that for us?" It would be very very useful if we all become guru's on GW
> also. Actually, I think its necessary that we do become very familiar
> with GW. We need to know what it does, how it does them, and how we can
> change/add to its functionality.
>
> I'm going to say something and don't take it the wrong way chris, but i
> dont want the design of vrs to be limited by the decisions made by
> goldwater. for example, the whole deal about the dynamic discovery. of
> course i understand that whatever design decisions gw makes is a
> reflection of your decisions too, which is fine. but i see us getting
> into a dangerous area where there is a good idea and everyone thinks its
> a good idea but the only thing preventing us from implementing it is
> that goldwater doesn't support it. i'm not sure on where your stance is
> on maybe modifying gw and adding extra functionality to it.
>
> this is not a problem at all. i just wanted you to know what i was
> thinking. that's the way i am, if i see something i just let you know.
> so its not like i think this is a big problem or anything. sorry if i
> came on too strong.
>
> so this is the timeline i'm thinking for the immediate future.
>
> 1. write requirements for all the parts of VRS
> 2. meet to talk about those requirements
> 3. meet to learn about goldwater
> 4. design each of the parts
> 5. implement initial rollout
>
> I'm thinking 1-3 should all happen within in the next 3 weeks. then
> maybe another 1-2 weeks for 4 (design). then i guess we'll go from there
> to see how long we expect stage 1 to be complete.
>
> thanks for listening,
>
> -alias

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



reply via email to

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