[bind10-dev] Agenda for 2009-10-15 call

[Shane Kerr]

All,

Some notes from the last call.

All,

Some notes from the BIND 10 meeting.

Attendees:

Michael
David
Shane
Likun
Feng
Jelte
Kambe-san
Larissa
Jinmei
Jeremy
Fujiwara-san
Evan

* Review of AP
   * Hotel for face-to-face meeting

Shane is on it, but not complete yet.

   * Directory layout

There was a discussion about the directory layout on the bind10-dev
list.

* Face-to-face meeting coming soon!

Shane will send a draft meeting plan ASAP.

* To "src" or not to "src" in directory layout?

Some discussion on list whether or not to use "src" in the directory
layout.

Michael: We can flatten easier than "unflatten".
Shane: Okay, let's use "src" and we can flatten if we want to later.

Jeremy: Do we want separate directories based on language? I think
"no".
Michael: Each library has its own format, so maybe libraries but not
excutables.
Shane: Makes sense to me, libraries in per-language, executables not.

Jinmei: Also where to put test programs. Separate program named "test"
like BIND 9? Unit tests and source code in separate directory, or...
Michael: Ruby test framework - follow whatever language testing is
built-in. 
Michael: Would rather see a "test" subdirectory.
Shane: harder to forget if tests are close, both changing and writing
at all.
Jeremy: Also easier to ship as separate release if near the code.

Shane: What does ldns do?
Jelte: Did not release tests. Would encourage us not to do this, but
rather to release tests.
Jelte: Had separate framework, each test was small file
(unit/module/system level), made sense to have separate directory
Jelte: Not sure whether we should change whole layout to reflect
modules.
Michael: Separate hierarchy like we have now, but under "tests".

Michael: Suggestion: delay final decision, do re-factor later.
Jinmei: Compromise - begin with whatever person likes, then revisit in
a few months.
Shane: May end up with 2 or 3 styles for a time.

Jinmei: The important thing is that we WILL revisit that.
Michael: Revisit this one month before next face-to-face meeting?
Shane: Will schedule something for early December - we will either
revisit or schedule again.

[ Note: I have added this to my calendar. -Shane ]



Design Documents

Michael: don't care as long as it is reasonable

Shane: doxygen?
Jelte: doxygen can support generating from code, but does NOT
guarantee up to date
Michael: never found something generated from source that was useful
(separate doc, or read source code)
Michael: great for API documention, not for design documentation
Jinmei: API documentation *part* of design documentation

Shane: I think we should make a design document based on a version and
note it
Michael: tool to check versions
Shane: lots of noise?
Jelte: that is the least we should do, if no effect on design we can
ignore it
Michael: API spec is *this* version, source code is *that* version
Michael: tool should handle multiple modules for same design document

AP: Shane will write requirements and send to list

Michael: we should use Python/C++ versions (even comments)
Michael: do we also do this in our binaries?
Shane: which version of libraries and so on?
Michael: if we have tests then we don't care


* Documentation
   * Design documents (see Jinmei's example)
   * Is doxygen the least horrible option for documentation?

Shane: What about documention?
Michael: pydoc for Python, C++ use... doxygen?

AP: Jeremy will research how to make doxygen make it do what we want

Jelte: Can we use doxygen for making man pages?
Michael: man pages are archaic! HTML is de-facto standard, PDF for
print format
Evan: Suggesting we do not include man pages?
Jeremy: doxygen does create man pages, has conditionals and syntax
Shane: Kind of agree with Michael - for API documentation
Evan: man pages needed for executables and config format
Jinmei: I use man pages for API, but reasonable and consistent
documentation with the least effort is most important
Jelte: I don't think I agree with Michael, but it should be fully
automatic
Jeremy: yes
Jinmei: okay
Michael: I think they will not be quite right, and we'll do tweaks to
get them right
Shane: If man pages fall automatically out of tool, great, but we
don't want to hand-craft them
Jeremy: That is my responsibility, if it needs to be done
Michael: Requirements document about what we want?

AP: Jeremy to write requirements document about documentation tool


Michael: I really like open office format - for high level stuff.
Jinmei: Are you particularly talking about design documents?
Michael: Documents in general... user guides, things more than simple
API doc.
Larissa: Maybe write them in Open Office and exporting in PDF?
Shane: I am not morally opposed, but I do like online documentation...
Michael: Open Office HTML is horrific.
Larissa: Agreed.
David: Simple business reason to put documentation on web site. Hit
from someone using our software, have a chance to convert them to
customer.
Michael: Have used DocBook for BIND 9... wasn't pretty, but we
probably could make it nice, if Jeremy came up with a good style sheet
Michael: We also need to think about what web site documentation lives
on... that is a future battle...

Jelte: The most important thing is that we can publish when we release
Michael: Would like to see "make doc" command
Jelte: That is what I am talking about
Jeremy: For now can do that on BIND 10 server



* Strategy for exceptions
   * Michael's benchmarks

Michael: I didn't try *not* raising exceptions in my test.

AP: Michael to benchmark try blocks that do not raise exceptions.

Jinmei: Should also try cost with various compilers. Point of
bottleneck of exception handling varies. Sometimes just using "try" is
expensive, but exception is expensive.
Michael: Will try on NetBSD, test was from Mac
Shane: There is also maybe gcc vs. lvcc
Michael: What if one system is bad?
Shane: Hopefully *everyone* optimizes for non-exception case
Michael: I read the guide for developing C++ compiler, and it advises
optimizing for non-exception case


   * Robustness

Michael: Maybe we should make a classification: exit vs. non-exit
exceptions
Shane: Does C++ have something like a "finally" block?
Jinmei: No
Shane: I think we have to come back after we've used some code.


Michael: Can you allocate memory in an exception?
Shane: Yes
Jinmei: For resource allocation - you should use destructors since we
don't have finally.





* Component status
   * General question: discussion on call helpful, or written updates?

Michael: In sweng we have GOALS/DONE, no reason not to have this
Shane: Okay, we'll keep current format where we discuss everything on
our call.

   * c-channel

Michael: No big changes, learning Python and learning C++, because
writing a program was not enough to learn the language (Python)
Michael: If I write tests for Python side of thing, then it's "done"
Michael: Then C++ next

Shane: Is the Python stuff usable?
Michael: Yes, still require BIND 9 libraries for now, can send/receive
around 1500 messages per second in pure Python/Ruby

Shane: Next steps include design doc and drawings
Michael: Next steps are tests
Shane: Okay


Evan: A bit concerned about getting a string representation of
integers, rather than the actual integers. For example, pointers
Michael: If you pass in a blob it will work, if you pass in a
int/float it gets converted to strings
Michael: It's much easier to use than to explain


   * Message API
Jinmei: Not so many things to report. Moving forward from experimental
to development status. Everything was done on the list. Plan to finish
that in parallel with documentation on main trunk this week.

Jinmei: One question. Do I need to make separate branch from main
trunk?
Michael: Main reason is to make certain things are reviewed properly.
Had plenty of chance to review, okay directly to branch. Most
development can occur directly on branch at this stage.
Shane: Seems quite pragmatic
Larissa: Need to make sure we understand when we cross over into the
other realm


   * Configuration Manager
Jelte: Playing around with XML schemas to see if a module writer could
specify configuration data and constraints on that. Decided that
writing XML schemas is not a lot of fun, and overly complicated.
Michael: What language did you use choose?
Jelte: XS namespace. 
Jelte: We can do a lot easier, but it depends on whether we want the
XML to look like the experiment now, or a more general one (item,
list, value).
Michael: Take a look at data format for c-channel stuff...
Jelte: Perhaps we should lift the base structures from that instead of
the XML library that I am using now?
Michael: I like the idea of tag:value hierarchy. Love the idea of
upgrading with old configuration database and moving up to date.
Shane: That is quite sexy when it works.

Jelte: I am also thinking about a way to make a difference between
live and static checking. Configuration might ask module "are these
useful"?  "yes/no/useful but not when running". Easy to do when
running, but not easy to do in generic way with something like
"named-checkconfig".
Michael: Each module itself should be in charge of configuration
format.

AP: Shane send outcome of user interface meetings at RIPE.

Michael: More than one blob per module, "fetch list of zones", then
"fetch configuration" per zone.
Jelte: BTW, reading "Effective C++"... great book!


   * BigTool
Feng: Syntax for command line, currently got feedback from Jinmei and
Shane about syntax, very helpful to me.
Feng: I will add "help", got very useful suggest about instance, plan
to move instance name to between module name and command name. If
syntax for command line is already acceptable or good enough, then can
fix it and move on. Want to see for syntax fixed or not.
Jinmei: I didn't see anything obviously wrong, but cannot be so sure
with only a few examples. Move forward with current idea and when we
see many other configuration examples we may be able to discuss more
details in the syntax, if you don't mind revisiting the whole syntax
at that point.
Feng: Suggestion is very good.
Shane: As a general philosophy - *everything* may be changed after we
try it.
Jinmei: Is the Python version is final, or re-written in C++?

Jinmei: I don't see need for C++
Michael: I prefer not to see in C++
Shane: I agree

Michael: I would also like to see module to import.
Shane: Already written that way
Jelte: Saw on diagram that this would be talking to configuration
manager.
Shane: Yes, that is correct, everything will go through command
channel
Likun: Configuration daemon same as configuration manager?
Yes

Michael: Should I import c-channel into main tree?
Shane: Yes, good idea


   * Statistics
Fujiwara-san looking at c-channel stuff


A.O.B.

Jeremy: What about final server?
Shane: That is AuthSrv, waiting on a few pieces.
Jinmei: Not sure about question...
Jeremy: I was just curious if somebody was already planning it, using
libevent, and so on, forgot on Wiki and can look there!

Michael: We're using .cc for C++, are we using .hh?
Jinmei: I started with .hh, but have no preference
Evan: Most C++ projects use .h
Michael: When converting from prototype to production, lets use .h
Shane: I agree
Evan: I agree, use .cc for C++ files?
Michael: Yes

Michael: Since we are meeting face to face on the 26th, are we having
a meeting next week?
Shane: Yes, unless otherwise noted!

--
Shane