Subject: [XCON] DP4.3: Can a blueprint contain more than one template

From: "Mary Barnes" <[email-masked]>
Date: Fri, 23 Dec 2005 18:12:43 -0600

DP4.3  Is there more than one template associated with a given 
blueprint (i.e. is a blueprint one copy of common conference 
information, along with one template or can there be multiple 
templates associated)? 

The current wording in the framework supports the multiple 
template proposal; again, per the text in 7.3 and the basic 
definition of Blueprint.  I couldn't initially see that we had an issue
with 
the framework per se.

But, based on the discussion amongst the group of authors, it 
became clear that a clarification in the FW would be useful, 
although the viewpoints were fairly evenly split as to the need 
for multiple templates (within a given blueprint).  There was general
agreement that a blueprint may have more than one template associated
with it, however, one viewpoint was the templates can be defined in a
way that include all the combinations (e.g., rather than a blueprint
having separate templates for audio, video, text, they are provided a
single multimedia template that combines the 3). Whereas, another
viewpoint was that we should still have it as an option as to whether a
client wants to choose multimedia or the audio, video and text
separately (or some combination thereof).  It was generally agreed that
it's expeditious to define the combinations that seem reasonable into a
single template. However, the alternative viewpoint  was that the FW (at
least) shouldn't preclude offering multiple templates in a given
blueprint. With this approach, the blueprint can be viewed as having the
superset that is allowed for the particular flavor of conference and
then the client chooses and returns in the explicit reservation object
what it wants to use, which is then validated by the conferencing
system. 

A compromise was eventually proposed and agreed, with the proposal to
add some text into the framework (before the 3rd paragraph in section
7.3 - right after the text proposed for resolution of DP4/4.1)
mentioning something like:
"A typical blueprint is anticipated to consist of a single template, as
the template approach allows for defining combinations of media types in
a single template [ref].  However, a blueprint may contain more than one
template depending upon the characteristics and configurations supported
by a specific conferencing system.  This approach allows a conferencing
system to provide the clients with additional flexibility in selecting
the type of conference they desire."

Mary.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 24 Dec 2005 15:14:19 +0100

I have to admit that I find this far too complicated. I see no hope that 
implementors will either understand or implement this in any 
interoperable fashion.

I think we can avoid this by concentrating on two inheritance models 
that depend on each other:

- A "datatype" (class, static) model that inherits variables; this seems 
to be called templates, although C++ templates, which most implementors 
are familiar with, are something different yet again;

- A "data" (dynamic) model that is reflected in the inheritance of 
specific values ("audio only, with Joe as moderator"). By its nature, 
this would be derived from one template since each template will have 
different variables, possibly with the same name, so it makes no sense 
to inherit from several. As noted in my previous email, the root of this 
tree would be a particular blueprint. A blueprint is then created just 
like any other conference.

I'm probably still not following the terminology, but, if I may say so, 
that's a sign that others who are not document authors will be similarly 
confused.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 28 Dec 2005 10:46:06 -0500

Please, no.  Pretty please?

Once again, I'm most interested in systems that work well for users.  I want
to be able to build clients and servers that interact well together, and
provide a good user experience. 

To do that, the client can't get a surprise from a server (or vice versa,
but I don't think that is at issue here).

You can't say things like "...configurations supported
by a specific conferencing system" and not get surprised.

Most of us working on these things, which I think includes the people who
proposed this text, have agreed that it won't work if we have a zillion
templates; the chances of a server offering the template the client
implements will be too low.  Instead, we want a small number of well crafted
templates that meet most people's needs, with the ability to have others
that might exploit some new capabilities. 

This argues that you DON'T offer lots and lots of TinkerToy templates that
you select from to assemble a client.  Do it "once", do it "right", and most
clients will work with most servers.  Have this kind of open ended free for
all, and the only thing that will work is the simplest, dumbest kind of
conference.  "Once" and "Right" are hard.  You don't get relief by creating
this kind of option.  It gets harder to make good interoperable
implementations, not easier.

Brian  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Friday, December 23, 2005 7:13 PM
To: [email-masked]
Subject: [XCON] DP4.3: Can a blueprint contain more than one template

Mary.