PHP client's _load_items

[Brad Fitzpatrick]

PHP client 1.0.8 is on the website now.  Mostly
whitespace/punctuation cleanup.  Details below.

Lisa, I removed the trailing whitespace so PHP won't send HTTP headers
prematurely.  (Ryan, you'll have to do that on your side too.)

I look forward to a proper fix to _load_items.

- Brad


On Sun, 10 Aug 2003, Ryan Gilfether wrote:

> Brad
>
> attached is the patch to move the 1.0.7 php api to 1.0.8. it fixes the
> incorrect debug wording Brion mentioned earlier and also incorporates
> his patch that for the debugging abstraction. It also fixes some of the
> formatting problems, my editor seemed to use spaces where tabs should
> have been applied in some areas. I might consider editing on emacs or vi
> in the future.
>
> I'll work on the _load_items() function for the next release and see
> what I can do about it.
>
> Ryan
>
> Brad Fitzpatrick wrote:
> > Yeah, the _load_items function in the PHP client is kinda scary.
> >
> > There's no way to treat a socket like a stream in PHP?  The command
> > sending in _load_items is good, but the parsing (especially not
> > respecting END\r\n on any "line") is wrong.  It'd be so much easier if
> > you could read a line or a block at a time.  Then you wouldn't have
> > to remember so much state.
> >
> > Unrelated, that file's in need of some tabs vs. spaces cleanup.  Go one
> > way or the other and be consistent, or at least add all the emacs/vim
> > hints at the top/bottom, so people's editors know how wide you thought
> > your spaces were.
> >
> > Ryan, in the future feel free to post diffs to the list, rather than
> > tarballs to me directly, then everybody can get access to things when I'm
> > away for a few hours, and it's easier to read a diff, too.  If you need
> > help with cvs and/or making diffs from cvs, email me off-list.
> >
> > - Brad
> >
> >
> > On Sun, 10 Aug 2003, Anatoly Vorobey wrote:
> >
> >
> >>Brion Vibber wrote on Sun, Aug 10, 2003 at 02:42:38AM -0700:
> >>
> >>>On further investigation, I note two things:
> >>>
> >>>a) The "_load_items(): Failed to recieve valid header!" is what I get
> >>>anytime I ask for data that isn't available, and seems to be normal.
> >>
> >>Well, if some data you asked for isn't available, it's _not_ an error,
> >>and you don't fail to receive a valid header, so something strange is
> >>going on. A cursory look at the client's source (I don't really know any
> >>PHP) seems to indicate that the client makes some unwarranted
> >>assumptions. I _think_ it only recognises the "END\r\n" line which
> >>finishes any batch of data a server sends when this line comes in the
> >>same buffer (as a result of the same read call) with some previous data
> >>for some key. As a result, when the server fails to match any keys, and
> >>only sends "END\r\n" (correctly, according to the protocol), the client
> >>thinks it's an error. This by itself may be harmless, but I think that
> >>more serious errors could occur if the "END\r\n" doesn't come in the
> >>same IP packet as the rest of server's reply (say if the reply is too
> >>large to fit in one packet) and subsequently arrives via a separate
> >>read request. This logic should be fixed (there shouldn't be any
> >>assumptions about how data is separated across read/write calls).
> >>
> >>
> >>>D'oh! Looks like relative expiration times are a new feature of
> >>>1.1.7/1.1.8, and 1.1.6 expects either 0 or a full Unix timestamp.
> >>
> >>That's correct (don't use 1.1.7, it has an embarrassing bug related to
> >>this very feature).
> >>
> >>--avva
> >>
> >>
> >
> >
> >
>
> --
> Ryan Gilfether
> Software Engineer
> http://www.gilfether.com
>