Talk:Plugin Link Negotiation Protocol


 * It's drafty in here. Morgaine 22:56, 3 January 2009 (UTC)

Protocol grammar, responder

 * This section isn't quite right, as it doesn't show that multiple responses are possible and that an OK or NO is mandatory. I'll fix it later, unless someone else does first. Morgaine 01:17, 4 January 2009 (UTC)
 * Is it appropriate for a grammar to describe semantics? My notion was that they are meant to express proper formatting, and to provide rules that can be referred to from a natural language description. (Jacek Antonelli 04:06, 4 January 2009 (UTC))
 * Well you're certainly right that pure grammar expresses only syntax. However, we're always trying to make computers do more for us, so if it's possible to add semantic elements to a protocol description, all the better.  In this particular case the semantic of "OK or NO is mandatory" is easily turned into an element of syntax, so the issue becomes moot.  I just haven't put that in yet. :-) Morgaine 04:35, 4 January 2009 (UTC)

Grammar expressed in ABNF
Here's my take on the grammar, in Augmented Backus-Naur form, to see how it looks. It's also a bit more succinct in its rules:

opt-or-arg     =  1*(ALPHA / DIGIT / "-" / "_" / "." / ",") option         =  opt-or-arg argument       =  opt-or-arg want-request   =  "WANT" [ WSP option 0*(WSP argument) ] request        =  want-request / "HELP" / "START" / "QUIT" response       =  ("OK" / "NO") WSP option comment        =  "#" 0*(WSP / VCHAR) message-line   =  ( request / response / comment ) CRLF

I've sneakily limited options and arguments to alphanumeric and a select few punctuation characters. And, I refrained from listing any of the options (json, xml, debug) by name, since I don't think they should be built into the grammar (or else new ones can't be added without changing the grammar). (Jacek Antonelli 03:31, 4 January 2009 (UTC))
 * Think of them as two separate grammars, one defining "option" in terms of the option literals, and another defining the negotiation protocol language in terms of the "option" non-terminal. Short of not defining the set of option names at all, there isn't really any way of decoupling them further. :D
 * When using Yacc/Bison, you sometimes replace a rule by a terminal simply because you can do a better job of emitting good error messages in your lexer than during the Yacc parse, so you've defined the rule syntactically but implemented it lexically. It's somewhat similar here:  we have a grammar rule defining the set of option terminals, but we're not going to use it because our option names will be a token so that we can decouple our negotiation language from our options set. :-) Morgaine 05:00, 4 January 2009 (UTC)