RE: [XCON] New draft on manipulating state in a conference
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [XCON] New draft on manipulating state in a conference



What does it mean "transactionless" for the "get" operations?

Thanks,
Orit. 

> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On 
> Behalf Of Cullen Jennings
> Sent: Monday, February 14, 2005 7:17 AM
> To: Paul H Kyzivat; Chris Boulton
> Cc: Adam Roach; XCON-IETF
> Subject: Re: [XCON] New draft on manipulating state in a conference
> 
> 
> Implementing transaction on the server side is a huge hassle. 
> In general, it would probably be better but so far I can't 
> think of any place where we need it. I rather try and 
> structure the XML that was being manipulated such that multi 
> command transactions were not required. I'm not imaging this 
> as the end all be all do everything that might ever be done 
> but more as a way that a client might be able to do simple 
> like set who's video they were watching or mute something. 
> 
> I guess it is one of those things where if someone thinks of 
> a case where we have to have it, well then we need to 
> reconsider. If we need the strong transactional nature, then 
> I would probably have serious reservation about why we would 
> not use XCAP instead of this. Come to think of it, Paul, you 
> are the king of coming up with the corner cases everyone 
> forgot that will break the system :-)
> 
> Cullen
> 
> On 2/14/05 6:52 AM, "Paul Kyzivat" <pkyzivat at cisco.com> wrote:
> 
> > I have one comment on the specific proposal. From the 
> overview it says:
> > 
> >     ...  A client sends the server a request representing
> >     a sequence of commands.  Each command can set, get, 
> add, or delete a
> >     single field in the conference object.  Changes to the 
> conference
> >     object are performed on a hierarchal set of elements and unique
> >     attributes within those elements.  A series of changes can be
> >     pipelined in a single BFCP message.  The server 
> executes each action
> >     in series.  If one of them fails, the server returns an 
> error for the
> >     action that failed and does not execute any of the actions after
> >     that.  Each individual action is atomic but the 
> pipelined series is
> >     not. 
> > 
> > It seems like it would be better for the client application if the 
> > request was transactional - all or nothing. Is there a 
> reason why it 
> > is not?
> 
> 
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
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.