RE: [XCON] Comments on draft-barnes-xcon-framework-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [XCON] Comments on draft-barnes-xcon-framework-01
Same here :-(
According to our terminology, ranges are not "rules". Template which is
a standard .xsd only can not express specific system ranges. You need to
have an XML object to express these. Thus the framework suggests that a
template is a data object, rather than only a registered .xsd schema
(and description).
The framework also suggests that all the three data objects (template,
reservation, and instance) are defined by using the same type:
conference-info because they ARE very similar in the content, indeed...
With this approach, each of the objects can contain its own definition
of ranges. Also, each of the objects is independently accessible by
using naming conventions.
Let's continue the discussion in Boston :-)
Orit.
> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Monday, January 03, 2005 6:55 PM
> To: Orit Levin; 'XCON-IETF'
> Subject: RE: [XCON] Comments on draft-barnes-xcon-framework-01
>
> I guess I don't get the model that is in your head.
> You get a conference by specifying a template and some information
like
> when/how long/...
>
> You get back an object (reservation).
>
> If you want to look in the rules database, you could figure out what
the
> limits on setting values could be. You could also just try it and see
> what
> happens. I think those are the only choices. You can't "just know".
> Having objects "ready to go" doesn't change the amount of information
the
> client gets; either he has the rules, and interprets them, or he
doesn't.
> I don't think anyone has proposed some kind of a rule collapsing
function
> (apply all the rules applicable, and tell me what the aggregate limits
> would
> be).
>
> Finally, I think many of you have the idea that there is a great deal
of
> state difference between reservation and active conference. I don't
think
> there is much difference at all. Let's take a few examples:
>
> - start time is one that is different; there is no start time on an
active
> conference
>
> - stop time can be changed at any time prior to the end of a
conference
>
> - a dial out list can be changed any time prior to the end of a
conference
>
> - how many moderators, and who is a moderator, can change any time
prior
> to
> the end of a conference
>
> - how many participants can be changed any time prior to the end of a
> conference
>
> - Mixing parameters are a little tricky. Generally, only an active
> conference has the controls for the mixer, but define "active". Can
you
> change the volume of the stream coming to you when you are getting
"the
> conference will begin when the moderator arrives" messages? Why not?
>
> So, generally, there is very little in an active conference that is
not in
> the reservation. Depending on how we handle mixer controls, there may
be
> a
> set of variables in the active conference that is not in the
reservation.
>
> Brian
>
> > -----Original Message-----
> > From: Orit Levin [mailto:oritl at microsoft.com]
> > Sent: Monday, January 03, 2005 8:24 PM
> > To: Brian Rosen; XCON-IETF
> > Subject: RE: [XCON] Comments on draft-barnes-xcon-framework-01
> >
> > 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.