Subject: RE: [XCON] Chair´s opinion :)

From: "Orit Levin" <[email-masked]>
Date: Thu, 2 Feb 2006 12:52:11 -0800

Brian,
I also suggest that you use WAP as the requirement for defining the template data model and be done with it :-)

Orit.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Rosen
> Sent: Thursday, February 02, 2006 12:17 PM
> To: Sean Olson; 'Alan Johnston'
> Cc: 'Cullen Jennings'; 'Chris Boulton'; [email-masked]; 'XCON-IETF'
> Subject: RE: [XCON] Chair´s opinion :)
> 
> Generally, I agree that we need more than set/get.
> OTOH, I don't want a zillion operators, and an invitation for each
> template
> to invent more.
> I think we want to do two things:
> 	a) think hard about the data structures so set/get does what we want
> 	b) put a very high threshold on what constitutes an operation we
> have
> 		a special "method" for
> 
> I'm not sure what it means to "bring sidebar participants back in the main
> conference", but if it means (for an audio conference) change the mixer so
> that what sidebar participants say is heard by main conference
> participants,
> and that state is transient (that is, you want a "button" with two states
> that moves them back and forth) then I want a datum ("sidebar enable") in
> the sidebar data structure that can be set to true/false, and not a
> method.
> 
> Brian
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean
> Olson
> Sent: Thursday, February 02, 2006 2:56 PM
> To: Alan Johnston
> Cc: Cullen Jennings; [email-masked]; Chris Boulton; XCON-IETF
> Subject: RE: [XCON] Chair´s opinion :)
> 
> My (biased) opinion is that data manipulation (get, set, create, delete)
> is
> not enough because it does not accurately capture the complex semantics of
> some operations like "bring sidebar participants back into the main
> conference".  Data manipulation implies the intended operation; commands
> explicitly define the intended operation. This makes it much easier to
> implement more complex operations.
> 
> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Thursday, February 02, 2006 11:48 AM
> To: Sean Olson
> Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); [email-masked];
> XCON-IETF
> Subject: Re: [XCON] Chair´s opinion :)
> 
> (not as chair)
> 
> Sean Olson wrote:
> 
> >Yeah, not sure I understand the terminology either ... What is the
> >purpose of the command if it does not involve some amount of data
> >manipulation? The command set doesn't need to be large, but hopefully
> >it is not just 4 commands (get, set, create, delete) ;-)
> >
> >
> >
> This is exactly my point.  A data manipulation only approach would only
> have
> get, set, create, and delete.  Examples of conference control commands
> that
> are not covered by these include "create a conference", "delete a
> conference", "bring the sidebar participants back into the main
> conference",
> etc.  Do we need these?
> 
> My terminology use was not intended to bias the discussion - we had never
> been able to agree on the right term in the past so I tried another one.
> Anyway, this discussion is exactly the one I wanted to have.
> 
> If we standardize two "transports" then they have to be equivalent - there
> needs to be clear mapping between them with the same set of features and
> services covered, in my personal opinion.  This way, it is like SIP using
> both UDP and TCP.
> 
> Thanks,
> Alan
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >Chris Boulton
> >Sent: Thursday, February 02, 2006 4:03 AM
> >To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF)
> >Cc: [email-masked]; XCON-IETF
> >Subject: RE: [XCON] Chair´s opinion :)
> >
> >
> >
> >
> >
> >>However, I still think we need to decide the fundamental question of
> >>whether conference control is about data manipulation alone, data
> >>manipulation plus commands, or purely command based.  I would like to
> >>see this addressed.  The working group consensus on this will validate
> >>whether multiple transports or bindings will even work.
> >>
> >>
> >
> >I think this terminology heavily bias the decision but continuing on with
> it ...
> >
> >Given how we have data in the server that is defined after the client is
> compiled, I think there *has* to be some of what you call data
> manipulation
> (though there could be toher things too). If someone disagrees with this,
> then I am probably misunderstanding the terms.
> >
> >[Chris Boulton] Agreed.
> >
> >I also think that with any command, you may have situations where you
> have
> to set data at the same point. And I don't want two phase commits because
> they are two hard to implement so the data needs to "go along" with the
> command.
> >
> >[Chris Boulton] Agreed.
> >
> >If you accept we have to have the above, I rather have a small command
> set
> than a large one because I think a small set will do.
> >
> >[Chris Boulton] Again, Agreed.  Command set certainly doesn't need to be
> large.
> >
> >
> >Information contained in this e-mail and any attachments are intended for
> the use of the addressee only, and may contain confidential information of
> Ubiquity Software Corporation.  All unauthorized use, disclosure or
> distribution is strictly prohibited.  If you are not the addressee, please
> notify the sender immediately and destroy all copies of this email.
> Unless
> otherwise expressly agreed in writing signed by an officer of Ubiquity
> Software Corporation, nothing in this communication shall be deemed to be
> legally binding.  Thank you.
> >
> >
> >_______________________________________________
> >XCON mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/xcon
> >
> >
> >
> >
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon

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