Adding a CRLF trailer to named-parameters would make it easier to
optimize parsing of named-parameters and would make the {structure}
look more consistent. A trailing CRLF is what our current examples use
as well. If we go down this path, we should change the above message
definition (again) to make CRLF named-parameter trailer mandatory
everywhere:
message = name [SP anonym-parameters]
( [CRLF named-parameters CRLF CRLF payload] | [CRLF CRLF payload] )
";" CRLF
Olala.
Although being more consistent it looks very strange, I guess that people don't
understand the motiviation here.
This is not an option for me.
Anyway let's call it option 1 for further reference.
Is there a more elegant/consistent way of doing this while keeping
one-liners and CRLF CRLF as a body indication?
Yes, I think so, see below (option 4).
------------------
Or should we accept
some inconsistency and stick with a simpler:
message = name [SP anonym-parameters]
[CRLF named-parameters]
[CRLF CRLF payload]
";" CRLF
structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
I think this is indeed an option. Let's call it option 2.
It is a small inconsistency, but still looks good to me.
------------------
Option 3 is as shown in the OCP core in today's CVS version:
message = name [SP anonym-parameters]
[CRLF named-parameters]
[CRLF CRLF payload]
";" CRLF
structure = "{" [anonym-parameters] [CRLF named-parameters] "}"
This option is consistent but has the non C-style closing bracket problem.
------------------
I would like to propose option 4, my favorite:
message = name [SP anonym-parameters]
[CRLF named-parameters CRLF]
[CRLF payload CRLF]
";" CRLF
structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
This is a consistent and symetric and easy syntax.
It allows for single line messages. Message rendering looks good.
Examples:
CS;
TS 88 10;
DUM 88 1 0
AM-Part: request-body
15:This is my body
;
DUM 88 2 0
20:no named params here
;
CE
Error: "13:Out of memory"
;
Cons: After scanning the anonymous params, the next element could either be a
named param or payload (but we do not have a real-life case for this yet).
Pros: Semicolon is on the same line only for single line commands; otherwise it
is always on its own line
The only message with payload with know today is DUM, it will always have
named params for HTTP and probably also for other applications; here it looks
MIME-like (headers, empty line, body).
I think, scanning is still quite easy. If you want to have the universal
scanner, that allows for payload without named parameters, just check for the
character after the first CRLF. If it is a digit, then there are no
named-params; otherwise use the algorithm that Alex presented earlier
Is this algorithm change acceptable for you?
What is your favorite?
Regards
Martin