Mladen, Alex, et al Interesting enough just a few weeks ago I also encountered a similar need of a lightweight server micro-kernel. After having looked around I found nothing which I thought was close enough to what the requirements were, so I ended up writing all that plumbing code myself from scratch, making quite a few unpleasant discoveries on the way* (see below).
Secondly, a light-weight server might potentially be very interesting for Commons HttpClient project. The more HttpClient matures, the more we find ourselves developing code that can be used on the server-side as well. Basically all that it takes to turn HttpClient into a embedded lightweight HTTP server is a lightweight server micro-kernel Clearly there's a need for a project like that. I personally would be interested to contribute if my work at HttpClient leaves me a few spare moments. Oleg PS: if you are not into sad stories, ignore stuff below * Initially I based my server code on NIO because one thread per connection (most of which would stay idle most of the time) was kind of luxury I could not afford. I after having spent a few days writing code I came to the point where I needed to plug in SSL. To my dismay I found out that SSL was not NIO enabled in Java 1.4 (SSLSocketChannel planned for 1.5). If you intend to target Java 1.4 and be able to use SSL, NIO appears out of question. On Mon, 2004-04-12 at 16:18, Alex Karasulu wrote: > > -----Original Message----- > > From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 12, 2004 8:45 AM > > To: Jakarta Commons Developers List > > Cc: [EMAIL PROTECTED] > > Subject: Re: Commons server infrastructure proposal > > > > > > Sounds like there may be some overlap with Commons Net. I know there > > is a point at which we'd like to move towards implementation with nio > > in [net]. More information may help. > > > > >>>>> On Mon, 12 Apr 2004 13:14:59 +0200, Mladen Turk <[EMAIL PROTECTED]> > > said: > > > > > Hi all, I have a project to propose that the 'commons philosophy' > > > can benefit thought. I'm aware of incubation process, but since I'm > > > an active ASF member for years now, I would like to hear your > > > opinions before. > > > > What I would like to know is are there any need and will to support > > > such a project. > > Yes absolutely. I too started to look for such a project but could > not really find one. I found a few components that could be used over > at Avalon but they seemed a bit to abstract so I had to implement my > own. BTW I'm currently involved with the directory > project in the incubator where the flagship server is an LDAP server > named Eve. This is what I wanted such a framework for. > > Plus using selectable IO is critical since LDAP is a stateless protocol > and the use of a thread per connection was out of the question. I > think we could leverage some of the code in Eve however I would rather > start from scratch again and retro fit this framework back into Eve > later. The primary reason being: starting from scratch as a group > is easier. There are however good examples that still can be used > but that can be done in an as needed bases if appropriate. > > > > Briefly the project I meant to do can be seen as a generic server > > > side component. It will based on NIO, and it will have plain > > > socket, SSL, and a generic channel support(Pipes and ByteBuffers), > > > so that communication doesn't necessary has to came from the wire, > > > but rather from any data source. > > Then we just want it to depend on SelectableChannels to enable > IO from any medium as you suggest: socket, pipe, or buffer. > > > > What's the purpose of it? Making a generic infrastructure for a > > > wide variety of server-like applications like http/ftp/mail servers, > > > reverse proxies, load balancers, clusters, game servers, etc. > > > > > Why? During past few years I found myself writing over and over > > > again some things that if properly designed could spare me lots of > > > time. > > Me too. Plus you never know when you have gone off the track. It > takes some peer review to keep things clean and reusable. > > > > Realy why? Something like that doesn't exists (at least I'm not > > > aware of such a thing having BSD-like licence), and although I have > > > a large codebase finished, I'm not the smartest guy around :) > > I'm not a smart guy either. That's why I know that my implementation > must be hoky to say the least in some places. I'd rather brainstorm > in a group to gain from the experiences of the collective. > > BTW I already have a ton of questions on the matter so I can't wait to > get started. Count me in if and when it happens. > > Alex > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
