Hi Otmar, Hi Juha,
I think the basic idea about adding new non-standard patching/feature to
stable module should be not to affect the original behaviour of the
modules - if there is a way to disable completely the new feature and to
use the module as it way before patching, I would say fine by me.
Because we make happy to aspects:
keep the module's original behaviour stable
allow new code to get in.
the second aspect is if the new feature will because a standard or not
:)...we will find out in the next week, according to Otmar.
regards,
bogdan
Otmar Lendl wrote:
On 2005/11/01 11:11, Juha Heinanen <[EMAIL PROTECTED]> wrote:
Otmar Lendl writes:
> I've added support for the carrier ENUM setup as described in
> draft-haberler-carrier-enum-01.txt. This code is indended to
> facilitate a trial. This certainly is not the final release as
> the spec itself is in flux.
the spec is not even a working group draft.
Yes. It's the old chicken/egg problem: What's first? The code or
the standard. Given the IETF motto, we decided not to wait until
the RFC before we start implementing this idea.
> Anyway: please have a look and give me some indication whether
> the patch could be incorporated into the default openser release.
since i have been maintaining enum module, i would like to know if this
patch some has performance impact on enum function as used currently?
Basically the change moves the main code from enum_query_2 to a new
function enum_query_3 in which the additional code is only execute
if carrier enum was desired.
So, maybe one function call overhead plus one "if" statement. The
minor rearrangement I made in the string-handling should be
performance-neutral.
also, would you be willing to maintain enum module if this patch is
incorporated?
Short term, probably yes. Longer term is a question which my boss
has to answer.
in my opinion, these kind of experimental features should be done using
experimental modules until the feature stablilizes and is found
generally useful.
I thought of that as well, but then decided against duplicating
a lot of code into a new module. After all, my changes only
affect the "turn number into domainname"-part of ENUM and not the
much trickier NAPTR parsing and selection.
Any changes to the original enum module are very likely to apply to
a spinoff module as well, so weighed the maintenance hassle of
two almost identical modules against the introduction of an
experimental feature in a mature module.
The make future reintegration with the main trunk easy such an
experimental module would look exactly like my patched enum module.
Anyway, there is an IETF meeting next week and this should give me
some direction on the protocol evolution.
If it's the consensus here that such trials should not happen in
the current enum module, I'll fork the module.
/ol
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
