Comments on AGN doc

[Ti Leggett]

This was my biggest beef with the documents. There was much overlap in
what the documents describe, and some described the same things
differently. I'm going to take the relational database frame of mind and
say that if there is a concept that two components use, then neither
should describe said concept but refer to a document explicitly meant
for it. Take the idea of services (which is general all on its own). As
I understand it both an AGN and a VV have some notion of providing a
service: the AGN can provide local services to those components local to
it, and the VV provides services to the components (i.e., AGNs and VVs)
connected to it. Either, these hold the same notion of a service and
therefor services should be defined separate of the two, OR they do not
hold the same notion of what a service is and therefor both shouldn't be
called services.

My 2c, Have a document that describes the architecture of the AG. This
would explain what the AG is, what problems it solves, and what
components make up an AG (AGN, VV, etc) on a strictly architecture
level. That means it would explain why an AGN is different than a VV
etc. Then the AGN doc would not deal with what an AG is, but
specifically what an AGN is, what components make up an AGN. It should
not deal with the specifics of how it does this (i.e., APIs) but rather
point you to the document that describes those standards. That way none
of these documents is cluttered with information that people might not
care about. It gives the flexibility of saying to someone who has no
idea what the AG is, "Here, read the AG Architecture document" and they
won't get bogged down in how services are defined, or how the VV handles
discovery. You see where I'm going.

Anyway, that was a bit more than 2 cents, but since I can't add too much
on the design side of things since I'm just now getting spun up on those
details, here we are.

On Fri, 2002-08-09 at 15:53, Rick Stevens wrote:
> We probably need an overall AG architecture document that frames everything 
> and creates the high-level concepts
> and definitions.  Given that we can decide if we should have separate 
> documents for VV vs nodes vs network services etc. or if we should roll the 
> whole thing up in to a single AG architecture document. In any case we need 
> to have
> all the documents share clear and consistent terminology.
> 
> We could then create dedicated specifications for each of the components 
> from which groups can code too.
> 
> 
> 
> At 03:06 PM 8/9/2002 -0500, Justin Binns wrote:
> >My comments included - mostly grammatical.
> >
> >My main issue at this point is that I feel the division between these two
> >conceptual spaces (AGN and VV) are either too distinct, or not distinct
> >enough.  The VV architecture, as I understand it, is designed to
> >explicitly support things like what the AGN document calls 'application
> >streams', but in a wholly different way than the AGN document describes.
> >At the same time, without such support in the VV, I'm not really sure what
> >a VV is.  We should either draw a clear line around what the AGN does vs.
> >what the VV does, then define the interfaces and (if there are any)
> >exceptions in a very clear way, or decide that they're all different
> >aspects to one big oval and resolve the design differences inherent here.
> >I'm leaning towards making them two different boxes, in which case the
> >application stream stuff, at a minimum, and possibly the media stream
> >stuff becomes part of the VV box (otherwise, what is a VV?), while the
> >control and node-specific organizational stuff stays in the AGN box.
> >
> >Justin
>