By the way, we have what we believe to be the most correct and complete Rust implementation of Avro here: https://github.com/MaterializeInc/materialize/tree/main/src/avro <https://github.com/MaterializeInc/materialize/tree/main/src/avro>
You are welcome to use it (and the related `avro_derive` crate in the same repo) under the terms of the Apache License v2.0, if it would be useful to you. Unfortunately the docs are very outdated, so your best bet would be to look at how it's used in Materialize for guidance. You should also get the latest code out of that repo directly, rather than using the outdated version on crates.io <http://crates.io/> . > On Feb 17, 2022, at 11:35 AM, Brennan Vincent <bren...@umanwizard.com> wrote: > > Hello, > > Why was I included in the To: field of this e-mail; do you have a > question/comment for me specifically? > >> On Feb 17, 2022, at 10:47 AM, Askar Safin <safinas...@mail.ru >> <mailto:safinas...@mail.ru>> wrote: >> >> Hi. >> >> To all: it seems my language was too strong. I'm sorry about this. But I >> still >> don't plan to fill separate bug reports or pull requests. >> >> To Dan Schmitt: >> Воскресенье, 13 февраля 2022, 3:55 +03:00 от "Dan Schmitt" >> <dan.schm...@gmail.com >> <https://light.mail.ru/compose?To=dan.schm...@gmail.com>>: >> > * [Opinion] [Line 737]. "The 16-byte, randomly-generated sync marker >> > for this file". I don't like this point. It >> > implies that container files are usually not equal. Thus it is not >> > possible to compare them bitwise to determine >> > equality. So, in my Avro implementation I write null bytes instead of >> > this marker (yes, this possibly means that my >> > implementation is non-conforming) >> > * [Opinion] [Line 717]. There is no any marker for end of container >> > file. Thus there is no way to determine whether all >> > data was written >> > >> > If you use the sync marker, you don't need an end of container marker. >> > (Flush the sync and container block map with new data after the new >> > block is written, if you have the metadata and block list you know that >> > much is complete and written for you to read, if you read the metadata >> > and your sync byte marker is wrong, go re-read/continue read.) >> What you mean by "metadata"? Header of this particular block? Or something >> in header of whole container? >> >> > * [Bug] [Line 292]. "The null namespace may not be used in a >> > dot-separated sequence of names". You defined previously >> > null namespace as a empty string instead of *whole* namespace. I. e. >> > null namespace is lack of namespace (i. e. lack of >> > whole dot-separated sequence). So there is no sense in speaking on >> > using null namespace in dot-separated sequence. You >> > probably mean that one should not use empty string in dot-separated >> > sequence >> > >> > That doesn't read as a bug at all to me, you have introduce a "whole >> > namespace" and only then does it not make sense >> > >> > a.b.c - a is the top level namespace, b is a namespace in a, c is a >> > namespace in b. >> > >> > Probably easier to read up on C++ namespaces and nesting and full >> > specification to see how your introduction of "whole namespace" where >> > it doesn't exist is what is causing your confusion. >> You assume that Avro namespaces are nested in sense of C++ namespaces. But >> spec >> doesn't say about this. From Avro point of view (as per spec) namespace >> "a.b.c" is >> simply opaque string. Namespace "a.b.c" doesn't live in "a.b". The only >> special component in >> fullname is its last component, i. e. name. Everything else is one namespace. >> So, if you think that namespace are nested similarly to C++'s ones, add this >> to spec. >> But I think this will add nothing to spec, so there is no need in such >> addition. >> >> >> == >> Askar Safin >> http://safinaskar.com <http://safinaskar.com/> >> https://sr.ht/~safinaskar <https://sr.ht/~safinaskar> >> https://github.com/safinaskar <https://github.com/safinaskar>
