Subject: Re: T13) Transactions - allowing optional commands

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 27 Aug 1999 16:14:21 -0500

Anyone else in favour of making context a command parameter?

> -----Original Message-----
> From: Bach, Richard [NGD:2011:EXCH]
> Sent: Friday, August 27, 1999 11:09 AM
> To:   [email-masked]
> Subject:      Re: T13) Transactions - allowing optional commands
>
> Dave,
>
> I am shaking my head also.  With 'atomic' commands being wrapped in
> contexts, transactions, and messages it hard to tell from which level
> acknowledgements should come.  I've never seem a call control protocol
> that
> uses transactions. Remote operation semantics are sufficient.
>
> I think all that is needed are for commands to be bundled in a message.
> ContextID could simply be a parameter of a command.  The move command is
> particularly interesting.  As I see it, the move command is wrapped in is
> the new context for the termination being moved.  When the move command is
> executed, the termination is implicitly subtracted from it old context.
> This implicit side affect is due to the current complexity of protocol.
> If
> a move command simply contained the IDs for the old and next context,
> things
> would be simpler and more obvious.  With the current design of context
> being
> external to commands there is no way to explicitly provide both the old
> and
> new context.
>
> --Richard
>
> > -----Original Message-----
> > From: David Oran [SMTP:[email-masked]]
> > Sent: Friday, August 27, 1999 9:13 AM
> > To:   [email-masked]
> > Subject:      Re: T13) Transactions - allowing optional commands
> >
> > Is anybody besides me shaking their head about how complicated we're
> > making
> > this poor protocol? Are we going to wind up with 3 years of
> > interoperabilty
> > workshops before a customer can be confident about interoperability (you
> > all
> > know what protocol I'm refererring to here :-) ).
> >
> > I think we should at least think about Christian's suggstion that we
> just
> > go
> > back to individual atomic commands and pitch all the rest of the
> > complexity,
> > or, as Mike Thomas suggested, punt such complicated stuff to scripts.
> >
> > Dave.
> >
> >

---

From: Rex Coldren <[email-masked]>
Date: Fri, 27 Aug 1999 14:31:47 -0700

Not me.  Not yet, anyway.  It seems like the way the transactions section
is written right now it puts the onus on the MGC to deal with partial success
of actions and commands within a transaction.  There appear to be no
particular worries for the MG.  It just bails at the failure point and reports.
Consequently, if the MGC is not prepared to deal with partial success, it
won't generate transactions that are too complicated.  Am I missing
something here?  It IS Friday.

Rex