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> 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>
