Changes between Version 1 and Version 2 of WeeklyMinutes20100720

Jul 20, 2010, 4:19:03 PM (8 years ago)



  • WeeklyMinutes20100720

    v1 v2  
    1 = BIND 10 meeting minutes NOT COMPLETE - THESE WILL BE NONSENSICAL!!! =
    31== Attendees ==
    8 Jelte
    9 Shane
    12 Fujiwara
    13 Jeremy
    14 Stephen
    16 Larissa
    18 Michael
    2322=== C++ templates: Evil or Just Misunderstood ===
     24Came from Stephen looking at base-N code.
     26Stephen summarizes his mail.
     28Stephen: Templates are a part of C++ now. Growing in importance. Some people get carried away. But need to know about them and use them.
     30Stephen: Jinmei made valid point about algorithms in the STL. This is probably not different from any languages where the complexity is in the libraries. I think we ought to consider templates and we ought to use them. More interesting... when we come into using optimization later on, the suggestion seems to be you can trade off runtime overhead in exchange for compile-time overhead. I haven't pursued this in any depth, but it might be worthwhile looking at this. Potentially Jinmei's base-N code is an example of that. If I had written this without using templates, it would have added statements to run time, but now it is all done at compile time.
     32Jinmei: Basically I think I agree with Stephen. But I don't have a clear idea about what we should do.
     34Stephen: I think it's more of a case of having a look and using them in the appropriate situation. I don't think you can make any a priori assumptions about when you can use them or not. For example, maybe we could have a class templated on the resource record class. We have to recognize that not everyone is familiar with them, and the syntax is intimidating. Some of the standard libraries are not great in terms of documentation. A reasonable check for a reviewer is, "Am I taking a long time to understand this?" When reviewing the base-N, I did understand it in the end, but it took a long time without the documentation there in the first place.
     36Shane: Was this template part of the STL or Boost or?
     38Jinmei: It's actually not STL or Boost, but it's a interface of the Boost library using some templates. Due to the complexity of the original Boost implementation the resulting interface looks complicated.
     40Stephen: Where the complexity came in is the idea of embedded iterators. So Jinmei wrote an iterator around the standard iterator on the input stream, which was handling the whitespace. Around *that* was a Boost iterator which is handling a transformation. So you have this idea of using an iterator who's template parameter is an iterator who's template parameter is another template parameter. So there's all this nesting, and it takes a while to get your head around.
     42Stephen: I think it's just a question of getting used to it.
     44Larissa: Would it be useful if there was more documentation/guidance by someone on our team for the people who don't?
     46Shane: Do we implement our own template classes?
     48Stephen: Whether you implement your own template classes or not depends on whether the situation requires it. I think it's really a case of looking at the problem and deciding whether or not to use templates for it.
     50Jinmei: Do you mean the interface of the public library for BIND 10?
     52Shane: That's one part of it.
     54Jinmei: We already use in some part of our code. In the public interface AFAIK we don't use so far. Again I don't think it's whether or not to use templates, if we keep it simple then I don't it causes any problem.
     56Shane: Is anyone uncomfortable with that approach.
     58Likun: My opinion is that make sure that we can't overuse a template. I was reading in some books, if we can do it in normal C++ code we don't need to use templates. That's better than overuse.
     60Michael: What are the dangers of overuse, other than the code being harder to read and use?
     62Likun: If we write some simple code it's very easy to understand with normal C++, and for every programmer. At least the template should not be a tool to show your coding skill.
     64Michael: They seem very useful - it gives you a typechecked generic data structure. I'm not sure why we would want to use it all over the place.
     66Stephen: Some compliers do have options to control run-time code size bloat.
     68Evan: What you are all saying about templates is more-or-less what I would say, but if we are getting into realms of template programming that are beyond our expertise, maybe we should talk to someone from the Boost team or other expert and see if they are willing to vet our code.
     70Jinmei: In this particular case it might be an option, but there will be other cases which are purely internal in our source code.
     72Shane: Even in that case we can *ask* for help... but you're right we may not find any.
     74Jinmei: Frankly I don't think we can have a particular guideline... today. So I am basically fine with the case-by-case basis approach.
     76Jinmei: Hopefully at the face-to-face meeting we may want to discuss more specific cases, like whether it is generally acceptable to use STL. When, for example. And if the answer is yes, we probably want to ask if someone doesn't know about it, it should be all right. Or if it is not acceptable we should avoid using that as a guideline. Otherwise we will have similar discussion in the future review when the developer uses a particular style and the reviewer does not understand.
     78Stephen: I think the distinction is whether we should be writing templates or not. STL is part of C++, and Boost is on the track for TR1. Maybe Jinmei or I could give a short overview of the libraries.
     80Evan: The problem is not using, but rather writing. Do we want to work in a language that we all speak and limit ourselves into this really complicated programming, or do we want to take advantage of people who have expertise in that kind of coding. We have Stephen and Jinmei who are both comfortable with this, so it's okay.
     82Michael: In BIND 9 we did an overview of tricky code. Maybe we should do that at the all hands. I suspect that it is tricky, and not always straightforward and clear, but once you understand the techniques it becomes clear.
     84Stephen: Doesn't this argue that it is going to the heart of program documentation?
     86[ Discussion of coding, familiarity with languages & techniques, ... ]
    2588== Architectural issues ==
    2790=== Multi-machine receptionist benchmarks? ===
     92Stephen: Work in progress now.
     94Jinemi: I didn't fully review the report and code due to the unexpected event for BIND 9 last week, but I quickly took a look at it, and I have some comments.
     96Jinmei: First that this benchmark is performed on a single machine, running client, receptionist, and server?
     98Shane: Yes.
     100Jinmei: From my past experiences this may affect performance due to loopback performance. Also the additional context switch for the client. So maybe it's better - especially if we want to have a more accurate performance measurement - to use at least 2 machines.
     102Stephen: You're probably right. It is only an approximation. The benchmark is as close to synchronous as it could be. There is a bit over overlap, but it is more to give an indication of additional overhead rather than an absolute measurement. You're right; if we're doing a true benchmark, then we want to use this asynchronous form. But what do you do with lost packets? At the moment, we send 1000 and receive 1000 and measure the time. It gets more complicated when you have the server on a different machine - because you may have dropped packets. At the moment it is purely an indication. When I finish the asynchronous work we do need to discuss it in more detail, and see whether there are any changes we should make.
     104Jinmei: I don't understand the asynchronous version well, but maybe the client program should be more something like queryperf rather than sending a batch of queries and waiting for replies.
     106Stephen: Yes that's what the asynchronous version is doing. One thread sends one thread receives. If the sending thread gets too far ahead it will wait until the appropriate number of packets come back.
    29108=== More ===
     110Jinmei: Maybe we want to revisit for which purpose we want to use this model, just like Stephen asked last week. For example, if we simply want to separate authoritative and caching server, we may be able to a simpler approach, where one of the authoritative and caching server is accepting all of the queries first and forwards the queries it does not handle to the other server. In general we expect these two servers to use different addresses to listen on, and use the forward model for other exceptions. In that way we may want to ignore the overhead for the forwarding case since it is an exceptional case just to act correctly. My point is that, depending on why we want to do this, we may want to explore other approaches.
     112[ Shane rambles about microkernels and "cheating". ]
     116Stephen: You said something last week about the cache. Also going back about redundancy and multiple purposes. Does the cache include shared memory with multiple updaters?
     118Stephen: Will the cache design be discussed at the all hands?
     120Shane: Yes. There may be work before then, but yes.
     124Jinmei: Question about what to with utility functions like SHA1() or base64() or things like that.
     126Jinmei: Stephen asked about this in the review of the base-n code. We simply want to rely on external libraries for generic crypto or the encoding/decoding things. But in the case of DNS library it's very primitive in the BIND 10 code, and in some cases the user may not want to install the other libraries. So to be self-contained as much as possible we decided to use a minimal set of utility functions. That's my understanding...
     128Jinmei: Based on this understanding, I think we do not want to use these utility functions, even from other BIND 10 modules. If they want to use something like that, we want them to use the external libraries, or limit the use for specific RDATA interfaces rather than using the low-level utility functions.
     130Shane: Is there a compile-time option to use any other libraries now?
     132Jinmei: It's a future possibility. Eventually we want to do this, especially for the support for validation. At that point we may want to selectively use external crypto libraries.
     134Shane: Is there any indication that these are not recommended?
     136Jinmei: I'd write a README file, but of course we can also use a language-level indication to explain the intent. Maybe that's something like some of the Boost libraries use, the "detail" namespace.
     138Shane: Maybe you can make a ticket for this?
     140Jinmei: Okay.
     144Jinmei: I implemented the change user option for the authoritative server, and I want to get it reviewed.
     146Shane: I'm reviewing that, should be done tomorrow.
    31148== Mascot contest status ==
    33150== IETF ==
     152Likun; Call meeting time next week is normal?
     154Shane: Yes.
     156Jinmei: Are we meeting in a hotel room?
     158Larissa: I have a SIP phone client for my iPhone we can try.
     160Jelte: I was just looking at SIP clients for my phone.
     164Larissa: Do we need to talk about the following week?
     166Shane: We can talk about it next week! (I am going on vacation after the IETF.)