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.