[ovs-dev] pwclient XML errors and form feeds

Aaron Conole aconole at redhat.com
Tue Aug 15 13:15:55 UTC 2017


Hi Mark,

Mark Michelson <mmichels at redhat.com> writes:

> Earlier today on IRC I brought up an error I had while attempting to use
> pwclient to get a patch from patchwork. Here [1] is the pastebin I linked
> to. At the time, I thought it was due to HTTP chunked encoding being used
> and the xmlrpclib or HTTP client library not handling that properly.
>
> I debugged the problem further and I now have figured out that the problem
> has to do with a form feed character being present in the patch. The
> Patchwork server places the patch text inside an XML 1.0 document; however,
> form-feeds are illegal in XML 1.0 [2]. This makes the use of form feeds and
> the use of pwclient incompatible.
>
> Aaron Conole pointed out that once Patchwork 2.0 is available, the git-pw
> command will render pwclient obsolete. I checked, and git-pw will use
> Patchwork 2.0's REST API (which is JSON-based) instead of XMLRPC, so this
> is indeed only a temporary problem.
>
> In the meantime, is there some other command line tool OVS devs use instead
> of pwclient for getting patches?

I use curl.  I guess pwclient could probably be patched to fix this
issue.  However, I think the xmlrpc interface isn't as nice as the
RESTful api being implemented by patchwork 2.0.

> Also also, can someone inform me why the coding guidelines encourage using
> form feeds? Do they aid in documentation generation? Do people use editors
> that render them in some meaningful way? Searching git logs and the mailing
> list archives didn't give me anything to go on.

Time to get all old-timey and preachy ;-).

Form feed, as a control mechanism, is a bit outdated.  It was really
useful in the 80s and 90s, because:

  1. Printers understood it
  2. Editors at the time understood that backward-page and forward-page
     should use the form feed as a pagination delimiter.
  3. Having lots of smaller files was more problematic than a few large,
     sectioned files because dependency tracking wasn't quite there.
  4. People knew why the convention of form feed was used.

Nowadays, most people don't know why projects (especially older projects
such as emacs) use the convention, especially since modern editors are
really good at contextual help, direct jump to any kinds of symbols, and
autocompletion (features that didn't exist in a really usable fashion
until the early- to mid-2000s).

For those folks who do use editors which understand (such as emacs, and
vi/vim), you can easily jump between logical sections of a file.  For
instance, it might be customary on some projects to have the file laid
out:

------------- >8 -------------
// This is the header
// it includes crazy things that cvs will insert
// such as $author: $
// and $log: $



#include <includefile1>
#include <includefile2>
...
#include <thelastincludefile>



static const int foo = 0xdeadbeef;
static const int bar = 0x1baddad0;
static const int baz = 0xdbdbdbdb;



static long int ffoo() {
...
}

static long int fbar() {
...
}

...



MODULE_INIT(__init_fn);
MODULE_NAME("SomeModule");
------------- >8 -------------

And (for instance) with emacs, pressing 'C-x ]' allows skipping between
the various 'logical' sections, while 'C-x [' skips backwards
similarly.  For vi / vim, I'm not sure.  I thought ']]' and '[[' were
the delimiter search keys, but the delimiters they use are opening
brace at the beginning of a line.  And other editors... well.. sorry.

It's a convention that doesn't bother me, but I don't think is really
well known anymore (and will cause problems when we try to use some
tools which don't understand the convention - as you see).

Hope this helps answer the question :-)

> Thanks,
> Mark Michelson
>
> [1] https://paste.fedoraproject.org/paste/gE6neR6-Yf19YnO7hM576g
> [2] https://www.w3.org/TR/REC-xml/#charsets
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list