Hi Bill,
The use-case for such a framework would be anything requiring a very large
amount of sockets.
The library its self is not specifically only for use to make a http daemon,
that's just a 'demo' of things you could make with it, the use for it is
much more general.
In my case I used it to make a IRC chat application (see:
http://www.chabotc.nl/chat.png if your curious), where a daemon accepts
comet connections on one end (see http://alex.dojotoolkit.org/?p=545 for a
nice writeup on Whats comet), it powers things like google talk in gmail,
renkoo, Meeboo, Jot Live, etc (and also Oracle forinstance uses it to
provide realtime stock or inventory events in their web apps).
So I needed a library to deal with 1000's of 'always open' http (server)
requests, and simultaneously an equal amount of irc (client) connections, no
framework I found was flexible enough to deal with such an large amount of
IO, or to deal with this mixing of client and server sockets, in one library
(which you do need if your going to socket_select the whole lot of them).
So that was my use-case, however many more can exist .. Jabber client
connections, stock trading updates over a comet connections, web2.0 real
time collaboration, writing an ftp server, or any kind of server really,
where you want to be able to scale very well on relatively limited hardware.
Basically anything where you want to implement a 'protocol handler' aka a
tcp service, and as a added benefit your not restricted to server
connections only, it will manage your client connections too.
I have to admit this library is not the first thing that comes to mind when
you speak of the average web developers, so I'm not sure if it fits the
80/20 rule. However when you want to make that little bit extra (such as
real time chat, real time cooperation and interaction inside RIA's, etc)
Regards,
-- Chris Chabot
-Original Message-
From: Bill Karwin [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 16, 2006 20:25
To: Chris Chabot; Zend Framework General
Subject: Re: [fw-general] Posible inclusion in ZendFramework?
Hi Chris,
Your project sounds very interesting. Currently we do have an
implementation of an Http Server in the incubator (under the 'tools'
directory) that has been contributed by a user. This tool is intended
to be lightweight, for purposes of testing and development of Zend
Framework applications.
We would welcome hearing more detailed explanation of the use cases of
your socket daemon with respect to possible usage in Zend Framework. So
far, Zend Framework has not focused on technology like yours, but
instead the Framework focuses on class libraries for web application
developers.
If you want to contribute to the Zend Framework project, the best thing
to do is to submit a Contributor License Agreement (CLA) and then write
a proposal. See http://framework.zend.com/wiki/display/ZFPROP/Home for
examples of proposals, and information about creating a proposal for the
Zend Framework.
Thanks for the contribution offer! Let me know if you have further
questions.
Regards,
Bill Karwin
Chris Chabot wrote:
Hi All,
I've just released a 'socket daemon' framework, which I've created as
a part of an open-source project I'm working on.
With it you can handle hundreds to thousands of client and server
connections, asynchronously, with build in buffering, state handling,
etc. Implementing a new TCP client or server service (or a mix
thereof) with this library is very easy, and allows maximum
flexibility in your implementations.
I was wondering if maybe the ZendFramework would be interested in
having such a library in the incubator, or if its to far out of spec
for the goals of the project.
If interest does exist, I'd be happy to change the code to Zend's
specifications (some differences exist in function naming style) and
write up a full documentation for it, and submit it for inclusion.
Download links and a bit of information can be found on:
http://www.chabotc.nl/phpsocketdaemon/
The tarbal includes a httpServer demo implementation to give more of
an idea how to use it and what its capable off.
Thanks Regards,
-- Chris Chabot
