[Box Backup] Win32 port (was: BoxBackup Server Side Management Specs (Draft0.01))

[Chris Wilson]

Hi Ben,

> Yes, that seems reasonable. I don't want to put lots of code in the 
> daemon for things which it doesn't really need to do.

I agree. That means that the changes to Box will be minimal, which is good 
for both of us (not least for me because I'm really struggling to keep up 
with your mastery of C++ :-)

> That's easy enough to do, and doesn't require too much extra code.

Excellent, I'll do that then.

> It's only provided on login, or when a specific command is sent to 
> retrieve it in more detail.

Then presumably bbackupd must query the server occasionally to determine 
that it's not over limit? If so, would you be happy for it to cache the 
responses, to help the GUI client?

> How about a simple \n terminated terminated line, with tab separated 
> message name and arguments? Nice and easy to parse, nice and easy to 
> write, extend by adding new messages or arguments.

It lacks human-readability, extensibility and robustness. In order to 
understand the output when "parsing" by hand, you have to learn by heart 
what each column stands for. With XML, the columns are self-describing.

How do you deal with third-party extensions to the protocol? With XML, you
can just create a new namespace to hold those attributes and tags, and the
client can ignore them. Any sensible solution to the problem is bound to
be similar to XML's.

How about if Box was forked one day, or independent, incompatible protocol
changes made in the stable and development versions? Such changes would
normally make the forks incompatible with each other, from the view of the
client, because they would re-use the same columns for new purposes.
Labelling columns makes this almost not an issue, and the same client
could probably work with both forks, with maximal shared code, and minimal
client complexity.

For robustness, there are many special cases to deal with, in terms of 
data encapsulation. For example, filenames can contain tabs, newlines and 
null bytes, all of which need to be escaped. The escape character itself 
needs to be escaped. Once you have dealt with that, the reader needs a 
parser of considerable complexity. I would not be at all sure that I had 
got it right, especially not without the extra syntactic sugar of the tag 
<start> and </end> markers.

> Why should there be a burden anyway, for the sake of using the latest 
> buzzword?

It's not for the _sake_ of using a buzzword, in fact, I think it would be 
considerably easier for me to import a standard XML library, than to write 
a custom parser of any complexity and have confidence in its stability and 
security. The overhead then would be in extra executable size, but that's 
in the GUI client, so with all due respect, it's my problem.

The overhead in the backup daemon is approximately zero. Compare your 
suggestion:

	stream << "file\t";
	stream << Escape(File->ID) << "\t";
	stream << Escape(File->Parent) << "\t";
	stream << Escape(File->Name) << "\t";
	stream << Escape(File->Age) << "\t";
	stream << Escape(File->State) << "\t";
	stream << Escaoe(File->Error) << "\n";

and mine:

	XMLTag tag("box:file");
	tag.add("id", File->ID);
	tag.add("parent", File->Parent);
	tag.add("name", File->Name);
	tag.add("age", File->Age);
	tag.add("state", File->State);
	tag.add("error", File->Error);
	stream << tag.ToString() << "\n";

These are almost identical, and all that's needed in addition is a pretty 
simple XMLTag class. 

> No XML will not be integrated into the backup engine, sorry.

I'm having difficulty understanding whether your objection to XML is 
philosophical or practical. Myself, I think that its practical benefits 
far outweigh its disadvantages, in all but the most extreme circumstances 
(tiny systems, huge systems, huge data volume; of which this protocol 
needs none), and I don't understand a philosophical objection. XML became 
popular for a reason, not because it was popular.

I really dislike over-simple protocols that make too little concession to
being easy for both humans and machines to read, future-proofing or
robustness. A little effort at design time makes it possible to satisfy
all these criteria. The only happy medium that I have found is XML (and
YAML, but it's almost the same as XML). Everybody is using it. It's not
big or ugly or heavy if you do it right. Good libraries are available.
What's not to like?

> It might be worth sending me an early copy to make sure the design fits 
> in with everything else.

I certainly will send you something when I have got it to compile! Right 
now I'm trying to add support for multiple UNIX sockets into bbackupd in a 
reasonably clean way. I will be happy to send you a patch early if you 
prefer, but it's in a real mess right now.

> Thanks for your efforts!

Thank you for writing Box in the first place, without which my project
would be two years behind where it is now. I only hope that I can persuade 
you on the merits of XML, or another generic encapsulation language, for 
this status protocol.

Cheers, Chris.
-- 
_ ___ __     _
 / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |