libhttp

[Alan DuBoff]

harpo@udlug.org wrote:
> 
> > Alan> Hi folks, I was recentely hacking together a shared library that
> > Alan> could be used in c/c++ applications to do http transfers,
> > Alan> similar to how wget works (for those that have used it).
> >
> > It's a bit hard to believe that something very similar doesn't already
> > exist.
> 
> It does,  actually:
> 
> Package: libcurl2-ssl
> Description: Multi-protocol file transfer library. (SSL support)
>  This package includes shared version of the libcurl library.
>  .
>  libcurl is designed and meant to become a solid, usable and reliable
>  multi-protocol file transfer library for URL syntax defined files.
>  .
>  Shared library *with* SSL support.

Will,

I didn't mean to imply that this problem has not been solved, it has. libcurl
is one such example of a solution to the problem, albeit a bit *plump* for
some of our use. As I had mentioned, my main intention was to be able to have
a useful library, that was most importantly very simple to use, and originally
this solution came out of the need to use it on embedded Linux.

Let me explain a few things about this, because libcurl is a much more
complete and robust library than libhttp, and even libghttp for that matter.
Both of them put my humble libhttp to shame in the sense of robustness.

The biggest (or should I say smallest?;-) reason should be very telling.

NOTE: this libcurl2 is the non-ssl, there doesn't seem to be source for the
ssl version, not sure why...so the ssl version might be even plumper!<g>

 1156704 Sep 21 19:03 libcurl.a                         
     703 Sep 21 19:03 libcurl.la                        
      16 Sep 21 19:03 libcurl.so -> libcurl.so.2.0.1    
      16 Sep 21 19:03 libcurl.so.2 -> libcurl.so.2.0.1  
  322521 Sep 21 19:03 libcurl.so.2.0.1                  

  209950 Sep 21 19:36 libghttp.a                        
     648 Sep 21 19:36 libghttp.la                       
      17 Sep 21 19:36 libghttp.so -> libghttp.so.1.0.0  
      17 Sep 21 19:36 libghttp.so.1 -> libghttp.so.1.0.0
  110479 Sep 21 19:36 libghttp.so.1.0.0                 

   40444 Sep 11 20:56 libhttp.a                         
     699 Sep 11 20:56 libhttp.la                        
      16 Sep 11 20:56 libhttp.so -> libhttp.so.0.0.1    
      16 Sep 11 20:56 libhttp.so.0 -> libhttp.so.0.0.1  
   45584 Sep 11 20:56 libhttp.so.0.0.1                  

This problem compounds on most embedded devices, since what you see here are
numbers from an Intel platform, and on *most* RISC processors I believe you'll
see those numbers go up substantially. On a PowerPC 823 chip I was developing
for, libghttp was more than twice the size. Other RISC processors may be
better with size, but it seems that is one drawback of the RISC architecture
in that it produces larger binaries.

libcurl has lots of baggage which does give it a lot of robustness, but it
also adds a little extra "plumpness" to it. 1 megabyte is quite a bit of space
for an embedded processor, where often you may only have 8mb of space on flash
or other type of storage. 16mb is getting more common these days, but I would
guess there are a lot of 8mb devices around still.

Another reason for creating libhttp was that admittedly, being an Einstein
admirer, I've always favored simple solutions...and I could be wrong, but
libhttp is a much simpler solutin, there is only one function at this
time!!!<G>

With that said, I didn't want one of these libraries that required you
initialize and maintain a state machine of such, and libcurl does just that.
Not that it's good or bad, but for my specific needs I didn't really want
that.

It was actually looking at libraries such as libcurl and libghttp that made me
want to create something smaller. The reality is that there is very little
overhead in opening a socket to a server to transfer data. libcurl is a very
complete library, and even includes ftp, gopher, and https (something I want
to implement;-) in addition to http, and libhttp only handles http schemas.

Lastly, in many cases on embedded devices, compiling static will produce
smaller code, and I have resorted to that in the past...but if you did have a
need for many different applications to use the same library, it certainly
would help to have a shared library, and ultimately save space as well. I felt
that by implementing the automake/autoconf/libtool setup, it would handle both
static or shared, and it would allow for cross compiling to any specific
target supported by the gnu cross compiler.

As an example, try and configure libcurl for a different host/target and it
will barf on you. This is not to say that it can't be cross compiled, just
that it is not setup for it in it's current state.

Now, I've opened my big mouth and left it there for my big fat foot...I keep
telling myself that one day I'm gonna learn how to do this programming 'thang,
no matter how long it takes...who knows, one day I might get good enough to be
a Debian developer...(admittedly, I have quite a ways to go before that could
probably happen).

-- 

Alan DuBoff
Software Orchestration, Inc.