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
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.