Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count*
of 2 or 4.
However, the result is similar: there is tons of Software Engineering data
that shows when modules get above a cyclomatic comlexity of 7, the number of
latent defects raises non-linearly.
Henning (or some lurker looking for something to do): an interesting
Master's Thesis would be to calculate the theoretical minimum cyclomatic
complexity of the current SIP state machine. That may answer the, "Why SIP
does not interoperate" question.
On 10/22/07 3:30 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
> Eric,
>
> I disagree with your *quantitative* assessments of how much thee things
> increase complexity (by factors of 2 or 4). But I certainly agree that
> complexity *will* increase.
>
> In the end everything we are doing increases complexity, so maybe we
> should all pack up shop and go home.
>
> Ultimately this all comes down to deciding how complex things have to
> get before people can do what they think they need to do.
>
> Paul
>
> Eric Burger wrote:
>>
>>
>> On 10/17/07 2:18 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
>> [snip]
>>> One agreed upon, NOTIFY may be sent in the agreed upon direction(s)
>>> within the INVITE dialog usage. Whether an initial NOTIFY is required
>>> will be determined on a per-event-package basis. (Its not needed to
>>> establish the dialog, so its a matter if it is semantically needed in
>>> the context of the event type.)
>>
>> Which is not the way NOTIFY works today, which means the sender has to have
>> code to the effect:
>>
>> if( !real_notify(event_object) )
>> {
>> if( needs_first_notify(event_object) )
>> {
>> send_event(event_object);
>> }
>> }
>> else
>> send_event(event_object);
>>
>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the
>> complexity of your notification stack by 2.
>>
>> [snip]
>>
>>> There is no separate subscription or timer. The dialog usage is
>>> refreshed by INVITE or UPDATE in the conventional manner. Events to be
>>> exchanged are renegotiated from scratch with every reINVITE or UPDATE.
>>
>> So what does the NOTIFY put into expires? I hear hk now: "Just stuff it
>> with 99999." OK, this now adds another hack into send_event(), "If I am a
>> real SUBSCRIPTION, return the timer; if I am not, return 99999." Just upped
>> the complexity by 1.
>>
>> Worse yet, what does the recipient do when it gets a BYE? Now it has either
>> a resource leak or more code:
>>
>> if( got_bye(dialog_object) )
>> {
>> for each pseudo-dialog subscription in the (dialog_object)
>> {
>> consider the subscription terminated;
>> }
>> }
>>
>> Upping the complexity by 2, again.
>>
>> Hey - we are not done yet! I will leave as an exercise to the reader the
>> amount of complexity added to create the implicit subscription in the first
>> place.
>>
>> I forgot, this really is targeted for devices that will hard code everything
>> and not support any real SUBSCRIBE/NOTIFY packages. [facetious]
>>
>> It would be much cleaner to call this thing "NOTQUITENOTIFY".
>>
>> Of course, since we are anal about messages and bandwidth, let's save 300ns
>> and just call the method "I". [joking]
>>
>> [snip]
>>
>>
>> Notice: This email message, together with any attachments, may contain
>> information of BEA Systems, Inc., its subsidiaries and affiliated
>> entities, that may be confidential, proprietary, copyrighted and/or
>> legally privileged, and is intended solely for the use of the individual or
>> entity named in this message. If you are not the intended recipient, and have
>> received this message in error, please immediately return this by email and
>> then delete it.
>>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
