Subject: Re: IPP>PRO: sorry, binary is better (?)

From: "Sylvan Butler" <[email-masked]>
Date: Fri, 20 Jun 1997 10:18:59 -0700

>This stuff is really too easy and we shouldn't worry about the
>differences between
>ASCII and binary at this point. The code difference is trivial.

That is what I was thinking on Tuesday 6/17, but actually doing 
something with it and covering all the possibilities with ASCII seems 
noticably more complex to implement and to test, and for no apparent 
benefit.

>I thought we have already made this decision?

Those at the meeting, including myself, had arrived at a
recommendation for the group.  That is why I said "sorry" for
opening the issue again.

>You have to have tokenizing capability in an implementation anyway,
>to support the HTTP headers and chunking...

Somewhat different constraints, and conceivably a significantly 
different part of the system.

>typedef struct {
>                 char *attrName;
>                 int  attrLength;
>                 char *attrValue;
>               } ATTR;
>
>/* Most optimizing compilers would attempt to inline the next_delim/next_token     functions for performance */
>char *next_delim(char *stream)
>{
>   while (!isspace(*stream)) ++stream;
>
>   return(stream);
>}
>
>char *next_token(char *stream)
>{
>   while (isspace(*stream)) ++ stream;
>
>    return(stream);
>}
>
>/* This routine assumes that the current position in the input or buffer stream is placed at the first character of the attribute name */
>
>int GrabAttr(ATTR *pAttr, char *inpstream)
>{
>   int sts = OK;
>
>  pAttr->attrName = inpstream;
>  inpstream = next_delim(inpstream);
>  *inpstream++ = '\0';
>  inpstream = next_token(inpstream);

I don't think we want to do that.  We defined it as one <SP>, 
skipping more will throw us off.  Just removing next_token should be 
fine.

>  for (pAttr->attrLength = 0; (isdigit(*inpstream)); inpstream++)
>    pAttr->attrLength = (pAttr->pAttrLength * 10) + (*inpstream -'0');
>  pAttr->attrValue = next_token(inpstream);

Again.

>   return(sts);
>}

I like that.  Very clean.

It does have the same concern that Bob's raised, that of validating 
the assumptions of the buffer containing the next delimiter.  It 
appears much easier to fix in this version however...

Like the binary solution, just quit making the assumption.  With no 
library routines then each loop also checks for the end of the data 
(by count).

Both text parsers leave us with the need for doing strcmp's, etc. to 
match keywords.  And for what?

sdb

 | Sylvan Butler | [email-masked] | AreaCode 208 Phone/TelNet 396-2282 |

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 20 Jun 1997 13:08:17 -0400

>>>>> "SB" == "Sylvan Butler" <[email-masked]> writes:

SB> That is what I was thinking on Tuesday 6/17, but actually doing
SB> something with it and covering all the possibilities with ASCII seems
SB> noticably more complex to implement and to test, and for no apparent
SB> benefit.

  I'm sure that the complexity won't be overwhelming :).

  The benefit is that the protocol is human-readable.  Don't discount
  this too much; you are not going to quickly get vendors of network
  monitoring equipment deploying versions of thier products that will
  decode IPP (not until long after you're done, if history is any
  guide).

  The first step in debugging any distributed operation is finding out
  what went over the wire so you can determine who did what (and using
  the opinion of one end of the wire for this is a good way to go down
  a lot of dead ends).

  One other note: when developing any protocol, one always discovers
  that things you thought would be easy aren't, and often the reverse
  too.  If these discoveries always justify reopening early and
  fundamental design decisions (good or not so good), then you can end
  up with a process that goes on for a long long time...

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/