RE: [XCON] Comments on draft-barnes-xcon-framework-01

["Orit Levin" <oritl at microsoft.com>]

I don't see how it can be an implementation detail.
We need to standardize the way we reserve/create an XCON conference,
i.e. what information a client provides for it.

Just providing the IANA registered value for a desired template is not
enough. In your scenario, the client needs to somehow know (how?) its
specific system limitations and optionally also provide the values for
the particular conference to be created within the allowed ranges.

In the framework scenario, the client can just point to an existing
system's template object which has already the allowed ranges (and
default rules). The client can also query for the supported system
template objects with their ranges and then create the conference
instance according to its needs.

Another difference is that the number of ranges and "rules" to be
checked during a conference creation is usually much larger than during
an active conference. It is similar to the difference between system
configuration and system management abilities. Why would the XCON
architecture require a conference server to execute all complicated
"configuration" checks for a conference created using a default valid by
definition system settings?

Orit.


> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Monday, January 03, 2005 4:25 PM
> To: Orit Levin; 'XCON-IETF'
> Subject: RE: [XCON] Comments on draft-barnes-xcon-framework-01
> 
> Every conference server will implement a small set of templates.  As
the
> template drafts discuss, you would like to have a small set of general
> purpose templates.  You don't get an object until you make a
reservation,
> that, in the case of an ad-hoc conference, is just before the
conference
> starts.
> 
> It's an implementation detail if a server has some set of structures
> "ready
> to go".  The implementation should not be constrained to need to do
so.
> The definition is that any change of value is subject to application
of
> all
> rules that affect it.  I think it's also the case that when you add or
> change a rule, you have to apply it to all existing reservations and
> conference instances.  That means it doesn't matter when you apply the
> rules
> (i.e. doing it in advance is okay because if the rule set changes, you
> have
> to apply the new rule to any extant objects that it affects).
> 
> Brian
> 
> > -----Original Message-----
> > From: Orit Levin [mailto:oritl at microsoft.com]
> > Sent: Monday, January 03, 2005 6:31 PM
> > To: Brian Rosen; XCON-IETF
> > Subject: RE: [XCON] Comments on draft-barnes-xcon-framework-01
> >
> > OK, I understand.
> > That is exactly how I would describe a "pattern" with its .xsd
> > definition.
> >
> > I would argue again that in a deployed system, we need a set of
> > templates ready "to go": i.e. a set of static objects (.xml) already
> > populated with the specific system limitations and not requiring
> > applying a set of ranges and rules to create the reservation or the
> > instance.
> >
> > Orit.
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > Sent: Monday, January 03, 2005 3:17 PM
> > > To: Orit Levin; 'XCON-IETF'
> > > Subject: RE: [XCON] Comments on draft-barnes-xcon-framework-01
> > >
> > > > BTW: You say: "A template is a DOCUMENT" - What does a DOCUMENT
in
> > > > technical terms mean?
> > > > According to XCON it is a "static XML object". According to your
> > view,
> > > > is it an .xsd or an .xml file? Not the IANA registered schema,
but
> > the
> > > > template file(s) that the XCON system keeps.
> > >
> > > It means it's a document that you can read.  It could be an RFC.
> > > It has a text description of what the "mixing pattern" does, and
what
> > all
> > > the controls do.  It has a text description of the roles, floors
and
> > other
> > > state.  It contains a schema.  If you extract the schema, it would
be
> > an
> > > .xsd.  It's not an object.  You can't do anything with it except
read
> > it,
> > > although the schema tells you what the object that is the
> > > reservation/conference looks like, so you could process the
document
> > to
> > > extract the schema and create a user interface that would
manipulate
> > the
> > > object created from the schema.
> > >
> > > The template RFC will contain a several templates.  We can create
> > > additional
> > > RFCs that are templates.
> > >
> > > You couldn't implement the server side of a conference without a
text
> > > description of how it works.  You can render a "reasonable"
version of
> > a
> > > user (client) side with only the schema, but you'll get a MUCH
better
> > user
> > > experience if you read the text, and figure out the interface from
the
> > > text
> > > description, using the schema as the specific definition of
exactly
> > what
> > > the
> > > roles, controls, streams and floors are named and how you
manipulate
> > the
> > > object that is instantiated from the schema.
> > >
> > > The template draft says this.
> > >
> > > Brian
> > >
> > >
> > >
> >
> >
> 
> 


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon