Changes between Version 1 and Version 2 of WeeklyMinutes20100114


Ignore:
Timestamp:
Jan 15, 2010, 8:14:10 PM (8 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20100114

    v1 v2  
    111111== DNS Message API ==
    112112
    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.
     114
     115Jinmei: thinking of moving on to the rest of the API, as well as spending some time on the data source API.
     116
     117Jelte will review ticket #21.
     118
     119== msgq ==
     120
     121Michael: no review ticket yet [ update - ticket #22 and #23, to be reviewed by Likun & Feng ]
     122
     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).
     125
     126Michael will review ticket #20.
     127
     128== Command & Control ==
     129Likun: plan to create a new branch based on Jelte's changes, maybe next week commit to tree
     130
     131Jelte: if I made any changes to bigtool that you disagree with, feel free to tell me
     132
     133Likun: only change was going through command & control rather than sending direct. so replace old bigtool with command & control
     134
     135== Statistics ==
     136Fujiwara-san: read Jeremy's ideas, considering what we need to define, will send my ideas tomorrow.
     137
     138Kambe-san: coding prototype of SNMP agent. Have not yet committed to experimental repository but I think I will within a few working days.
     139
     140== BoB ==
     141Shane: fixed signal handler
     142
     143[ Some discussion about SO_REUSEADDR option in the msgq - call setsockopt() before bind()! ]
     144
     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.
     147
     148Shane: where are we at, as of 2 days later...
     149
     150Michael: hoping we can get to coding soon! Is this going to be SQLite, in-memory, or what?
     151
     152Shane: simplest would be a vector of structures with a for loop around it
     153
     154Michael: just to flush out the API. I think the first one should be SQL.
     155
     156Shane: eventually we'll need a generic SQL version... but maybe not...
     157
     158Michael: generic SQL back-end is hard
     159
     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
     164
     165Michael: So we have to have some intelligence at the low level. So maybe callback functions.
     166
     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.
     168
     169Shane: is this something that happens every search, or...?
     170
     171Jelte: it could be, or one that you use for a class of search functions later.
     172
     173Michael: we need something like "what is the best zone you can give me for this query?"
     174
     175Shane: we agree that we need a data source where you don't know what zones it serves?
     176
     177Michael & Jelte: yes
     178
     179Michael: I understand updating signatures need to be updated with RRSETs.
     180
     181Shane: I was thinking of the query case as more worrying.
     182
     183Michael: not a problem as long as you know about signatures...
     184
     185Shane: worried about putting NSEC & NSEC3 processing in the lower level
     186
     187Michael: signatures need to be part of data. Flag that says "no DNSSEC supported".
     188
     189Shane: more worried about how we can get consistent data out
     190
     191Michael: no reason to make it complicated for how to use this API
     192
     193Shane: if API consumer has no way to say "these queries are related", API provider has no way to know to make them consistent
     194
     195Michael: find() is implemented on top of findRRset()... so if we need transactions, they would be in the low level
     196
     197Jelte: I just didn't call find() I called it getData or something.
     198
     199Michael: may as well call it find()
     200
     201Michael: update queue serial if necessary...
     202
     203Michael: but not now!
     204
     205Shane: outstanding issues?
     206
     207Michael: who's doing what, and so on, so we have something at end of January
     208
     209Shane: sure... re-rev of header file would be cool.
     210
     211Jelte: already doing that in special branch of parking lot so it's staying at a "it still works" level
     212
     213Michael: would also like RDataSet to contain signatures as well
     214
     215Jinmei: can simply go with current parking lot API. Don't expect interface will be so changed.
     216
     217Michael: addition of one other thing...
     218
     219Jinmei: right, we can easily adapt it later
     220
     221Michael: so for now we can assume we are not using DNSSEC
     222
     223Jinmei: regarding time frame... depends on the goal of the next face-to-face version. Actually want semi-working or completed.
     224
     225Michael: never completed! Semi-working base idea by end of January is the goal. Time to code together?
     226
     227Shane: most of the week is coding I hope!
     228
     229'''AP''' Shane to make agenda for face-to-face meeting
     230
     231= AOB =
     232
     233Larissa: sent mail to staff list about arriving/leaving for face-to-face will have Kat set up hotel arrangements
     234
     235Michael: which hotel?
     236
     237Larissa: same as for all hands