[Grub-develop] About the tcp4u library

[Igor S. <oz...@gr...>]

Doug wrote:

> Oh, good.  I'm glad that the "client" stuff in the server repository is
> going to be deleted.
[ozra] Actually, I am not deleting it.  I just accidentally imported it
under the server directory (wrong spot).  It still exists under the client
directory.

I am guessing, you had problems compiling the tcp4u library.  The reason we
are using it because it has several features:
  - It understands a subset of the HTTP protocol, the GET command in
partucular.
  - It understands HTTP error codes returned from the web server.
  - It is able to follow redirects given from the web server.
  - It works under both UNIX and Windows.
I thought it would be easier to just use something some wrote then
recreating it.  And I wasn't able to find anything more apporpriate.  If
anyone has anything better in mind, let me know.

It does have a lot of extraneous crap which we will never use, like UDP
sockets.  We might use whatever we can out of it, and then clean up the rest
of the code that we don't need in the future.

> It doesn't compile unless you do several things:
[ozra] As far as compiling problems, there should be none now except for one
warning, which is unimportant:

> *  you have to #define NEED_PROTO in both main.cpp and port.h (weird stuff
>    if you ask me...)
[ozra] It's fixed now.  Download the newest version of the code.

> *  you have to cast szURL to a char * in the strcat() call in Kosta's
change
>    to http4_url.c to get rid of a couple of compiler warnings
[ozra] It's fixed.

> *  you have to cast Rc in http4_ex.c to an unsigned int where it says in
the
>    comments that it will generate a signed/unsigned mismatch (this
probably
>    would be safe because the bizarre network abstraction library looks
>    like it already handles error conditions, so Rc would be positive
>    by the time it got here, or zero if nothing was received) to get rid of
>    the signed/unsigned mismatch
[ozra] This one is a problem.  Howerver, first, we will not likely use this
functionallity, that is, to write what we get from the HTTP response
straight to a local file.  Second, the functions used for writing to a local
file are from the old 16-bit Windows, which I don't feel confortable with.
This part needs a slight modification so that "write to a local file"
functionality is removed from there altogether.  I forgot about it now that
you mentioned it.

> *  and you have to link against wsock32.lib
[ozra] Yes.  But if you compile the code using Visual C++ and the .dsw
provided in the CVS, you don't need to be aware of that fact, as it is all
handled by the project files.

Right now the library tends to crash on Linux due to some bug.  But it's
being taken care of, too.


Cheers,

igor.