The only reason I implemented http layer was because when I looked around (few months ago) there was nothing to use. I knew that I must use libevent (portability) so I looked for http+libevent. Nothing. Well, there was one abandoned project but it was written by some college kid as an excercise - no use to my enterprise requirements.
So I implemented what had to be implmented (and I am not happy about this situation, because I would rather use someone else effort and focus on the guts of my server. Implementing an http layer was and remains a distraction to me). If there would be some decent (libevent based) library that deals with all those http quirks - I would gladly rewrite my code to use that library. On another hand, if there would be a substantial performance penalty associated with that library - then I would not use it. Performance was the reason I went with libevent, performence will be the reason for anybody who wants libevent+http. What happens above that layer is another story - my server is in C++. The http+libevent part is plain C, though. I don't want to marshall the http parameters as a Map into every request, that might cost too much. But maybe not ;-) The last but not the least. A few months ago there was not a single usable http+libevent combination out there. Now it seems there soon will be 3 competing combinations. Because the demand for that 'combination' is there and I claim that it will be there for a while. Such a situation looks silly and it would certainly hirt the overall situation with http+libevent combination, because it would confuse the users e t.c. Look at memcached + PHP situation. There are several different client implementations and not one is actually usable. Just to figure out what to download takes way too much time. Which is silly. Conclusion. I vote for an 'offcial' libevent+http layer and I volonteer to do whatever you guys would think makes sense for that layer to appear. As a matter of fact, because I have a full-blown performance/stress-testing framework set up and running, I can relativley easy replace my http layer with 'yours' (whatever that would be) and tell the performance difference, for example. The amount of time I can spend on bringing 'unified http+libevent' project to life is limited, but I just want to say that : I think that any unification of effort resulting in some 'official' library will be good for people, so if there is a political will to do that - count me in ;-) Have fun. Rgds.Paul. --- christopher baus <[EMAIL PROTECTED]> wrote: > > > 2. If anybody wants to play with / improve my > "http > > on top of libevent implementation" - pelase email > me > > offlist - the code should go opensource by the > middle > > of September. > > > > Rgds.Paul. > > > > I'll race you :) I also have a C++ HTTP > implementation that I have worked > on for a couple years. I really need to open source > it, but I've gotten > busy in the last 6 months. Niels announcement makes > me want to kick my > work back into high gear. I have keep-alive, > pipelines, per event > tokenizing, and client and server support. > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
