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 >: > * [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 https://sr.ht/~safinaskar https://github.com/safinaskar
