Eric Burger wrote:
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.
I'm not really a student of that stuff, but I believe that is for one
function or other closed unit of code.
When you take a system, if you add the complexity of each piece then of
course you get a huge number. In theory you don't have to do that
because the system is hierarchically decomposed into pieces each with
acceptable complexity, and in *theory* you can understand them one at a
time.
However I have yet to see a reasonable sized system where the overall
structure of all the pieces didn't introduce another kind of practical
complexity that AFAIK isn't normally measured.
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.
For one thing, SIP can't really be evaluated with a state machine
because it has stacks. (Via and Route headers, etc.) But that doesn't
really change the discussion.
I'm not sure its a meaningful question. But it seems like if it could be
answered, the answer would have to be in the thousands, or more, when
viewed as a whole. (Which is why adding two or four is irrelevant.)
To get a more meaningful number you would have to decompose it into a
hierarchy of state machines (or functions, objects and methods, ...) and
then find the worst case complexity of all those.
That may answer the, "Why SIP
does not interoperate" question.
I certainly agree that SIP is very complex, contrary to the claims that
were made for it early in its life. I don't have enough context to
compare it complexity to that of earlier systems for the same job - it
is my impression that they are worse.
The complexity is why we have been writing guides and clarification
documents, etc. (They don't *fix* the complexity, but they may help
people to master it.)
I do appreciate the point that the complexity arises one decision at a
time, and we should always be trying to make things as simple as we can,
given what we have to do.
It always comes down to: is the benefit of this new feature worth the
complexity that it brings. Not everybody comes to the same answer about
such a question.
Paul
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
