From sebyte at smolny.plus.com  Fri Sep  2 21:43:07 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Fri, 02 Sep 2011 21:43:07 +0000
Subject: [hunchentoot-devel] Hunchentoot development is moving to github
References: <CABj0bw+9yy-o=4edL7xSGQ=8Lr_juiSuAOqOec73eE1KggWCNw@mail.gmail.com>
Message-ID: <62laei38.fsf@chimera.gnukahvesi.net>

Hi Hans,

First of all, thanks for taking this on.

Quoth Hans H?bner <hans.huebner at gmail.com>:
> The "edicl" organization on github also has repository for several
> other libraries that Edi has written.

May I suggest that flexi-streams be added to the edicl organisation as it's a
hunchentoot dependency (and an ediware library).

Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Sat Sep  3 05:28:40 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 3 Sep 2011 07:28:40 +0200
Subject: [hunchentoot-devel] Hunchentoot development is moving to github
In-Reply-To: <62laei38.fsf@chimera.gnukahvesi.net>
References: <CABj0bw+9yy-o=4edL7xSGQ=8Lr_juiSuAOqOec73eE1KggWCNw@mail.gmail.com>
	<62laei38.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bwJMuCeB+uJx_gZzqSwk2i5NyVmWiscdjC4X5+ngmbk_nA@mail.gmail.com>

On Fri, Sep 2, 2011 at 11:43 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:

> May I suggest that flexi-streams be added to the edicl organisation as it's a
> hunchentoot dependency (and an ediware library).

Thanks for pointing this out.  flexi-streams has been added to edicl on github.

Cheers,
Hans



From sebyte at smolny.plus.com  Sun Sep  4 14:58:36 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sun, 04 Sep 2011 14:58:36 +0000
Subject: [hunchentoot-devel] edicl & Quicklisp - formal release tarballs or
	production-ready master branches?
Message-ID: <bov0cq1v.fsf@chimera.gnukahvesi.net>

Hi Hans,

I recently wrote the following post on the Quicklisp mailing list:

 http://permalink.gmane.org/gmane.lisp.quicklisp/69

and you can read Zach's reply here:

 http://permalink.gmane.org/gmane.lisp.quicklisp/70

Here's the final paragraph of Zach's reply, for the sake of convenience:

 "If the updated Ediware projects have important improvements, I would love to
  see new versioned releases published in some formal way. If that's not going
  to happen, I can look into pulling the projects from git [...]"

I suspect formal release tarballs for each and every project in edicl would be
quite a lot of work for you (as it probably was for Edi) so how about
maintaining production-ready master branches (as in git-flow[1]) to make things
as easy as possible for Zach?

Seb

[1] http://nvie.com/posts/a-successful-git-branching-model/

-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Fri Sep  9 14:26:17 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 9 Sep 2011 16:26:17 +0200
Subject: [hunchentoot-devel] edicl & Quicklisp - formal release tarballs
 or production-ready master branches?
In-Reply-To: <bov0cq1v.fsf@chimera.gnukahvesi.net>
References: <bov0cq1v.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bwLf67Aa=pk+k9h7K1c+JZ-mf7sJpGDCFiZLOEYDT3iMQQ@mail.gmail.com>

Hi Sebastian,

Sorry for the delay. I will switch to git-flow in the future, but that will
take a little while. I would like to make a release in the not so far future
as git repository has a number of improvements an bug fixes, but I still
have not found the time to make a basic file system to go with the release.
Any volunteers?

Hans
Am 04.09.2011 17:01 schrieb "Sebastian Tennant" <sebyte at smolny.plus.com>:
> Hi Hans,
>
> I recently wrote the following post on the Quicklisp mailing list:
>
> http://permalink.gmane.org/gmane.lisp.quicklisp/69
>
> and you can read Zach's reply here:
>
> http://permalink.gmane.org/gmane.lisp.quicklisp/70
>
> Here's the final paragraph of Zach's reply, for the sake of convenience:
>
> "If the updated Ediware projects have important improvements, I would love
to
> see new versioned releases published in some formal way. If that's not
going
> to happen, I can look into pulling the projects from git [...]"
>
> I suspect formal release tarballs for each and every project in edicl
would be
> quite a lot of work for you (as it probably was for Edi) so how about
> maintaining production-ready master branches (as in git-flow[1]) to make
things
> as easy as possible for Zach?
>
> Seb
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110909/3e6e05d8/attachment.html>

From sebyte at smolny.plus.com  Fri Sep  9 17:49:27 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Fri, 09 Sep 2011 17:49:27 +0000
Subject: [hunchentoot-devel] edicl & Quicklisp - formal release tarballs
	or production-ready master branches?
References: <bov0cq1v.fsf@chimera.gnukahvesi.net>
	<CABj0bwLf67Aa=pk+k9h7K1c+JZ-mf7sJpGDCFiZLOEYDT3iMQQ@mail.gmail.com>
Message-ID: <zkidzjvc.fsf@chimera.gnukahvesi.net>

Quoth Hans H?bner <hans.huebner at gmail.com>:
> Sorry for the delay. 

No problem.

> I will switch to git-flow in the future, 

Oh good.  I haven't actually used it myself yet but it made a lot of sense to
me when I first read about it, so I thought I'd suggest it here.

> but that will take a little while.

No problem.

> I would like to make a [hunchentoot] release in the not so far future as
> [the] git repository has a number of improvements and bug fixes, but I still
> have not found the time to make a basic file system to go with the
> release. Any volunteers?

I'd be happy to help, if I can.

Could you provide a little more detail about what you'd like the volunteer to
actually do and if I think it's something I have the time and skills for, I'll
I'll contact you off-list.

Incidentally, the library I'd actually like to see updated soonest is cl-who as
the version in Quicklisp doesn't include support for HTML5.

Perhaps I could assist with 'releasing' an updated version of cl-who as a
warm-up to assisting you with a hunchentoot release?

Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From edi at weitz.de  Fri Sep  9 18:02:59 2011
From: edi at weitz.de (Edi Weitz)
Date: Fri, 9 Sep 2011 20:02:59 +0200
Subject: [hunchentoot-devel] edicl & Quicklisp - formal release tarballs
 or production-ready master branches?
In-Reply-To: <zkidzjvc.fsf@chimera.gnukahvesi.net>
References: <bov0cq1v.fsf@chimera.gnukahvesi.net>
	<CABj0bwLf67Aa=pk+k9h7K1c+JZ-mf7sJpGDCFiZLOEYDT3iMQQ@mail.gmail.com>
	<zkidzjvc.fsf@chimera.gnukahvesi.net>
Message-ID: <CAD3YvRUQ1uoKGLw7hALoiqJZNJSfFSWo=aHP-79pN0J-3xhMjw@mail.gmail.com>

On Fri, Sep 9, 2011 at 7:49 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:

> Incidentally, the library I'd actually like to see updated soonest is cl-who as
> the version in Quicklisp doesn't include support for HTML5.
>
> Perhaps I could assist with 'releasing' an updated version of cl-who as a
> warm-up to assisting you with a hunchentoot release?

It's been a while (maybe two years ago), so I'm not totally sure, but
I /think/ the unreleased version of CL-WHO contains architectural
changes of mine which so far haven't been sufficiently documented
and/or tested.  You might want to take a look at this before you make
a release.

Just a recommendation.  Of course, you can proceed as you like... :)

Cheers,
Edi.

PS: cl-who-devel on Cc.



From ch-tbnl at bobobeach.com  Wed Sep 21 21:22:02 2011
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Wed, 21 Sep 2011 14:22:02 -0700
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
In-Reply-To: <BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
Message-ID: <BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>

Hi Hans and the rest of the hunchentoot folks,

Sorry for the silence on this, but I'm curious to see if anything has happened in the last few months that changes things. The main problem I had with the hunchentoot changes from late last year/early this year where that my hunchentoot-vhost no long worked, and it wasn't clear how to cleanly make things work. I thought the socket-connector and dispatcher patches solved the problem in an appropriate manner.

I've been away from this for quite some time, but I, once again, find myself needing to run multiple, in apache parlance, virtual hosts, on a single pair or 80 and 443 ports. I'm happy to abandon my hunchentoot-vhost approach if there's a better option, but I'd hate to have to recode that stuff for no good reason. Any suggestions?

thanks,

Cyrus
 
On Apr 20, 2011, at 1:01 AM, Hans H?bner wrote:

> On Mon, Apr 18, 2011 at 4:56 PM, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
>> I think the idea is that someone could both extend ACCEPTOR (and TASKMASTER) (a fancy epoll-using ACCEPTOR perhaps?) and still have said ACCEPTOR-subclass useable with SSL without subclassing. I like the idea of composing in the SSL-based socket functionality at runtime without subclassing -- at least I liked it enough to try out the approach. I'm not certain this is the best approach, but it looked reasonable enough to try it out and it seems to work. If the consensus is that this isn't a good approach, I can live with that.
> 
> At this point, I'd prefer not to add new classes unless they really
> fulfill a need.  I have been pondering whether/if Hunchentoot can be
> converted to an event oriented web server somehow, but that would
> require much more than separating out the connector functionality.
> The real issue, I think, is that the underlying streams are not event
> oriented.  The flow of control would need to be basically reverted,
> and that is something that I'm not up to doing.  Maybe using
> Hunchentoot as a start is a bad idea anyway.  Anyway, I'd like to keep
> things as simple as possible.
> 
>> I think a SERVER class that holds one or more acceptors would be a fine thing. I seem to end up coding something like that by hand when I need it (the ability to do so should remain, of course) but it would be nice to have a standard way to wrap those servers as I think that's a pretty common use case.
> 
> The task of a SERVER class would be to read a configuration
> specification and instantiate the required objects that make up the
> server.  In the simple case, this would be one ACCEPTOR, one
> TASKMASTER and one REQUEST-HANDLER.  In more complex cases, more
> ACCEPTOR instances would be present (to listen on multiple ports) or
> more REQUEST-HANDLERS would exist to, say, serve multiple virtual
> hosts.
> 
> I will need a few more weeks until I can really put effort into
> reviewing the patches and implement the new mechanisms.  I also hope
> that the SSL problems are sorted out until then, as the upcoming
> release should certainly support SSL.
> 
> -Hans
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From sebyte at smolny.plus.com  Thu Sep 22 06:48:09 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 22 Sep 2011 06:48:09 +0000
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
	<BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>
Message-ID: <8vph8446.fsf@chimera.gnukahvesi.net>

Hi Cyrus,

Quoth Cyrus Harmon <ch-tbnl at bobobeach.com>:
> I'm happy to abandon my hunchentoot-vhost approach if there's a better
> option, but I'd hate to have to recode that stuff for no good reason. Any
> suggestions?

At one point I considered hunchentoot-vhost but decided against it.  It seemed
quite complex (at least to me).

Instead, I run hunchentoot behind lighttpd.  hunchentoot has acceptors
listening on various localhost ports and lighttpd is configured to send page
requests to one of those localhost ports depending on which host is identified
in the URL.

And that's it! "One host per port".  It works like a dream.

lighttpd's conf file needs a section that reads like this:

--8<---------------cut here---------------start------------->8---
 # proxy handling
 server.modules                += ( "mod_proxy" )

 $SERVER["socket"] == "123.456.78.90:80" {
     proxy.balance = "fair"
     $HTTP["host"] =~ "^example.com" {
         proxy.server   = ("" => (("host" => "127.0.0.1", "port" => 49154))) }
     $HTTP["host"] =~ "^foobar.org" {
         proxy.server   = ("" => (("host" => "127.0.0.1", "port" => 49155))) }
 }
--8<---------------cut here---------------end--------------->8---

I'm sure it's just as easy using Apache, but I'm afraid I've never used it so I
can't say precisely how it's done.

Hope this helps,

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Thu Sep 22 08:22:10 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 22 Sep 2011 10:22:10 +0200
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
In-Reply-To: <8vph8446.fsf@chimera.gnukahvesi.net>
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
	<BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>
	<8vph8446.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bw+phVaMFkBFLJC0BS9KMG9a-r8muB8Bh_EeECNqzkDObQ@mail.gmail.com>

On Thu, Sep 22, 2011 at 8:48 AM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:
> At one point I considered hunchentoot-vhost but decided against it. ?It seemed
> quite complex (at least to me).

I am using squid as a frontend to pretty much the same effect (I use
it for SSL processing, too).

Sadly, I have not made progress regarding the changing the
architecture of Hunchentoot in ways that would decouple request
handling from from accepting.  What would really be needed is a
request routing concept that is orthogonal to request handling.
Virtual host handling would then become part of the request routing.

Even though easy handlers are currently defined as acceptor subclass,
I do not think that this is the best way to implement a framework on
top of Hunchentoot.  I refactored easy handlers that way because it
was the quickest way to make them optional, as I wanted to get the
easy handler code out of the common code path used for all handlers.

I don't have current plans to make larger architectural changes
myself, though.  If you, the Hunchentoot user base, have needs that
require architectural microchanges within the current class layout,
I'll gladly review pull requests on github and also make them part of
the main repository.  I am also open to larger efforts if anyone has
the time to do that.  This can happen on a github fork first and moved
to the edicl repository once there is sufficient interest and
movement.

For the long-promised, still-undated upcoming release of Hunchentoot,
my focus is to stabilize the feature set that exists right now.

-Hans



From sebyte at smolny.plus.com  Thu Sep 22 20:03:48 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 22 Sep 2011 20:03:48 +0000
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
	<BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>
	<8vph8446.fsf@chimera.gnukahvesi.net>
	<CABj0bw+phVaMFkBFLJC0BS9KMG9a-r8muB8Bh_EeECNqzkDObQ@mail.gmail.com>
Message-ID: <ehz873a3.fsf@chimera.gnukahvesi.net>

Quoth Hans H?bner <hans.huebner at gmail.com>:
> On Thu, Sep 22, 2011 at 8:48 AM, Sebastian Tennant
> <sebyte at smolny.plus.com> wrote:

>> At one point I considered hunchentoot-vhost but decided against it. ?It
>> seemed quite complex (at least to me).

> I am using squid as a frontend to pretty much the same effect (I use
> it for SSL processing, too).

Cool.  I've never tried squid but I'll definitely have a look at it now, if I
ever find time!

> Sadly, I have not made progress regarding the changing the architecture of
> Hunchentoot in ways that would decouple request handling from accepting.
> What would really be needed is a request routing concept that is orthogonal
> to request handling.  Virtual host handling would then become part of the
> request routing.

IMHO, the fact that there's only a single *dispatch-table* is 'the big thing'
that needs changing.

Adding a dispatch-table slot (with default value *dispatch-table*) to the
acceptor class would probably suffice, though it's probably not that simple.

My workaround uses the acceptor :name slot to store the name of the dispatch
table for that acceptor) and I then define a modified request dispatcher
function that binds *dispatch-table* accordingly:

 ;;; per-acceptor dispatch tables
 (defun choosing-list-request-dispatcher (request)
   (let ((*dispatch-table* (eval (acceptor-name *acceptor*))))
     (loop for dispatcher in *dispatch-table*
           for action = (funcall dispatcher request)
           when action return (funcall action)
             finally (setf (return-code *reply*) +http-not-found+))))

  ;;; initalise dispatch tables
  (defvar *exmaple-dot-com-dispatch-table* '(default-dispatcher))
  (defvar *foobar-dot-org-dispatch-table* '(default-dispatcher))
  
  ;;; acceptors             
  (defvar example-dot-com
     (make-instance
      'acceptor
      :name '*exmaple-dot-com-dispatch-table*
      :address "127.0.0.1" :port 49154
      :request-dispatcher 'choosing-list-request-dispatcher))

  (defvar foobar-dot-org
     (make-instance
      'acceptor
      :name '*foobar-dot-org-dispatch-table*
      :address "127.0.0.1" :port 49155
      :request-dispatcher 'choosing-list-request-dispatcher))

> Even though easy handlers are currently defined as acceptor subclass, I do
> not think that this is the best way to implement a framework on top of
> Hunchentoot.  I refactored easy handlers that way because it was the quickest
> way to make them optional, as I wanted to get the easy handler code out of
> the common code path used for all handlers.

I found easy handlers too difficult to use :) so I've never used them and
therefore can't really comment, although getting their code out of the common
code path sounds like a sensible thing to be doing.

> If you [...] require architectural microchanges within the current class
> layout, I'll gladly review pull requests

Noted.

> on github and also make them part of the main repository.

Sorry... isn't 'hunchentoot on github' and 'the main repository' one and the
same thing?

> I am also open to larger efforts if anyone has the time to do that.  This can
> happen on a github fork first and moved to the edicl repository once there is
> sufficient interest and movement.

Noted.

> For the long-promised, still-undated upcoming release of Hunchentoot, my
> focus is to stabilize the feature set that exists right now.

Might it not be a good idea to make an announcement with subject line
'Hunchentoot frozen pending imminent release - bugfixes welcome' or words to
that effect?

Seb
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Fri Sep 23 07:22:42 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 23 Sep 2011 09:22:42 +0200
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
In-Reply-To: <ehz873a3.fsf@chimera.gnukahvesi.net>
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
	<BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>
	<8vph8446.fsf@chimera.gnukahvesi.net>
	<CABj0bw+phVaMFkBFLJC0BS9KMG9a-r8muB8Bh_EeECNqzkDObQ@mail.gmail.com>
	<ehz873a3.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bwJmU9BdL1rq8JBfBKrHviJjfedv92TRtMDVw+OHRymONg@mail.gmail.com>

On Thu, Sep 22, 2011 at 10:03 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:
> Quoth Hans H?bner <hans.huebner at gmail.com>:

> IMHO, the fact that there's only a single *dispatch-table* is 'the big thing'
> that needs changing.

> Adding a dispatch-table slot (with default value *dispatch-table*) to the
> acceptor class would probably suffice, though it's probably not that simple.

I can agree to that, but subclassing acceptors is not really modular
(i.e. it is as right or wrong as the easy-acceptor subclass).  I think
it would make sense to have a dispatcher class.  Every acceptor would
have an dispatchers slot that contained a list of dispatcher instances
which would be consulted, one after another, to route the request.

That way, it would be possible to share dispatcher instances between
acceptors.  For example, a web site could have a dispatcher for the
anonymous, sessionless front-end functionality that would be used by
the http port.  The same dispatcher instance would be on the
dispatchers list of the https acceptor, and in addition there would be
a dispatcher instance for the, say, content management system on that
acceptors dispatchers list.  Also, the dispatcher class would be
responsible for implementing virtual hosts, i.e. there would be one
dispatcher for every virtual host supported.

Now this sounds nice and easy, but it adds to the number of instances
that need to be created in order to start Hunchentoot.  Starting
Hunchentoot in any but the most basic standard configurations is
already a chore, requiring various make-instance invocations and
initargs.  If we move forward in this direction, I think we need to
improve how Hunchentoot is configured and started, too.  Basically,
this would be a declarative syntax that contained the various classes
and instiation arguments.

>> on github and also make them part of the main repository.
>
> Sorry... isn't 'hunchentoot on github' and 'the main repository' one and the
> same thing?

"on github" means "in any fork", "the main repository" means edicl/hunchentoot.

> Might it not be a good idea to make an announcement with subject line
> 'Hunchentoot frozen pending imminent release - bugfixes welcome' or words to
> that effect?

Yes.  As soon as the freeze point is reached, that will happen.
Before that, here is what I'd like to do:

- Conceptionalize dispatching (in the way described above or a
different modular way)
- Implement declarative configuration
- Integrate Hunchensocket
- Set up default file system with documentation and nice-looking error pages

Anything else?  Let me know.  In order for this to actually happen,
discussion and collaboration is needed.

-Hans



From sebyte at smolny.plus.com  Thu Sep 29 13:07:31 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Thu, 29 Sep 2011 13:07:31 +0000
Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector?
References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com>
	<BANLkTikVnO6HX9agkmz0N_JtMjibnokaCQ@mail.gmail.com>
	<436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com>
	<BANLkTimga1e5BfQN8mCgiWTUS4A=09LMEA@mail.gmail.com>
	<BC30AA0A-5275-448C-8442-20E8FCDF138F@bobobeach.com>
	<8vph8446.fsf@chimera.gnukahvesi.net>
	<CABj0bw+phVaMFkBFLJC0BS9KMG9a-r8muB8Bh_EeECNqzkDObQ@mail.gmail.com>
	<ehz873a3.fsf@chimera.gnukahvesi.net>
	<CABj0bwJmU9BdL1rq8JBfBKrHviJjfedv92TRtMDVw+OHRymONg@mail.gmail.com>
Message-ID: <oby34hv0.fsf@chimera.gnukahvesi.net>

Quoth Hans H?bner <hans.huebner at gmail.com>:
> On Thu, Sep 22, 2011 at 10:03 PM, Sebastian Tennant
> <sebyte at smolny.plus.com> wrote:
>> Quoth Hans H?bner <hans.huebner at gmail.com>:
>
>> IMHO, the fact that there's only a single *dispatch-table* is 'the big thing'
>> that needs changing.
>
>> Adding a dispatch-table slot (with default value *dispatch-table*) to the
>> acceptor class would probably suffice, though it's probably not that simple.
>
> I can agree to that, but subclassing acceptors is not really modular
> (i.e. it is as right or wrong as the easy-acceptor subclass).  

I was talking about adding a dispatch-table slot to the existing acceptor
class.  I was not talking about subclassing.  My understanding of object
oriented programming paradigms is limited so I can't say I fully understand why
subclassing is 'not really modular', however simply adding a dispatch-table
slot to the acceptor class would circumvent that problem.

> I think it would make sense to have a dispatcher class.  Every acceptor would
> have a dispatchers slot that contained a list of dispatcher instances which
> would be consulted, one after another, to route the request.

I'm sure this could be made to work well but it undoubtedly adds another layer
of complexity.

I drew this visual model for myself when I was learning about hunchentoot:


                                   +--------------------------+
                      +-----------<|           Client         |<---------------+
                      |            +--------------------------+                |
                  HTTP request                                                HTML
                      |                                                        |
             +---------------------------------------------------+             |
             |        |          req. obj.                       |             |
   ACCEPTOR  | PROCESS-REQUEST -------------> request dispatcher | ===> request handler
             +---------------------------------------------------+
                          | ^                   | ^
                      req.| |               req.| |
                      obj.| NIL             obj.| request handler
                          | |                   | |
 *DISPATCH-TABLE* (dispatch function#1   dispatch function#2 ... dispatch function#N)


It would help me a lot if you could draw a similar model which incorporates
dispatch tables and dispatch functions, as well as your proposed dispatcher
object.

> That way, it would be possible to share dispatcher instances between
> acceptors.  For example, a web site could have a dispatcher for the
> anonymous, sessionless front-end functionality that would be used by the http
> port.  The same dispatcher instance would be on the dispatchers list of the
> https acceptor, and in addition there would be a dispatcher instance for the,
> say, content management system on that acceptors dispatchers list.  

Sharing dispatcher instances sounds good in theory but I'm not sure how useful
it would be in practice (based on my own experience).

> Also, the dispatcher class would be responsible for implementing virtual
> hosts, i.e. there would be one dispatcher for every virtual host supported.

Each virtual host already has its own acceptor so why does each virtual host
need its own dispatcher object as well?

> Now this sounds nice and easy,

Does it? :)

> but it adds to the number of instances that need to be created in order to
> start Hunchentoot.  Starting Hunchentoot in any but the most basic standard
> configurations is already a chore, requiring various make-instance
> invocations and initargs.  If we move forward in this direction, I think we
> need to improve how Hunchentoot is configured and started, too.  Basically,
> this would be a declarative syntax that contained the various classes and
> instantiation arguments.

It seems to me the solution is becoming more complicated than the problem we
are trying to solve, namely improved support for virtual hosts.


My solution is simple, and backwards compatible:

 (defun list-request-dispatcher (request)
   (let ((dispatch-table
          (if (fboundp 'acceptor-dispatch-table))
              (eval (acceptor-dispatch-table *acceptor*))
            *dispatch-table*)))
     (loop for dispatcher in dispatch-table
           for action = (funcall dispatcher request)
           when action return (funcall action)
           finally (setf (return-code *reply*) +http-not-found+)))))

 where acceptor-dispatch-table is a reader method defined on an additional slot
 to the acceptor class; dispatch-table, with default value '*dispatch-table*.

> "on github" means "in any fork", "the main repository" means edicl/hunchentoot.

OK, I see.

> Yes.  As soon as the freeze point is reached, that will happen.  Before that,
> here is what I'd like to do:
>
> - Conceptionalize dispatching [...]
> - Implement declarative configuration

This seems to me like a lot of work and it also seems quite likely that you
will have to do most (if not all) of it.  And will these changes be backwards
compatible?  I suugest these be deferred to a subsequent release, one with a
more significant version number bump; 1.2.0 say?

> - Integrate Hunchensocket

I hadn't heard of hunchensocket until now, but I've no doubt it should be
integrated.  How easy or hard do you think this will be?

> - Set up default file system with documentation and nice-looking error pages

I'm not sure what you mean by a default file system.  Do you mean a dispatch
function which matches a unique path:

 /hunchendocs/manual.html

for example, which is added to *dispatch-table* by default?

As for 'nice-looking' error pages, don't forget that one person's nice is
another person's ugly.


Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From z_axis at 163.com  Fri Sep 30 00:06:19 2011
From: z_axis at 163.com (z_axis)
Date: Fri, 30 Sep 2011 08:06:19 +0800
Subject: [hunchentoot-devel] Can hunchentoot host CGH application ?
Message-ID: <op.v2lg8ul31uofcn@redirector.netnames.net>

We have a CGI application developed using python, which can be hosted in  
erlang YAWS easily:
> cat ~/yaws.conf
...
<server 192.168.1.2>
     port = 8000
     listen = 0.0.0.0
     docroot = /media/G/www/qachina/
     access_log = false
     appmods = <cgi-bin, yaws_appmod_cgi>
</server>
...

Now we want to host the application in a lisp web server.  Maybe  
hunchentoot can do it ?

Sincerely!




From hans.huebner at gmail.com  Fri Sep 30 07:12:09 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 30 Sep 2011 03:12:09 -0400
Subject: [hunchentoot-devel] Can hunchentoot host CGH application ?
In-Reply-To: <op.v2lg8ul31uofcn@redirector.netnames.net>
References: <op.v2lg8ul31uofcn@redirector.netnames.net>
Message-ID: <CABj0bwJijo+d7oqXVMWtWK-URCe-Qxap1_W6qo=nVSzwaSrDTg@mail.gmail.com>

On Thu, Sep 29, 2011 at 8:06 PM, z_axis <z_axis at 163.com> wrote:
> We have a CGI application developed using python, which can be hosted in
> erlang YAWS easily:
> [...]
> Now we want to host the application in a lisp web server. ?Maybe hunchentoot
> can do it ?

Hunchentoot does not come with native CGI support.  There is the
hunchentoot-cgi extension written by Cyrus Harmon, but I have no
experience with it.

-Hans