Changes between Version 1 and Version 2 of WeeklyMinutes20100114

Jan 15, 2010, 8:14:10 PM (9 years ago)



  • WeeklyMinutes20100114

    v1 v2  
    111111== DNS Message API ==
    113 [ checkpoint save ]
     113Jinmei: completed latest branch of Message API which includes RR types, classes, TTLs. Going for review - ticket #21. Implementation is pretty trivial I think. I believe it is relatively easy to review.
     115Jinmei: thinking of moving on to the rest of the API, as well as spending some time on the data source API.
     117Jelte will review ticket #21.
     119== msgq ==
     121Michael: no review ticket yet [ update - ticket #22 and #23, to be reviewed by Likun & Feng ]
     123== Configuration ==
     124Jelte: put up ticket for review of small part (Element class, which is the data files) - also used by stuff which uses the msgq. But no time spent on general configuration again (busy with data source).
     126Michael will review ticket #20.
     128== Command & Control ==
     129Likun: plan to create a new branch based on Jelte's changes, maybe next week commit to tree
     131Jelte: if I made any changes to bigtool that you disagree with, feel free to tell me
     133Likun: only change was going through command & control rather than sending direct. so replace old bigtool with command & control
     135== Statistics ==
     136Fujiwara-san: read Jeremy's ideas, considering what we need to define, will send my ideas tomorrow.
     138Kambe-san: coding prototype of SNMP agent. Have not yet committed to experimental repository but I think I will within a few working days.
     140== BoB ==
     141Shane: fixed signal handler
     143[ Some discussion about SO_REUSEADDR option in the msgq - call setsockopt() before bind()! ]
     145= Data Source =
     146Jelte: nice talk on Tuesday, I sent around on list, Michael did too. Promised that I would send out an updated proposal, but not finished yet.
     148Shane: where are we at, as of 2 days later...
     150Michael: hoping we can get to coding soon! Is this going to be SQLite, in-memory, or what?
     152Shane: simplest would be a vector of structures with a for loop around it
     154Michael: just to flush out the API. I think the first one should be SQL.
     156Shane: eventually we'll need a generic SQL version... but maybe not...
     158Michael: generic SQL back-end is hard
     160Michael: 3 goals in data source API:
     161  1. Anybody can write these, even if just fixed data from a script!
     162  1. Some semblence of sanity in the way data is associated together (signatures need to be part of data)
     163  1. Code reuse possible as much as possible
     165Michael: So we have to have some intelligence at the low level. So maybe callback functions.
     167Jelte: I was looking into what we need to have a "catch-all" data source, where you don't know whether we have the zone in advance. So a "do you have this zone" function, or "what would be the zone for this name?". Maybe we need an init() function that you then use on a data source.
     169Shane: is this something that happens every search, or...?
     171Jelte: it could be, or one that you use for a class of search functions later.
     173Michael: we need something like "what is the best zone you can give me for this query?"
     175Shane: we agree that we need a data source where you don't know what zones it serves?
     177Michael & Jelte: yes
     179Michael: I understand updating signatures need to be updated with RRSETs.
     181Shane: I was thinking of the query case as more worrying.
     183Michael: not a problem as long as you know about signatures...
     185Shane: worried about putting NSEC & NSEC3 processing in the lower level
     187Michael: signatures need to be part of data. Flag that says "no DNSSEC supported".
     189Shane: more worried about how we can get consistent data out
     191Michael: no reason to make it complicated for how to use this API
     193Shane: if API consumer has no way to say "these queries are related", API provider has no way to know to make them consistent
     195Michael: find() is implemented on top of findRRset()... so if we need transactions, they would be in the low level
     197Jelte: I just didn't call find() I called it getData or something.
     199Michael: may as well call it find()
     201Michael: update queue serial if necessary...
     203Michael: but not now!
     205Shane: outstanding issues?
     207Michael: who's doing what, and so on, so we have something at end of January
     209Shane: sure... re-rev of header file would be cool.
     211Jelte: already doing that in special branch of parking lot so it's staying at a "it still works" level
     213Michael: would also like RDataSet to contain signatures as well
     215Jinmei: can simply go with current parking lot API. Don't expect interface will be so changed.
     217Michael: addition of one other thing...
     219Jinmei: right, we can easily adapt it later
     221Michael: so for now we can assume we are not using DNSSEC
     223Jinmei: regarding time frame... depends on the goal of the next face-to-face version. Actually want semi-working or completed.
     225Michael: never completed! Semi-working base idea by end of January is the goal. Time to code together?
     227Shane: most of the week is coding I hope!
     229'''AP''' Shane to make agenda for face-to-face meeting
     231= AOB =
     233Larissa: sent mail to staff list about arriving/leaving for face-to-face will have Kat set up hotel arrangements
     235Michael: which hotel?
     237Larissa: same as for all hands