(To clarify: we have NOT licensed that entire Materialize repo under Apache v2.0. I am only referring to the `avro` and `avro-derive` crates).
> On Feb 17, 2022, at 1:11 PM, Brennan Vincent <bren...@umanwizard.com> wrote: > > 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 >> <mailto: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> >
