Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. how to unparse token (Francis Dupont)
2. Heads up everybody! Kea 1.0 is almost ready! (Wlodek Wencel)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Nov 2015 16:40:52 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] how to unparse token
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
(the whole topic is about the clasification expression which are parsed
as a vector of Token objects)
We are divided between two ways to provide an "unparse" method which
from a Token gives back its textual input.
In both case we have:
parse o unparse = identity
which means if you parse again the result of unparse you get the same Token.
Only a solution provides too:
unparse o parse = identity
Ie., unparse gives back the exact input (there is no miracle: this solution
simply caches the input into the Token object).
I argue we don't need this (expensive to implement) property, i.e.,
we can live with in "substring('foo', 01, all)" the "01" be unparsed
into "1". Opinion? Argument?
Thanks
Francis Dupont <[email protected]>
PS: I wrote a decompile function too but it requires only a from Token
to string method so works with #4115 or #4124. Of course the same question
can be raise: decompile or simply keep the "to be parsed" sring. And
the day we'll provide a get text config you can guess the question...
(with in this case the two common arguments: keep comments vs. pretty
print the output which shows bad constructs :-).
------------------------------
Message: 2
Date: Wed, 25 Nov 2015 22:58:19 +0100
From: Wlodek Wencel <[email protected]>
To: [email protected], [email protected]
Subject: [kea-dev] Heads up everybody! Kea 1.0 is almost ready!
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Kea 1.0, our first production release, is almost ready!
On December 8 the Kea 1.0 beta testing period begins.
The entire Kea development team appreciates any feedback you can give us.
Reports are welcome at the [email protected]
<mailto:[email protected]> mailing list or, log-in and open a ticket
directly on our project wiki at https://kea.isc.org/wiki
<http://kea.isc.org/wiki>.
Kea 1.0 will be released on December 29 as a summary of the year 2015!
Here is a summary of the changes and new features that will be included
in Kea 1.0:
- Lease expiration. Kea is now able to properly clean up expired
leases, including logging, removing DNS entries for expired leases,
and triggering hook calls upon lease expiration. This mechanism is
configurable, so the administrator can choose whether they want their
leases cleaned up immediately upon expiration, or whether they prefer
to delay cleanup by a few seconds or minutes. This mechanism can
even be disabled altogether to get a bit of extra performance when it's
really needed.
- Client classification. Kea 1.0 features initial support for
client classification. If you wanted your cable modems to act
differently than your CPEs, send different options to your Windows
machines, or put your voip devices in a completely different subnet, now
you can!
- Decline support in both DHCPv4 and DHCPv6. Kea is now able to
properly handle cases where clients report that an address is already
being used
by another device.
- New statistics. Several new statistics have been added. They can be
used to monitor lease expiration and decline processing.
- PXE boot. Several new DHCPv4 and DHCPv6 options useful for PXE and
iPXE boot are now supported.
We are currently working on several features that are considered stretch
goals for this release. Parts of the code required to support them are
already available,
but there are still important pieces missing. Please be advised that
those features may or may not make it into the Kea 1.0 final version.
Feel free
to contact ISC if you're willing to participate in testing of those
features when we get the engineering builds. Note that the quality of
such builds may be lower than released versions.
Host Reservations in MySQL. Currently Kea is able to store host
reservations in its configuration file. That is useful when the number
of reservations is reasonably low, but may become difficult to maintain
when the number gets large. We're working on the ability to store host
reservations in MySQL. Besides improving scalability and maintainability,
this will also allow the administrator to modify reservations without
going through the reconfiguration procedure.
DHCPv4-over-DHCPv6. The IETF recently published RFC7341, which standardized
a capability to configure IPv4 hosts in IPv6-only network. There's an
effort underway
in Kea to provide a server component for that architecture.
Thank you for your support!
Release Engineer,
W?odek W. Wencel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151125/6c0b24cb/attachment-0001.html>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 12
***************************************
