[17019] in Kerberos_V5_Development
Re: RFC: libverto nearing release
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Fri Jul 8 22:39:08 2011
Message-ID: <4E17BF3F.3070609@mit.edu>
Date: Fri, 08 Jul 2011 22:38:55 -0400
From: Ezra Peisach <epeisach@mit.edu>
MIME-Version: 1.0
To: Nathaniel McCallum <npmccallum@redhat.com>
In-Reply-To: <1310073296.16598.71.camel@localhost>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
One concern that I have with this library is that you do not
define/document a required set of options. Yes - you test some at
runtime - but is that really universal.
For instance, the signal handling that you have implemented - it
requires glib 2.29 - which is not available in earlier versions. I can
deal with requiring a minimal library version. The problem I have is
that depending on your "backend" - some signals are allowed or not. glib
only allows SIGINT, SIGTERM, SIGHUP. When you try to use a different
signal - libverto will not return a handle - as the low level glib traps
it. Your test suite uses SIGUSR1/2 - but the test suite returns
not-supported - so your code never really tests the glib library support
No - here is the rub - how can you write implementation code - as an
end-user - when the implementations are restricting you. I cannot write
"portable" code using the library - as I need to know the backend
implementation before hand.... [glib timeout code being up to 10ms less
than your requested time is another gotcha]
I do not know what other demons lurk beneath the surface... Clearly
these would need to be documented. Any code/plugins that use libverto
would need to use the lowest common denominator of all features...
Ezra
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
