On Wed, Feb 6, 2019 at 1:30 PM Vlad Grigorescu <v...@es.net> wrote: > I _think_ I like Seth's idea of records, but I'm still thinking it through. > It would formalize a growing trend towards moving more parameters into > records anyway. If we're worried about backwards compatibility, then maybe we > have a built in version number in each record. Whenever fields are > added/removed, or there are more subtle contextual changes, the version > number could increase.
Explicit versioning is a neat idea to maybe try expanding on. I'm not quite sure how it would look for the user to, when they write their code, make it explicit that they expect the semantics of the record to match version XYZ. But yeah, on our end, we could ensure that if we see someone wanted XYZ, we send them that version of the record, which matches their semantic expectations. > As a concrete example, the is_server parameter of the ssh_capabilities event > was being set backwards (effectively as "is_client.") In this particular example, the way I would have wanted to solve it with my proposed patch would be: deprecate "is_server", document it as actually meaning "is client" (don't change semantics of that parameter to avoid breaking user code that is already doing the inversion), but do introduce a new "is_client" which actually means "is client", then later remove "is_server". - Jon _______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
