From hans.huebner at gmail.com  Mon Jan  5 12:38:27 2009
From: hans.huebner at gmail.com (Hans Huebner)
Date: Mon, 5 Jan 2009 13:38:27 +0100
Subject: [hunchentoot-devel] Limit on Request Content Size
In-Reply-To: <873ag4pinx.fsf_-_@alamut.mobiliz.com.tr>
References: <87iqp1n4so.fsf@alamut.mobiliz.com.tr>
	<fd2982320812300653u64abbe35g2abf1312deb08829@mail.gmail.com>
	<873ag4pinx.fsf_-_@alamut.mobiliz.com.tr>
Message-ID: <fd2982320901050438n23e42372m5d82f664d6b651f2@mail.gmail.com>

Happy New Year's, y'all!

On Wed, Dec 31, 2008 at 14:40, Volkan YAZICI <yazicivo at ttmail.com> wrote:
> Considering your comparison, implementing the limitation in stream
> structures could be great. In case of a limitation failure, hunchentoot
> can signal a (restartable) condition. But I don't have an idea about how
> I could make flexi-streams to force such a limitation while reading
> streams. Would you mind giving some hints, reading pointers, etc. that I
> can further study?

I did not investigate this much, but here are two hints:  The input
stream that Hunchentoot gets from usocket is eventually wrapped in a
flexi-stream.  Before doing so, the stream could be wrapped in an
instance of the length-limiting stream class that you have created.
The SBCL manual has some helpful documentation and examples on gray
streams, see (http://www.sbcl.org/manual/Gray-Streams.html).

Note that gray streams can be slow if you only supply methods for
character wise reading.  Things may still be fast enough, but you
should keep an eye on performance.

Let us know if you need further pointers.

-Hans



From hans.huebner at gmail.com  Thu Jan  8 13:56:36 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 8 Jan 2009 14:56:36 +0100
Subject: [hunchentoot-devel] Fwd: [Sbcl-devel] SBCL crashes in READ-SEQUENCE
	with Error: The value 1025 is not of type (MOD 1025)
In-Reply-To: <87ljtmoro6.fsf@vasara.proghammer.com>
References: <loom.20090108T124651-13@post.gmane.org>
	<87ljtmoro6.fsf@vasara.proghammer.com>
Message-ID: <fd2982320901080556u14f5cea0h68f486e335062efd@mail.gmail.com>

Recently, I saw one of my servers crash to ldb with the error message
"Error: The value 1025 is not of type (MOD 1025)".  This happens every
few months, and I have not been bothered too much by it (and I will be
bothered even less now that Zach Beane has posted how I can disable
ldb), but I wanted to know what the cause for this is, so inquired in
sbcl-devel.  See Juho's answer below.  It boils down to:  There is a
file descriptor leak.

-Hans

---------- Forwarded message ----------
From: Juho Snellman <jsnell at iki.fi>
Date: Thu, Jan 8, 2009 at 14:26
Subject: Re: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error:
The value 1025 is not of type (MOD 1025)
To: Hans H?bner <hans.huebner at gmail.com>
Cc: sbcl-devel at lists.sourceforge.net


Hans H?bner <hans.huebner at gmail.com> writes:
> Hi,
>
> sporadically, some of my Hunchentoot based web servers running on SBCL
> 1.0.20.22 (FreeBSD, threaded) crash to ldb, with the following messages
> appearing on the REPL:
>
> Error: The value 1025 is not of type (MOD 1025).

My first guess would be that you've got a fd that's too large (select
can only handle fds smaller than FD_SETSIZE).

Some people have explored replacing the use of select() for
serve-event with using various other fd polling interfaces to work
around this problem (there should be one patch floating around that
uses epoll() on Linux, don't know whether that'd be usable for you on
FreeBSD).

--
Juho Snellman



From avodonosov at yandex.ru  Thu Jan  8 14:42:26 2009
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Thu, 8 Jan 2009 16:42:26 +0200
Subject: [hunchentoot-devel] Fwd: [Sbcl-devel] SBCL crashes in
	READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025)
In-Reply-To: <fd2982320901080556u14f5cea0h68f486e335062efd@mail.gmail.com>
References: <loom.20090108T124651-13@post.gmane.org>
	<87ljtmoro6.fsf@vasara.proghammer.com>
	<fd2982320901080556u14f5cea0h68f486e335062efd@mail.gmail.com>
Message-ID: <17188154.20090108164226@yandex.ru>

Are you use SELECT?
(just curious)

on Thursday, January 8, 2009, 3:56:36 PM Hans wrote:

> Recently, I saw one of my servers crash to ldb with the error message
> "Error: The value 1025 is not of type (MOD 1025)".  This happens every
> few months, and I have not been bothered too much by it (and I will be
> bothered even less now that Zach Beane has posted how I can disable
> ldb), but I wanted to know what the cause for this is, so inquired in
> sbcl-devel.  See Juho's answer below.  It boils down to:  There is a
> file descriptor leak.

> -Hans

> ---------- Forwarded message ----------
> From: Juho Snellman <jsnell at iki.fi>
> Date: Thu, Jan 8, 2009 at 14:26
> Subject: Re: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error:
> The value 1025 is not of type (MOD 1025)
> To: Hans H?bner <hans.huebner at gmail.com>
> Cc: sbcl-devel at lists.sourceforge.net


> Hans H?bner <hans.huebner at gmail.com> writes:
>> Hi,
>>
>> sporadically, some of my Hunchentoot based web servers running on SBCL
>> 1.0.20.22 (FreeBSD, threaded) crash to ldb, with the following messages
>> appearing on the REPL:
>>
>> Error: The value 1025 is not of type (MOD 1025).

> My first guess would be that you've got a fd that's too large (select
> can only handle fds smaller than FD_SETSIZE).

> Some people have explored replacing the use of select() for
> serve-event with using various other fd polling interfaces to work
> around this problem (there should be one patch floating around that
> uses epoll() on Linux, don't know whether that'd be usable for you on
> FreeBSD).

> --
> Juho Snellman

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel






From hans.huebner at gmail.com  Thu Jan  8 15:05:36 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 8 Jan 2009 16:05:36 +0100
Subject: [hunchentoot-devel] Fwd: [Sbcl-devel] SBCL crashes in
	READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025)
In-Reply-To: <17188154.20090108164226@yandex.ru>
References: <loom.20090108T124651-13@post.gmane.org>
	<87ljtmoro6.fsf@vasara.proghammer.com>
	<fd2982320901080556u14f5cea0h68f486e335062efd@mail.gmail.com>
	<17188154.20090108164226@yandex.ru>
Message-ID: <fd2982320901080705j64785037gd31667d5a4ec4e5d@mail.gmail.com>

On Thu, Jan 8, 2009 at 15:42, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> Are you use SELECT?
> (just curious)

No, but it seems that SBCL does, internally, and does not try to guard
against file descriptors that are too large.

-Hans



From zaries at global.co.za  Mon Jan 19 18:41:19 2009
From: zaries at global.co.za (First name Last name)
Date: Mon, 19 Jan 2009 20:41:19 +0200
Subject: [hunchentoot-devel] Widget Guidlines
Message-ID: <MWS39ddef248793094357ac843c01812a8a86@mws39>

Hi

I have been using hunchentoot for the last two months and I
 have created a DB-Grid widget for myself. I pass relevant info in
 through parameters like table name and columns to display and the
 widget generates a html grid with paging, edit/delete and search
 functionality.

My lisp experience however is limited and my
 widget is feeling more and more clunky as the functionality grows. I
 would like to ask the experts how they would structure/design such a
 widget using hunchentoot (cl-who + postmodern).

I was thinking
 that such a widget might benefit others as well and others might have
 widgets that I might find useful. If we all use our own designs thow
 the resulting code might end up being to diverse to support. I would
 also not like to have to use a whole other framework on top of
 hunchentoot unless it came from the hunchentoot community and/or was
 supported by them. I would like the widgets to be as close as possible
 to hunchentoot to make them small, light and independant.

Would
 it be feasible to set up? a guideline/specification for hunchentoot
 widgets in general and widgets dealing with data-binding specifically?
 This way we could share widget among each other based on some standard
 that is documented and "trusted".

Regards





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090119/ab0fbe67/attachment.html>

From edi at agharta.de  Tue Jan 20 07:08:37 2009
From: edi at agharta.de (Edi Weitz)
Date: Tue, 20 Jan 2009 08:08:37 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <MWS39ddef248793094357ac843c01812a8a86@mws39>
References: <MWS39ddef248793094357ac843c01812a8a86@mws39>
Message-ID: <b56421a00901192308x17d3da5fwa511b53a46b19718@mail.gmail.com>

On Mon, Jan 19, 2009 at 7:41 PM, First name Last name
<zaries at global.co.za> wrote:

> I have been using hunchentoot for the last two months and I have created a
> DB-Grid widget for myself. I pass relevant info in through parameters like
> table name and columns to display and the widget generates a html grid with
> paging, edit/delete and search functionality.
>
> My lisp experience however is limited and my widget is feeling more and more
> clunky as the functionality grows. I would like to ask the experts how they
> would structure/design such a widget using hunchentoot (cl-who +
> postmodern).
>
> I was thinking that such a widget might benefit others as well and others
> might have widgets that I might find useful. If we all use our own designs
> thow the resulting code might end up being to diverse to support. I would
> also not like to have to use a whole other framework on top of hunchentoot
> unless it came from the hunchentoot community and/or was supported by them.
> I would like the widgets to be as close as possible to hunchentoot to make
> them small, light and independant.
>
> Would it be feasible to set up  a guideline/specification for hunchentoot
> widgets in general and widgets dealing with data-binding specifically? This
> way we could share widget among each other based on some standard that is
> documented and "trusted".

I think this generally sounds like a good idea although I imagine that
it'll be kind of hard to reach consensus even in the small group of
Hunchentoot users about the requirements for such widgets.

Cheers,
Edi.



From tomek.lipski at gmail.com  Tue Jan 20 08:26:21 2009
From: tomek.lipski at gmail.com (Tomasz Lipski)
Date: Tue, 20 Jan 2009 09:26:21 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <MWS39ddef248793094357ac843c01812a8a86@mws39>
References: <MWS39ddef248793094357ac843c01812a8a86@mws39>
Message-ID: <d33bafc50901200026q61a74cf5p345db370f7511285@mail.gmail.com>

2009/1/19 First name Last name <zaries at global.co.za>:
> Hi
>
> I have been using hunchentoot for the last two months and I have created a
> DB-Grid widget for myself. I pass relevant info in through parameters like
> table name and columns to display and the widget generates a html grid with
> paging, edit/delete and search functionality.

Hi,

I believe that attempt for such standardization could be weblocks
(based on hunchentoot)...

http://weblocks.viridian-project.de/

Best regards,

Tomek Lipski



From helmut at cybernetic-systems.de  Tue Jan 20 08:42:04 2009
From: helmut at cybernetic-systems.de (Helmut G. Enders)
Date: Tue, 20 Jan 2009 09:42:04 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <b56421a00901192308x17d3da5fwa511b53a46b19718@mail.gmail.com>
References: <MWS39ddef248793094357ac843c01812a8a86@mws39>
	<b56421a00901192308x17d3da5fwa511b53a46b19718@mail.gmail.com>
Message-ID: <49758E5C.1050007@cybernetic-systems.de>

Edi Weitz wrote:
> On Mon, Jan 19, 2009 at 7:41 PM, First name Last name
> <zaries at global.co.za> wrote:
> 
>> I have been using hunchentoot for the last two months and I have created a
>> DB-Grid widget for myself. I pass relevant info in through parameters like
>> table name and columns to display and the widget generates a html grid with
>> paging, edit/delete and search functionality.
>>
>> My lisp experience however is limited and my widget is feeling more and more
>> clunky as the functionality grows. I would like to ask the experts how they
>> would structure/design such a widget using hunchentoot (cl-who +
>> postmodern).
>>
>> I was thinking that such a widget might benefit others as well and others
>> might have widgets that I might find useful. If we all use our own designs
>> thow the resulting code might end up being to diverse to support. I would
>> also not like to have to use a whole other framework on top of hunchentoot
>> unless it came from the hunchentoot community and/or was supported by them.
>> I would like the widgets to be as close as possible to hunchentoot to make
>> them small, light and independant.
>>
>> Would it be feasible to set up  a guideline/specification for hunchentoot
>> widgets in general and widgets dealing with data-binding specifically? This
>> way we could share widget among each other based on some standard that is
>> documented and "trusted".
> 
> I think this generally sounds like a good idea although I imagine that
> it'll be kind of hard to reach consensus even in the small group of
> Hunchentoot users about the requirements for such widgets.
> 

Perhaps the widgets in the WEBLOCKS project would be a possible starting point.

Hemut



From zaries at global.co.za  Tue Jan 20 09:11:27 2009
From: zaries at global.co.za (First name Last name)
Date: Tue, 20 Jan 2009 11:11:27 +0200
Subject: [hunchentoot-devel] Widget Guidlines
Message-ID: <MWS3776720fdb0b6c40c99a783cc5a98c845e@mws37>




I don't think we need agreement from all, we need one or two of the main developers to agree on a specification. Compliance can be enforced by only adding "valid" widgets to a widgets repository. As more widgets are added arguments about the the how and why will fade as reusability wins in the end. 

Besides its open source, and opponents can come up with their own specification and own repository if they feel that strongly about it, nothing wrong with some choice. 

The specification does not need to be perfect if it covers 80% of what is needed then it will be good enough. The last 20% is almost always not worth bothering with any way.

I vote for some thing over nothing here.


?----- Original Message ------
?From:Edi Weitz
?Sent:Tuesday, January 20, 2009 09:08
?To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel at common-lisp.net; 
?Subject:Re: [hunchentoot-devel] Widget Guidlines



On Mon, Jan 19, 2009 at 7:41 PM, First name Last name
 
wrote:
 

 
> I have been using hunchentoot for the last two months and I have created a
 
> DB-Grid widget for myself. I pass relevant info in through parameters like
 
> table name and columns to display and the widget generates a html grid with
 
> paging, edit/delete and search functionality.
 
>
 
> My lisp experience however is limited and my widget is feeling more and more
 
> clunky as the functionality grows. I would like to ask the experts how they
 
> would structure/design such a widget using hunchentoot (cl-who +
 
> postmodern).
 
>
 
> I was thinking that such a widget might benefit others as well and others
 
> might have widgets that I might find useful. If we all use our own designs
 
> thow the resulting code might end up being to diverse to support. I would
 
> also not like to have to use a whole other framework on top of hunchentoot
 
> unless it came from the hunchentoot community and/or was supported by them.
 
> I would like the widgets to be as close as possible to hunchentoot to make
 
> them small, light and independant.
 
>
 
> Would it be feasible to set up a guideline/specification for hunchentoot
 
> widgets in general and widgets dealing with data-binding specifically? This
 
> way we could share widget among each other based on some standard that is
 
> documented and "trusted".
 

 
I think this generally sounds like a good idea although I imagine that
 
it'll be kind of hard to reach consensus even in the small group of
 
Hunchentoot users about the requirements for such widgets.
 

 
Cheers,
 
Edi.
 

 
_______________________________________________
 
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/20090120/742d895d/attachment.html>

From zaries at global.co.za  Tue Jan 20 09:24:12 2009
From: zaries at global.co.za (First name Last name)
Date: Tue, 20 Jan 2009 11:24:12 +0200
Subject: [hunchentoot-devel] Widget Guidlines
Message-ID: <MWS37b832e606b94b4ec097408ee9b51defb0@mws37>





?----- Original Message ------
?From:Tomasz Lipski
?Sent:Tuesday, January 20, 2009 10:26
?To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel at common-lisp.net; 
?Subject:Re: [hunchentoot-devel] Widget Guidlines



2009/1/19 First name Last name :
 
>> Hi
 

>> I have been using hunchentoot for the last two months and I have created a
 
>> DB-Grid widget for myself. I pass relevant info in through parameters like
 
>> table name and columns to display and the widget generates a html grid with
 
>> paging, edit/delete and search functionality.
 

 
>Hi,
 

 
>I believe that attempt for such standardization could be weblocks
 
>(based on hunchentoot)...
 

 
>http://weblocks.viridian-project.de/
 

 
>Best regards,
 

 
>Tomek Lipski
 

 


Tomek

I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it.

What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methadoligy (persistance,state...etc) that would fit in with hunchentoot's design and strong points. 

Regards
Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090120/f839eb61/attachment.html>

From zaries at global.co.za  Tue Jan 20 10:14:00 2009
From: zaries at global.co.za (First name Last name)
Date: Tue, 20 Jan 2009 12:14:00 +0200
Subject: [hunchentoot-devel] Widget Guidlines
Message-ID: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>

>> Hi
 



>> I have been using hunchentoot for the last two months and I have created a
 
>> DB-Grid widget for myself. I pass relevant info in through parameters like
 
>> table name and columns to display and the widget generates a html grid with
 
>> paging, edit/delete and search functionality.
 

 
>Hi,
 

 
>I believe that attempt for such standardization could be weblocks
 
>(based on hunchentoot)...
 

 
>http://weblocks.viridian-project.de/
 

 
>Best regards,
 

 
>Tomek Lipski
 

 


Tomek

I think weblocks is a bit of
 a over kill. I have never used it but from what I saw in the
 documentation it is big and in my opinion might carry to much over
 head. I am sure it has its right full place but I am not sure this is
 it.

What I was thinking about was free standing widgets that
 don't need a whole framework to carry them. A specification for
 something like this would include a list of common
 properties/functionality and general methodology
 (persistence,state...etc) that would fit in with hunchentoot's design
 and strong points. 

Regards
Phil

 

 

 PS. Apologies for re-posting but I am still getting the hang of using
 the mailing list....for some reason the previous post lost the text (think it is because my web client wraps replies in table)






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090120/875b1dab/attachment.html>

From hans.huebner at gmail.com  Tue Jan 20 10:35:35 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 20 Jan 2009 11:35:35 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>
References: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>
Message-ID: <fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>

On Tue, Jan 20, 2009 at 11:14, First name Last name <zaries at global.co.za> wrote:
> What I was thinking about was free standing widgets that don't need a whole
> framework to carry them. A specification for something like this would
> include a list of common properties/functionality and general methodology
> (persistence,state...etc) that would fit in with hunchentoot's design and
> strong points.

Start with something new.  I do not think that Hunchentoot itself
should be extended to include a widget framework, and I also think
that Edi's development model is not suitable for an effort similar to
the one that you have suggested.  Rather, I think what you are talking
about is creating a web framework with certain properties that you
don't seem to find in other frameworks.

I think the Hunchentoot mailing list is a suitable starting point to
discuss such a framework up to the point where enough traffic has been
gathered to create a suitable standalone project.  common-lisp.net is
a free hosting service for Common Lisp projects, just let me know if
you want me to set up infrastructure.

I'd suggest that you go ahead and maybe start by detailing out what
you think should be the common denominator for the "widgets" that you
propose.

-Hans



From tomek.lipski at gmail.com  Tue Jan 20 11:15:49 2009
From: tomek.lipski at gmail.com (Tomasz Lipski)
Date: Tue, 20 Jan 2009 12:15:49 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>
References: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>
	<fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>
Message-ID: <d33bafc50901200315k7ca08cb1n16b1a1e36aa9ca1d@mail.gmail.com>

> I think the Hunchentoot mailing list is a suitable starting point to
> discuss such a framework up to the point where enough traffic has been
> gathered to create a suitable standalone project.  common-lisp.net is
> a free hosting service for Common Lisp projects, just let me know if
> you want me to set up infrastructure.
>

Yeah, but what are the chances that it will end up with something
superior to weblocks?
Pretty low I guess..

t



From hans.huebner at gmail.com  Tue Jan 20 11:34:17 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 20 Jan 2009 12:34:17 +0100
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <d33bafc50901200315k7ca08cb1n16b1a1e36aa9ca1d@mail.gmail.com>
References: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>
	<fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>
	<d33bafc50901200315k7ca08cb1n16b1a1e36aa9ca1d@mail.gmail.com>
Message-ID: <fd2982320901200334h39db7290wbde4041c361648b7@mail.gmail.com>

On Tue, Jan 20, 2009 at 12:15, Tomasz Lipski <tomek.lipski at gmail.com> wrote:
>> I think the Hunchentoot mailing list is a suitable starting point to
>> discuss such a framework up to the point where enough traffic has been
>> gathered to create a suitable standalone project.  common-lisp.net is
>> a free hosting service for Common Lisp projects, just let me know if
>> you want me to set up infrastructure.
>>
>
> Yeah, but what are the chances that it will end up with something
> superior to weblocks?
> Pretty low I guess..

Not all needs are the same, and it may be that there is an interest in
whatever Phil comes up with as a mission statement for his widget
library.  I don't know Weblocks, but I have glanced at its web site
enough to know that it is not a fit for my development model.  I'm
assuming that other people feel the same.

My point is:  Hunchentoot is and will stay being a HTTP server library
and not include any "widget like" functionality that interoperates
with a database, requires a certain development model, supplies or
assumes a model for flow of control between server and all that.
Hunchentoot does not even know about HTML, and rightfully so.

-Hans



From zaries at global.co.za  Tue Jan 20 21:32:09 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Tue, 20 Jan 2009 23:32:09 +0200
Subject: [hunchentoot-devel] Widget Guidlines
In-Reply-To: <fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>
References: <MWS40aeec0d9ca16c429b8c316ee2e4f9188f@MWS40>
	<fd2982320901200235k5bd65235jba7a6d6f49aaad84@mail.gmail.com>
Message-ID: <1232487129.12598.11.camel@scatha>

On Tue, 2009-01-20 at 11:35 +0100, Hans H?bner wrote:
> On Tue, Jan 20, 2009 at 11:14, First name Last name <zaries at global.co.za> wrote:
> > What I was thinking about was free standing widgets that don't need a whole
> > framework to carry them. A specification for something like this would
> > include a list of common properties/functionality and general methodology
> > (persistence,state...etc) that would fit in with hunchentoot's design and
> > strong points.
> 
> Start with something new.  I do not think that Hunchentoot itself
> should be extended to include a widget framework, and I also think
> that Edi's development model is not suitable for an effort similar to
> the one that you have suggested.  Rather, I think what you are talking
> about is creating a web framework with certain properties that you
> don't seem to find in other frameworks.
> 
> I think the Hunchentoot mailing list is a suitable starting point to
> discuss such a framework up to the point where enough traffic has been
> gathered to create a suitable standalone project.  common-lisp.net is
> a free hosting service for Common Lisp projects, just let me know if
> you want me to set up infrastructure.
> 
> I'd suggest that you go ahead and maybe start by detailing out what
> you think should be the common denominator for the "widgets" that you
> propose.
> 
> -Hans
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

I agree that hunchentoot should not be altered for the sake of widgets
but in an effort to keep the framework as bare boned as possible I would
like it to be as close as possible to hunchentoot + cl-who basics.

Here follows some high level ideas I have.

Basic Goals:

Widgets should be as free standing as possible.

Widgets should follow simple rules that create conformity from the view
of the user and the implementer. These rules should be inforced by
minimal plumbing/framework code. 

Plumbing/framework code should be simple and light.


Widget Basics:

Widgets have properties that can be set and/or read.
    - Simple properties would be hunchentoot:parameter's
    - Complex properties would be clos objects or lists of objects
                - Complex properties that are objects or list of objects
                would free the widget from any persistance dependencies
                making persistance the resposibility of the user. There
                are just to many persistance models to comfortably
                integrate it into a light framework. 
                Or widgets could be grouped/categorized according to
                their persistance models?

Widgets have events.
    - Mandatory events
    - Optional events

Only certain properties can be set and/or read in the context of an
event.
        - This has to do with the fact that get or post form actions
        have limited access to hunchentoot parameters (see handlers)

A user should be able to register handlers for events. The handler
registration code should use the plumbing/framework code to enforce the
event property relationships.
    - Handlers are hunchentoot dispatchers

Widgets should be as generic as possible and as close to hunchentoot
basics as possible. By this I mean that widgets should only use
hunchentoot, cl-who and basic CL so that anybody with a basic
understanding of lisp and web/html can hack them.

Widgets should be self documenting. By this I mean that events,
properties and the fireing sequence of events should be accessible via
code so that plumbing/framework code can enforce rules.


Questions:

The big question I have is whether the plumbing/framework code should
use clos (my clos knowledge is very limited) to better group/package
rules or whether plain CL would do. In deciding this we should consider
both simplicity and cleanliness of the code that uses the
pumbing/framework code.

Conclusions:

In my opinion the above would give the widget designer the option of
being very generic or very prescriptive depending on the widgets goals,
yet it would have enough conformity to be recognisable as a widget based
on the plumbing/framework code.


Regards
Phil





From yazicivo at ttmail.com  Wed Jan 21 15:19:32 2009
From: yazicivo at ttmail.com (Volkan YAZICI)
Date: Wed, 21 Jan 2009 17:19:32 +0200
Subject: [hunchentoot-devel] CLEAR-INPUT and RAW-POST-DATA
Message-ID: <873afc1ybf.fsf@alamut.mobiliz.com.tr>

Hi,

Why doesn't we use

  (clear-input *hunchentoot-stream*)

instead of

  (raw-post-data :force-binary t)

in the START-OUTPUT function in headers.lisp?


Regards.



From yazicivo at ttmail.com  Wed Jan 21 16:22:43 2009
From: yazicivo at ttmail.com (Volkan YAZICI)
Date: Wed, 21 Jan 2009 18:22:43 +0200
Subject: [hunchentoot-devel] Maximum Request Size
Message-ID: <87prigzl0s.fsf@alamut.mobiliz.com.tr>

Hi,

Here are two patches[1][2] for both flexi-streams and hunchentoot. First
patch makes flexi-streams to signal a condition when stream BOUND gets
exceeded -- documentation and tests are included. Second one uses
freshly introduced flexi-streams feature to limit the maximum request
size.

The latter hunchentoot patch is not well tested, doesn't include any
documentation, replaces (raw-post-data ...) call with (clear-input ...)
to flush the input stream (thus, can have chunking and common lisp
implementation/platform related problems). It appears to be working for
me, I hope it would for you as well.

Thanks Hans Huebner for his kindly helps and Edi Weitz for his
uninterest in any effort.


Regards.

P.S. Enhancements are patched against the repositories located at
     http://bknr.net/svn/ediware address.

[1] http://www.students.itu.edu.tr/~yazicivo/tmp/flexi-streams-bound-invalidation-condition.patch.txt

[2] http://www.students.itu.edu.tr/~yazicivo/tmp/hunchentoot-request-size-limit.patch.txt



From sky at viridian-project.de  Tue Jan 27 12:20:05 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 27 Jan 2009 13:20:05 +0100 (CET)
Subject: [hunchentoot-devel] rfc2388: Handling of octets and strings is
	flawed
Message-ID: <61089.88.73.219.7.1233058805.squirrel@mail.stardawn.org>


rfc2388 doesn't care about the encoding of strings
despite of returning them.

The result of a parsed body that doesn't contain
binary data is then a vector of octets disguised
as string, forcing the ultimate user to jump through
this or a similar hoop:

  (sb-ext:octets-to-string
    (map '(vector (unsigned-byte 8)) #'char-int s))

Hunchentoot for example will just return this broken
string when rfc2388 is used for parsing a parameter's
content.

IMO parse-mime should return a vector of octets and
not a string. Its users (e.g. HT) should then apply
appropriate character conversion functions to build
a proper string.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From hans.huebner at gmail.com  Tue Jan 27 12:46:00 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 27 Jan 2009 13:46:00 +0100
Subject: [hunchentoot-devel] rfc2388: Handling of octets and strings is
	flawed
In-Reply-To: <61089.88.73.219.7.1233058805.squirrel@mail.stardawn.org>
References: <61089.88.73.219.7.1233058805.squirrel@mail.stardawn.org>
Message-ID: <fd2982320901270446v58c3eb8arca8ce5d49531aa5d@mail.gmail.com>

On Tue, Jan 27, 2009 at 13:20, Leslie P. Polzer <sky at viridian-project.de> wrote:
>
> rfc2388 doesn't care about the encoding of strings
> despite of returning them.

Replacing the rfc2388 system by something that is better has been on
the "should be done" list for a very long time.  Are you volunteering
to either repair it or come up with something that is better?

-Hans



From sky at viridian-project.de  Tue Jan 27 13:30:46 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 27 Jan 2009 14:30:46 +0100 (CET)
Subject: [hunchentoot-devel] rfc2388: Handling of octets and strings is
 flawed
In-Reply-To: <fd2982320901270446v58c3eb8arca8ce5d49531aa5d@mail.gmail.com>
References: <61089.88.73.219.7.1233058805.squirrel@mail.stardawn.org>
	<fd2982320901270446v58c3eb8arca8ce5d49531aa5d@mail.gmail.com>
Message-ID: <63311.88.73.219.7.1233063046.squirrel@mail.stardawn.org>


> Replacing the rfc2388 system by something that is better has been on
> the "should be done" list for a very long time.  Are you volunteering
> to either repair it or come up with something that is better?

I also think that a replacement is needed (I have another patch lying
around that is needed for missing final MIME boundaries).

Time is a problem, though. I'm going to put it up on LispNYC's list
of SoC projects I'm willing to mentor. Should no one turn up then I'm
likely going to work on it myself in a couple of months.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From css at swissjabber.ch  Wed Jan 28 11:37:02 2009
From: css at swissjabber.ch (css)
Date: Wed, 28 Jan 2009 12:37:02 +0100
Subject: [hunchentoot-devel] Changes in (send-headers) ?
In-Reply-To: <9e4493f70901271840o4ad227b9od6c70a5cbfdaacb9@mail.gmail.com>
References: <9e4493f70901271840o4ad227b9od6c70a5cbfdaacb9@mail.gmail.com>
Message-ID: <9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>

Hello.

I havent used hunchentoot for a while now, so I checked out the
svn-repository on http://bknr.net/svn/ediware/ (I hope this is the
correct one) and Installed the packages. The server seems to work, but
unfortunately, the following code seems not to do:

(defun http-seite ()
  (with-html-output (out (send-headers))
    (:html (:head (:title "Hallo-Welt-Seite"))
           (:body (:h1 "Hallo Welt")))))
(setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt"
'http-seite)))
(defvar *server* (start-server :port 8000))

When calling http://localhost:8000/hallo-welt, I only get an empty
page. For any other URL, i get a "not found" error.

When defining the function differently, returning a string, say

(defun http-seite ()
  (with-html-output-to-string (bla)
    (:html (:head (:title "Hallo-Welt-Seite"))
           (:body (:h1 "Hallo Welt")))))

the whole thing works. Also the more trivial functions

(defun http-2 () (write-char #\A (send-headers)))

and

(defun http-2 () (write-char #\A (send-headers))
                  (finish-output (send-headers)))

do not produce any output. I read the included documentation, but it
seems like (send-headers) hasnt changed its meening according to it,
and also the code doesnt say anything else.

Any Ideas what I could be doing wrong?

Greetings
Christoph



From hans.huebner at gmail.com  Wed Jan 28 15:28:52 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 28 Jan 2009 16:28:52 +0100
Subject: [hunchentoot-devel] Changes in (send-headers) ?
In-Reply-To: <9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>
References: <9e4493f70901271840o4ad227b9od6c70a5cbfdaacb9@mail.gmail.com>
	<9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>
Message-ID: <fd2982320901280728s47d1953ev62fccbed851a1d59@mail.gmail.com>

Christoph,

thank you for the report, what you see is actually a bug.  I was able
to pinpoint some possible causes for the problem, but have not yet
fixed the issue.  I will let the list know once it is fixed.

-Hans

On Wed, Jan 28, 2009 at 12:37, css <css at swissjabber.ch> wrote:
> Hello.
>
> I havent used hunchentoot for a while now, so I checked out the
> svn-repository on http://bknr.net/svn/ediware/ (I hope this is the
> correct one) and Installed the packages. The server seems to work, but
> unfortunately, the following code seems not to do:
>
> (defun http-seite ()
>  (with-html-output (out (send-headers))
>    (:html (:head (:title "Hallo-Welt-Seite"))
>           (:body (:h1 "Hallo Welt")))))
> (setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt"
> 'http-seite)))
> (defvar *server* (start-server :port 8000))
>
> When calling http://localhost:8000/hallo-welt, I only get an empty
> page. For any other URL, i get a "not found" error.
>
> When defining the function differently, returning a string, say
>
> (defun http-seite ()
>  (with-html-output-to-string (bla)
>    (:html (:head (:title "Hallo-Welt-Seite"))
>           (:body (:h1 "Hallo Welt")))))
>
> the whole thing works. Also the more trivial functions
>
> (defun http-2 () (write-char #\A (send-headers)))
>
> and
>
> (defun http-2 () (write-char #\A (send-headers))
>                  (finish-output (send-headers)))
>
> do not produce any output. I read the included documentation, but it
> seems like (send-headers) hasnt changed its meening according to it,
> and also the code doesnt say anything else.
>
> Any Ideas what I could be doing wrong?
>
> Greetings
> Christoph
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From edi at agharta.de  Wed Jan 28 16:01:11 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 28 Jan 2009 11:01:11 -0500
Subject: [hunchentoot-devel] Changes in (send-headers) ?
In-Reply-To: <9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>
References: <9e4493f70901271840o4ad227b9od6c70a5cbfdaacb9@mail.gmail.com>
	<9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>
Message-ID: <b56421a00901280801p666d1e78g5946227b87dece16@mail.gmail.com>

Hi,

Unfortunately, the HTML documentation isn't always up to date in the
development version and even some of the docstrings might not be fully
correct anymore.  In the case of send-headers, the docstring /is/
correct, though, although the change is hard to catch.  The modified
sentence there is "returns a BINARY stream" instead of "returns a
stream".  This is one of many changes that we did for performance
reasons.  So, if you want to send text to this stream, you'll have to
wrap it with a flexi stream first.

HTH,
Edi.

On Wed, Jan 28, 2009 at 6:37 AM, css <css at swissjabber.ch> wrote:
> Hello.
>
> I havent used hunchentoot for a while now, so I checked out the
> svn-repository on http://bknr.net/svn/ediware/ (I hope this is the
> correct one) and Installed the packages. The server seems to work, but
> unfortunately, the following code seems not to do:
>
> (defun http-seite ()
>  (with-html-output (out (send-headers))
>    (:html (:head (:title "Hallo-Welt-Seite"))
>           (:body (:h1 "Hallo Welt")))))
> (setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt"
> 'http-seite)))
> (defvar *server* (start-server :port 8000))
>
> When calling http://localhost:8000/hallo-welt, I only get an empty
> page. For any other URL, i get a "not found" error.
>
> When defining the function differently, returning a string, say
>
> (defun http-seite ()
>  (with-html-output-to-string (bla)
>    (:html (:head (:title "Hallo-Welt-Seite"))
>           (:body (:h1 "Hallo Welt")))))
>
> the whole thing works. Also the more trivial functions
>
> (defun http-2 () (write-char #\A (send-headers)))
>
> and
>
> (defun http-2 () (write-char #\A (send-headers))
>                  (finish-output (send-headers)))
>
> do not produce any output. I read the included documentation, but it
> seems like (send-headers) hasnt changed its meening according to it,
> and also the code doesnt say anything else.
>
> Any Ideas what I could be doing wrong?
>
> Greetings
> Christoph
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From christoph.senjak at web.de  Wed Jan 28 20:01:17 2009
From: christoph.senjak at web.de (christoph.senjak at web.de)
Date: Wed, 28 Jan 2009 21:01:17 +0100
Subject: [hunchentoot-devel] Changes in (send-headers) ?
In-Reply-To: <b56421a00901280801p666d1e78g5946227b87dece16@mail.gmail.com>
References: <9e4493f70901271840o4ad227b9od6c70a5cbfdaacb9@mail.gmail.com>
	<9e4493f70901280337w2bf65c1x84c759bc81ffdcaa@mail.gmail.com>
	<b56421a00901280801p666d1e78g5946227b87dece16@mail.gmail.com>
Message-ID: <9e4493f70901281201n6aac2296i3d60bf83aa3922f5@mail.gmail.com>

Hello.

Ok, thank you. This new behaviour makes more sense since for most
streamed output you will often want binary output anyway (and if not
can still use flexi-streams). The handler

(defun bla ()
	   (cl-who:with-html-output (out
				     (flexi-streams:make-flexi-stream
				      (hunchentoot:send-headers)))
	     (:html (:head (:title "blafasel"))
		    (:body (:h1 "quak")))))

works (though it is not very useful).

Christoph Senjak

2009/1/28 Edi Weitz <edi at agharta.de>:
> Hi,
>
> Unfortunately, the HTML documentation isn't always up to date in the
> development version and even some of the docstrings might not be fully
> correct anymore.  In the case of send-headers, the docstring /is/
> correct, though, although the change is hard to catch.  The modified
> sentence there is "returns a BINARY stream" instead of "returns a
> stream".  This is one of many changes that we did for performance
> reasons.  So, if you want to send text to this stream, you'll have to
> wrap it with a flexi stream first.
>
> HTH,
> Edi.
>
> On Wed, Jan 28, 2009 at 6:37 AM, css <css at swissjabber.ch> wrote:
>> Hello.
>>
>> I havent used hunchentoot for a while now, so I checked out the
>> svn-repository on http://bknr.net/svn/ediware/ (I hope this is the
>> correct one) and Installed the packages. The server seems to work, but
>> unfortunately, the following code seems not to do:
>>
>> (defun http-seite ()
>>  (with-html-output (out (send-headers))
>>    (:html (:head (:title "Hallo-Welt-Seite"))
>>           (:body (:h1 "Hallo Welt")))))
>> (setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt"
>> 'http-seite)))
>> (defvar *server* (start-server :port 8000))
>>
>> When calling http://localhost:8000/hallo-welt, I only get an empty
>> page. For any other URL, i get a "not found" error.
>>
>> When defining the function differently, returning a string, say
>>
>> (defun http-seite ()
>>  (with-html-output-to-string (bla)
>>    (:html (:head (:title "Hallo-Welt-Seite"))
>>           (:body (:h1 "Hallo Welt")))))
>>
>> the whole thing works. Also the more trivial functions
>>
>> (defun http-2 () (write-char #\A (send-headers)))
>>
>> and
>>
>> (defun http-2 () (write-char #\A (send-headers))
>>                  (finish-output (send-headers)))
>>
>> do not produce any output. I read the included documentation, but it
>> seems like (send-headers) hasnt changed its meening according to it,
>> and also the code doesnt say anything else.
>>
>> Any Ideas what I could be doing wrong?
>>
>> Greetings
>> Christoph
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From christoph.senjak at web.de  Thu Jan 29 00:06:50 2009
From: christoph.senjak at web.de (christoph.senjak at web.de)
Date: Thu, 29 Jan 2009 01:06:50 +0100
Subject: [hunchentoot-devel] Is there any implementation of XML-RPC for
	Hunchentoot
Message-ID: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>

Hello.

Again a question. Is there already any Implementation of XML-RPC
running on Hunchentoot. I only found S-XML-RPC so far, and it seems
like it is using allegro serve. It may not be too hard to implement,
but if it is already there, I dont want to do it.

Greetings
Christoph-Simon Senjak



From rsynnott at gmail.com  Thu Jan 29 00:53:17 2009
From: rsynnott at gmail.com (Robert Synnott)
Date: Thu, 29 Jan 2009 00:53:17 +0000
Subject: [hunchentoot-devel] Is there any implementation of XML-RPC for
	Hunchentoot
In-Reply-To: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>
References: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>
Message-ID: <24f203480901281653g51eebc8eh7b10a6e65703770b@mail.gmail.com>

2009/1/29  <christoph.senjak at web.de>:
> Hello.
>
> Again a question. Is there already any Implementation of XML-RPC
> running on Hunchentoot. I only found S-XML-RPC so far, and it seems
> like it is using allegro serve. It may not be too hard to implement,
> but if it is already there, I dont want to do it.
>
> Greetings
> Christoph-Simon Senjak
>

This might be useful:
http://boinkor.net/archives/2007/12/cxmlrpc_update_changed_interfa.html
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Robert Synnott
http://myblog.rsynnott.com
MSN: rsynnott at gmail.com
Jabber: rsynnott at gmail.com



From rsynnott at gmail.com  Thu Jan 29 00:53:17 2009
From: rsynnott at gmail.com (Robert Synnott)
Date: Thu, 29 Jan 2009 00:53:17 +0000
Subject: [hunchentoot-devel] Is there any implementation of XML-RPC for
	Hunchentoot
In-Reply-To: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>
References: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>
Message-ID: <24f203480901281653g51eebc8eh7b10a6e65703770b@mail.gmail.com>

2009/1/29  <christoph.senjak at web.de>:
> Hello.
>
> Again a question. Is there already any Implementation of XML-RPC
> running on Hunchentoot. I only found S-XML-RPC so far, and it seems
> like it is using allegro serve. It may not be too hard to implement,
> but if it is already there, I dont want to do it.
>
> Greetings
> Christoph-Simon Senjak
>

This might be useful:
http://boinkor.net/archives/2007/12/cxmlrpc_update_changed_interfa.html
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Robert Synnott
http://myblog.rsynnott.com
MSN: rsynnott at gmail.com
Jabber: rsynnott at gmail.com



From edi at agharta.de  Thu Jan 29 12:52:58 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 29 Jan 2009 07:52:58 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
Message-ID: <b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>

On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com> wrote:

> Thanks Hans Huebner for his kindly helps and Edi Weitz for his
> uninterest in any effort.

Volkan,

If you think you're somehow entitled to an immediate reply or any
action from me just because you sent a patch that is "not well tested"
and "doesn't include any documentation", you're obviously living on a
different planet or at least you don't know what it means to have a
job and a family in addition to taking care of more than a dozen open
source libraries in your spare time.  I might look at these patches if
and when I find the time to work on Hunchentoot again or I might not.
If that's not acceptable to you, the license on all of my libs always
allows you to fork them and basically do with them whatever you want.

For those of you who wonder why Hunchentoot and some other libraries
have been in limbo for quite some time now, here's a quick
explanation: A company paid Hans to make a couple of additions to
Hunchentoot which are now in the bknr.net repository.  I also worked
on this a bit in my spare time and added some code, mainly for
performance improvements.  The good thing is that due to Hans' work
the development version is much improved in several aspects over the
current release.  The bad thing is that due to Hans' and my changes
the dev versions of Hunchentoot, Chunga, and Drakma have to be
released together, because they are mutually incompatible with the
released versions.  And, for them to become acceptable (for me)
release versions, there's a certain amount of clean-up and
documentation needed that still has to be done.

Now, the deal with the afore-mentioned company was that they would pay
Hans and me to do this clean-up and integration work so that we once
again have "official" release versions that are feature-wise in sync
with the current dev versions.  This hasn't happened so far, and right
now I fail to see why I should spend a significant amount of my spare
time to do this clean-up work when I have more interesting things to
do.  /Maybe/, this will happen in the future (paid or unpaid), or
maybe there'll at some point just be another Hunchentoot release based
on 0.15.7 and the dev changes will be lost.  Until then, I think the
current release isn't perfect, but certainly something that can be
used (and is used) without significant problems.

Cheers,
Edi.



From whalliburton at gmail.com  Thu Jan 29 17:28:47 2009
From: whalliburton at gmail.com (William Halliburton)
Date: Thu, 29 Jan 2009 12:28:47 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
Message-ID: <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>

Hello everyone...

I would like to volunteer any amount of time needed to get Hans's changes
folded into the main repository and/or get the development version moving
forward and more accessible. I am working on a startup that is currently
using hunchentoot and, as chance may have it, I am right about now going to
be digging into hunchentoot and friends as part of a performance and
understanding push.

Currently the BKNR repository is down, but once it gets back up I would like
to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma
and I invite anyone that wishes to help contribute to this effort.

I am most interested in figuring out and testing the performance
characteristics of the libraries with respects to threading/non-threading,
select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the
time and effort to develop and test these different scenarios.

Thanks to everyone.

Peace,
Will

On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:

> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com>
> wrote:
>
> > Thanks Hans Huebner for his kindly helps and Edi Weitz for his
> > uninterest in any effort.
>
> Volkan,
>
> If you think you're somehow entitled to an immediate reply or any
> action from me just because you sent a patch that is "not well tested"
> and "doesn't include any documentation", you're obviously living on a
> different planet or at least you don't know what it means to have a
> job and a family in addition to taking care of more than a dozen open
> source libraries in your spare time.  I might look at these patches if
> and when I find the time to work on Hunchentoot again or I might not.
> If that's not acceptable to you, the license on all of my libs always
> allows you to fork them and basically do with them whatever you want.
>
> For those of you who wonder why Hunchentoot and some other libraries
> have been in limbo for quite some time now, here's a quick
> explanation: A company paid Hans to make a couple of additions to
> Hunchentoot which are now in the bknr.net repository.  I also worked
> on this a bit in my spare time and added some code, mainly for
> performance improvements.  The good thing is that due to Hans' work
> the development version is much improved in several aspects over the
> current release.  The bad thing is that due to Hans' and my changes
> the dev versions of Hunchentoot, Chunga, and Drakma have to be
> released together, because they are mutually incompatible with the
> released versions.  And, for them to become acceptable (for me)
> release versions, there's a certain amount of clean-up and
> documentation needed that still has to be done.
>
> Now, the deal with the afore-mentioned company was that they would pay
> Hans and me to do this clean-up and integration work so that we once
> again have "official" release versions that are feature-wise in sync
> with the current dev versions.  This hasn't happened so far, and right
> now I fail to see why I should spend a significant amount of my spare
> time to do this clean-up work when I have more interesting things to
> do.  /Maybe/, this will happen in the future (paid or unpaid), or
> maybe there'll at some point just be another Hunchentoot release based
> on 0.15.7 and the dev changes will be lost.  Until then, I think the
> current release isn't perfect, but certainly something that can be
> used (and is used) without significant problems.
>
> Cheers,
> Edi.
>
> _______________________________________________
> 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/20090129/b342cfd7/attachment.html>

From mail at chaitanyagupta.com  Thu Jan 29 19:04:33 2009
From: mail at chaitanyagupta.com (Chaitanya Gupta)
Date: Fri, 30 Jan 2009 00:34:33 +0530
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
Message-ID: <4981FDC1.7000906@chaitanyagupta.com>

Edi Weitz wrote:
> Now, the deal with the afore-mentioned company was that they would pay
> Hans and me to do this clean-up and integration work so that we once
> again have "official" release versions that are feature-wise in sync
> with the current dev versions.  This hasn't happened so far, and right
> now I fail to see why I should spend a significant amount of my spare
> time to do this clean-up work when I have more interesting things to
> do.

I haven't worked a lot on the dev version yet, but I have been planning 
to give it a spin for some time. (believe I read somewhere that the dev 
version would allow hunchentoot to run as an I/O multiplexer like 
select, epoll, etc., right?)

I also happen to have lots of spare time right now, and am willing to 
spend some of it on cleanup, documentation, etc. of the dev version, if 
possible. Any pointers or helpful hints on where to start?

Chaitanya




From hans.huebner at gmail.com  Thu Jan 29 19:27:59 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 29 Jan 2009 20:27:59 +0100
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
Message-ID: <fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>

Hi,

bknr.net was temporarily down due to a power failure at the data
center.  The machine is back up now.

What is the plan for the git repository?  Why is it needed, what makes
it useful?  I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a
community project (i.e. we'll review all patches that we accept into
the repository that eventually becomes the release), I'm not sure how
another level of indirection helps.  It may be possible to convince us
to switch to git if there is a good reason to do so, but that'd need
some explanation.

-Hans

On Thu, Jan 29, 2009 at 18:28, William Halliburton
<whalliburton at gmail.com> wrote:
> Hello everyone...
>
> I would like to volunteer any amount of time needed to get Hans's changes
> folded into the main repository and/or get the development version moving
> forward and more accessible. I am working on a startup that is currently
> using hunchentoot and, as chance may have it, I am right about now going to
> be digging into hunchentoot and friends as part of a performance and
> understanding push.
>
> Currently the BKNR repository is down, but once it gets back up I would like
> to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma
> and I invite anyone that wishes to help contribute to this effort.
>
> I am most interested in figuring out and testing the performance
> characteristics of the libraries with respects to threading/non-threading,
> select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the
> time and effort to develop and test these different scenarios.
>
> Thanks to everyone.
>
> Peace,
> Will
>
> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
>>
>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com>
>> wrote:
>>
>> > Thanks Hans Huebner for his kindly helps and Edi Weitz for his
>> > uninterest in any effort.
>>
>> Volkan,
>>
>> If you think you're somehow entitled to an immediate reply or any
>> action from me just because you sent a patch that is "not well tested"
>> and "doesn't include any documentation", you're obviously living on a
>> different planet or at least you don't know what it means to have a
>> job and a family in addition to taking care of more than a dozen open
>> source libraries in your spare time.  I might look at these patches if
>> and when I find the time to work on Hunchentoot again or I might not.
>> If that's not acceptable to you, the license on all of my libs always
>> allows you to fork them and basically do with them whatever you want.
>>
>> For those of you who wonder why Hunchentoot and some other libraries
>> have been in limbo for quite some time now, here's a quick
>> explanation: A company paid Hans to make a couple of additions to
>> Hunchentoot which are now in the bknr.net repository.  I also worked
>> on this a bit in my spare time and added some code, mainly for
>> performance improvements.  The good thing is that due to Hans' work
>> the development version is much improved in several aspects over the
>> current release.  The bad thing is that due to Hans' and my changes
>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
>> released together, because they are mutually incompatible with the
>> released versions.  And, for them to become acceptable (for me)
>> release versions, there's a certain amount of clean-up and
>> documentation needed that still has to be done.
>>
>> Now, the deal with the afore-mentioned company was that they would pay
>> Hans and me to do this clean-up and integration work so that we once
>> again have "official" release versions that are feature-wise in sync
>> with the current dev versions.  This hasn't happened so far, and right
>> now I fail to see why I should spend a significant amount of my spare
>> time to do this clean-up work when I have more interesting things to
>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
>> maybe there'll at some point just be another Hunchentoot release based
>> on 0.15.7 and the dev changes will be lost.  Until then, I think the
>> current release isn't perfect, but certainly something that can be
>> used (and is used) without significant problems.
>>
>> Cheers,
>> Edi.
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From whalliburton at gmail.com  Thu Jan 29 20:23:25 2009
From: whalliburton at gmail.com (William Halliburton)
Date: Thu, 29 Jan 2009 15:23:25 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
Message-ID: <4e7bd29e0901291223k60bbd70eq143dc5b611e91ce@mail.gmail.com>

Hi Hans,

I wont be a fanboy here and express the benefits of git over svn, but the
coolaid tasted great!

I figured from the gist of Edi's original post that there just isn't enough
time (understandably) to move hunchentoot forward and I believe that
garnering a little community support on this worthwhile, at least to me,
project would be helped  by converting it into a "community project", and a
distributed decentralized development model should help in that regard.

Will

On Thu, Jan 29, 2009 at 2:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:

> Hi,
>
> bknr.net was temporarily down due to a power failure at the data
> center.  The machine is back up now.
>
> What is the plan for the git repository?  Why is it needed, what makes
> it useful?  I'm aware of the "centralized maintenance" "problem" of
> Subversion, but as Hunchentoot is not going to convert into a
> community project (i.e. we'll review all patches that we accept into
> the repository that eventually becomes the release), I'm not sure how
> another level of indirection helps.  It may be possible to convince us
> to switch to git if there is a good reason to do so, but that'd need
> some explanation.
>
> -Hans
>
> On Thu, Jan 29, 2009 at 18:28, William Halliburton
> <whalliburton at gmail.com> wrote:
> > Hello everyone...
> >
> > I would like to volunteer any amount of time needed to get Hans's changes
> > folded into the main repository and/or get the development version moving
> > forward and more accessible. I am working on a startup that is currently
> > using hunchentoot and, as chance may have it, I am right about now going
> to
> > be digging into hunchentoot and friends as part of a performance and
> > understanding push.
> >
> > Currently the BKNR repository is down, but once it gets back up I would
> like
> > to set up a git repository of flexi-streams, hunchentoot, chunga, and
> drakma
> > and I invite anyone that wishes to help contribute to this effort.
> >
> > I am most interested in figuring out and testing the performance
> > characteristics of the libraries with respects to
> threading/non-threading,
> > select/epoll, and proxy/no-proxy on SBCL and am most willing to put in
> the
> > time and effort to develop and test these different scenarios.
> >
> > Thanks to everyone.
> >
> > Peace,
> > Will
> >
> > On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
> >>
> >> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com>
> >> wrote:
> >>
> >> > Thanks Hans Huebner for his kindly helps and Edi Weitz for his
> >> > uninterest in any effort.
> >>
> >> Volkan,
> >>
> >> If you think you're somehow entitled to an immediate reply or any
> >> action from me just because you sent a patch that is "not well tested"
> >> and "doesn't include any documentation", you're obviously living on a
> >> different planet or at least you don't know what it means to have a
> >> job and a family in addition to taking care of more than a dozen open
> >> source libraries in your spare time.  I might look at these patches if
> >> and when I find the time to work on Hunchentoot again or I might not.
> >> If that's not acceptable to you, the license on all of my libs always
> >> allows you to fork them and basically do with them whatever you want.
> >>
> >> For those of you who wonder why Hunchentoot and some other libraries
> >> have been in limbo for quite some time now, here's a quick
> >> explanation: A company paid Hans to make a couple of additions to
> >> Hunchentoot which are now in the bknr.net repository.  I also worked
> >> on this a bit in my spare time and added some code, mainly for
> >> performance improvements.  The good thing is that due to Hans' work
> >> the development version is much improved in several aspects over the
> >> current release.  The bad thing is that due to Hans' and my changes
> >> the dev versions of Hunchentoot, Chunga, and Drakma have to be
> >> released together, because they are mutually incompatible with the
> >> released versions.  And, for them to become acceptable (for me)
> >> release versions, there's a certain amount of clean-up and
> >> documentation needed that still has to be done.
> >>
> >> Now, the deal with the afore-mentioned company was that they would pay
> >> Hans and me to do this clean-up and integration work so that we once
> >> again have "official" release versions that are feature-wise in sync
> >> with the current dev versions.  This hasn't happened so far, and right
> >> now I fail to see why I should spend a significant amount of my spare
> >> time to do this clean-up work when I have more interesting things to
> >> do.  /Maybe/, this will happen in the future (paid or unpaid), or
> >> maybe there'll at some point just be another Hunchentoot release based
> >> on 0.15.7 and the dev changes will be lost.  Until then, I think the
> >> current release isn't perfect, but certainly something that can be
> >> used (and is used) without significant problems.
> >>
> >> Cheers,
> >> Edi.
> >>
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
>
> _______________________________________________
> 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/20090129/d127f2b3/attachment.html>

From edi at agharta.de  Thu Jan 29 19:26:09 2009
From: edi at agharta.de (Edi Weitz)
Date: Thu, 29 Jan 2009 14:26:09 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <4981FDC1.7000906@chaitanyagupta.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4981FDC1.7000906@chaitanyagupta.com>
Message-ID: <b56421a00901291126g51be8022xcf0c153b9456416e@mail.gmail.com>

On Thu, Jan 29, 2009 at 2:04 PM, Chaitanya Gupta
<mail at chaitanyagupta.com> wrote:

> I haven't worked a lot on the dev version yet, but I have been planning to
> give it a spin for some time. (believe I read somewhere that the dev version
> would allow hunchentoot to run as an I/O multiplexer like select, epoll,
> etc., right?)

Not out of the box, but the new infrastructure should in theory allow that.

> I also happen to have lots of spare time right now, and am willing to spend
> some of it on cleanup, documentation, etc. of the dev version, if possible.
> Any pointers or helpful hints on where to start?

One part of the work would be to look at all of the docstrings and to
check if they still describe what the functions are actually doing.
Another part would be to go over the HTML documentation and refactor
it to explain the new infrastructure.  I'm afraid the latter part can
probably only be done by Hans and me as we're not even sure that the
infrastructure will stay the way it is now.  (It will likely be very
similar to the current version, but there might be new names and some
other reshuffling.)

Thanks to you and William for offering your help, but I'm not sure if
having you working on the documentation would really buy us much right
now.  I'm pretty anal about this and I'd probably go over all of it
once again anyway... :)

What is always helpful is more people testing the dev version, playing
with it and finding and reporting bugs - as long as you don't expect
an immediate reply or fix.  You can be sure that all issues will be
taken care of eventually.  RSN...

Thanks,
Edi.



From amalawi at gmail.com  Thu Jan 29 21:15:31 2009
From: amalawi at gmail.com (Ala'a (cmo-0))
Date: Fri, 30 Jan 2009 01:15:31 +0400
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
Message-ID: <af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>

> What is the plan for the git repository?  Why is it needed, what makes
> it useful?

i find the following feature helpful (YMMV)

http://github.com/guides/pull-requests

it will be a helpful tool of using git to allow for easy forks and
experimentation and easy cherry pick any changes made by other forks.

cmo-0

On Thu, Jan 29, 2009 at 11:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Hi,
>
> bknr.net was temporarily down due to a power failure at the data
> center.  The machine is back up now.
>
  I'm aware of the "centralized maintenance" "problem" of
> Subversion, but as Hunchentoot is not going to convert into a
> community project (i.e. we'll review all patches that we accept into
> the repository that eventually becomes the release), I'm not sure how
> another level of indirection helps.  It may be possible to convince us
> to switch to git if there is a good reason to do so, but that'd need
> some explanation.
>
> -Hans
>
> On Thu, Jan 29, 2009 at 18:28, William Halliburton
> <whalliburton at gmail.com> wrote:
>> Hello everyone...
>>
>> I would like to volunteer any amount of time needed to get Hans's changes
>> folded into the main repository and/or get the development version moving
>> forward and more accessible. I am working on a startup that is currently
>> using hunchentoot and, as chance may have it, I am right about now going to
>> be digging into hunchentoot and friends as part of a performance and
>> understanding push.
>>
>> Currently the BKNR repository is down, but once it gets back up I would like
>> to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma
>> and I invite anyone that wishes to help contribute to this effort.
>>
>> I am most interested in figuring out and testing the performance
>> characteristics of the libraries with respects to threading/non-threading,
>> select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the
>> time and effort to develop and test these different scenarios.
>>
>> Thanks to everyone.
>>
>> Peace,
>> Will
>>
>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
>>>
>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com>
>>> wrote:
>>>
>>> > Thanks Hans Huebner for his kindly helps and Edi Weitz for his
>>> > uninterest in any effort.
>>>
>>> Volkan,
>>>
>>> If you think you're somehow entitled to an immediate reply or any
>>> action from me just because you sent a patch that is "not well tested"
>>> and "doesn't include any documentation", you're obviously living on a
>>> different planet or at least you don't know what it means to have a
>>> job and a family in addition to taking care of more than a dozen open
>>> source libraries in your spare time.  I might look at these patches if
>>> and when I find the time to work on Hunchentoot again or I might not.
>>> If that's not acceptable to you, the license on all of my libs always
>>> allows you to fork them and basically do with them whatever you want.
>>>
>>> For those of you who wonder why Hunchentoot and some other libraries
>>> have been in limbo for quite some time now, here's a quick
>>> explanation: A company paid Hans to make a couple of additions to
>>> Hunchentoot which are now in the bknr.net repository.  I also worked
>>> on this a bit in my spare time and added some code, mainly for
>>> performance improvements.  The good thing is that due to Hans' work
>>> the development version is much improved in several aspects over the
>>> current release.  The bad thing is that due to Hans' and my changes
>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
>>> released together, because they are mutually incompatible with the
>>> released versions.  And, for them to become acceptable (for me)
>>> release versions, there's a certain amount of clean-up and
>>> documentation needed that still has to be done.
>>>
>>> Now, the deal with the afore-mentioned company was that they would pay
>>> Hans and me to do this clean-up and integration work so that we once
>>> again have "official" release versions that are feature-wise in sync
>>> with the current dev versions.  This hasn't happened so far, and right
>>> now I fail to see why I should spend a significant amount of my spare
>>> time to do this clean-up work when I have more interesting things to
>>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
>>> maybe there'll at some point just be another Hunchentoot release based
>>> on 0.15.7 and the dev changes will be lost.  Until then, I think the
>>> current release isn't perfect, but certainly something that can be
>>> used (and is used) without significant problems.
>>>
>>> Cheers,
>>> Edi.
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
It does not matter how fast your code is, if it does not work!



From cavandusen at gmail.com  Thu Jan 29 23:17:16 2009
From: cavandusen at gmail.com (Chris Van Dusen)
Date: Thu, 29 Jan 2009 17:17:16 -0600
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
Message-ID: <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>

It would be, but (at the risk of being presumptuous) allowing for easy  
forks and experimentation is not the goal of the maintainers.

I could see that as being the goal of a person that wanted to fork the  
code and/or experiment.  As Edi said, you have the freedom to fork...,  
or not.

Chris.

On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:

>> What is the plan for the git repository?  Why is it needed, what  
>> makes
>> it useful?
>
> i find the following feature helpful (YMMV)
>
> http://github.com/guides/pull-requests
>
> it will be a helpful tool of using git to allow for easy forks and
> experimentation and easy cherry pick any changes made by other forks.
>
> cmo-0
>
> On Thu, Jan 29, 2009 at 11:27 PM, Hans H?bner  
> <hans.huebner at gmail.com> wrote:
>> Hi,
>>
>> bknr.net was temporarily down due to a power failure at the data
>> center.  The machine is back up now.
>>
>  I'm aware of the "centralized maintenance" "problem" of
>> Subversion, but as Hunchentoot is not going to convert into a
>> community project (i.e. we'll review all patches that we accept into
>> the repository that eventually becomes the release), I'm not sure how
>> another level of indirection helps.  It may be possible to convince  
>> us
>> to switch to git if there is a good reason to do so, but that'd need
>> some explanation.
>>
>> -Hans
>>
>> On Thu, Jan 29, 2009 at 18:28, William Halliburton
>> <whalliburton at gmail.com> wrote:
>>> Hello everyone...
>>>
>>> I would like to volunteer any amount of time needed to get Hans's  
>>> changes
>>> folded into the main repository and/or get the development version  
>>> moving
>>> forward and more accessible. I am working on a startup that is  
>>> currently
>>> using hunchentoot and, as chance may have it, I am right about now  
>>> going to
>>> be digging into hunchentoot and friends as part of a performance and
>>> understanding push.
>>>
>>> Currently the BKNR repository is down, but once it gets back up I  
>>> would like
>>> to set up a git repository of flexi-streams, hunchentoot, chunga,  
>>> and drakma
>>> and I invite anyone that wishes to help contribute to this effort.
>>>
>>> I am most interested in figuring out and testing the performance
>>> characteristics of the libraries with respects to threading/non- 
>>> threading,
>>> select/epoll, and proxy/no-proxy on SBCL and am most willing to  
>>> put in the
>>> time and effort to develop and test these different scenarios.
>>>
>>> Thanks to everyone.
>>>
>>> Peace,
>>> Will
>>>
>>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
>>>>
>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com 
>>>> >
>>>> wrote:
>>>>
>>>>> Thanks Hans Huebner for his kindly helps and Edi Weitz for his
>>>>> uninterest in any effort.
>>>>
>>>> Volkan,
>>>>
>>>> If you think you're somehow entitled to an immediate reply or any
>>>> action from me just because you sent a patch that is "not well  
>>>> tested"
>>>> and "doesn't include any documentation", you're obviously living  
>>>> on a
>>>> different planet or at least you don't know what it means to have a
>>>> job and a family in addition to taking care of more than a dozen  
>>>> open
>>>> source libraries in your spare time.  I might look at these  
>>>> patches if
>>>> and when I find the time to work on Hunchentoot again or I might  
>>>> not.
>>>> If that's not acceptable to you, the license on all of my libs  
>>>> always
>>>> allows you to fork them and basically do with them whatever you  
>>>> want.
>>>>
>>>> For those of you who wonder why Hunchentoot and some other  
>>>> libraries
>>>> have been in limbo for quite some time now, here's a quick
>>>> explanation: A company paid Hans to make a couple of additions to
>>>> Hunchentoot which are now in the bknr.net repository.  I also  
>>>> worked
>>>> on this a bit in my spare time and added some code, mainly for
>>>> performance improvements.  The good thing is that due to Hans' work
>>>> the development version is much improved in several aspects over  
>>>> the
>>>> current release.  The bad thing is that due to Hans' and my changes
>>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
>>>> released together, because they are mutually incompatible with the
>>>> released versions.  And, for them to become acceptable (for me)
>>>> release versions, there's a certain amount of clean-up and
>>>> documentation needed that still has to be done.
>>>>
>>>> Now, the deal with the afore-mentioned company was that they  
>>>> would pay
>>>> Hans and me to do this clean-up and integration work so that we  
>>>> once
>>>> again have "official" release versions that are feature-wise in  
>>>> sync
>>>> with the current dev versions.  This hasn't happened so far, and  
>>>> right
>>>> now I fail to see why I should spend a significant amount of my  
>>>> spare
>>>> time to do this clean-up work when I have more interesting things  
>>>> to
>>>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
>>>> maybe there'll at some point just be another Hunchentoot release  
>>>> based
>>>> on 0.15.7 and the dev changes will be lost.  Until then, I think  
>>>> the
>>>> current release isn't perfect, but certainly something that can be
>>>> used (and is used) without significant problems.
>>>>
>>>> Cheers,
>>>> Edi.
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
>
>
> -- 
> It does not matter how fast your code is, if it does not work!
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From hutch-lists at recursive.ca  Fri Jan 30 04:22:08 2009
From: hutch-lists at recursive.ca (Bob Hutchison)
Date: Thu, 29 Jan 2009 23:22:08 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
Message-ID: <C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>

Hi,

On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:

> It would be, but (at the risk of being presumptuous) allowing for easy
> forks and experimentation is not the goal of the maintainers.
>
>
> I could see that as being the goal of a person that wanted to fork the
> code and/or experiment.  As Edi said, you have the freedom to fork...,
> or not.

This 'fork' business when using git seems to be more due to github  
than git, and doesn't normally mean a forked project like, say, the  
Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a  
bunch of tools that allow for core maintainers (e.g. Edi and Hans) to  
keep control of the code base but to have other people contribute  
(without worrying about things like commit privileges, and messed up  
patch files). This made a *huge* difference to the Rails project  
starting last April or so. These two links give more information along  
the lines of that on the page linked to by cmo-0:

<http://github.com/guides/fork-a-project-and-submit-your-modifications>
<http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch>

And they give you shiny baubles like:

<http://github.com/madrobby/scriptaculous/network>

This is the arbitrarily chosen (near the top of the most-forked list  
with a few forks yet to be pulled) scrit.aculo.us project, 292 forks  
-- but still only one script.aculo.us :-)

I've been using github for my company and my personal work for about  
10 months now. Works well for me. Big wins:

-- works off line
-- branching and tagging easy and fast
-- master branch can be 'rebased' into the branches, and the branches  
commited as though a single commit (you can, if you want, lose all  
those micro commits and sub-branches -- if you look at the github  
network/fork graph, each of the forks can be reduced into a single  
'dot' on the master branch, or not).
-- commits are orders of magnitude faster than SVN, at least for me.

I think git might make things easier for Edi and Hans at the cost of  
having to learn it. More importantly, things like Volkan's patch might  
be better tested or improved by having people contribute to the fork  
rather than the master branch. Keep this kind of thing out of their  
hair until it's more ready.

Cheers,
Bob

>
>
> Chris.
>
> On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
>
>>> What is the plan for the git repository?  Why is it needed, what
>>> makes
>>> it useful?
>>
>> i find the following feature helpful (YMMV)
>>
>> http://github.com/guides/pull-requests
>>
>> it will be a helpful tool of using git to allow for easy forks and
>> experimentation and easy cherry pick any changes made by other forks.
>>
>> cmo-0
>>
>> On Thu, Jan 29, 2009 at 11:27 PM, Hans H?bner
>> <hans.huebner at gmail.com> wrote:
>>> Hi,
>>>
>>> bknr.net was temporarily down due to a power failure at the data
>>> center.  The machine is back up now.
>>>
>> I'm aware of the "centralized maintenance" "problem" of
>>> Subversion, but as Hunchentoot is not going to convert into a
>>> community project (i.e. we'll review all patches that we accept into
>>> the repository that eventually becomes the release), I'm not sure  
>>> how
>>> another level of indirection helps.  It may be possible to convince
>>> us
>>> to switch to git if there is a good reason to do so, but that'd need
>>> some explanation.
>>>
>>> -Hans
>>>
>>> On Thu, Jan 29, 2009 at 18:28, William Halliburton
>>> <whalliburton at gmail.com> wrote:
>>>> Hello everyone...
>>>>
>>>> I would like to volunteer any amount of time needed to get Hans's
>>>> changes
>>>> folded into the main repository and/or get the development version
>>>> moving
>>>> forward and more accessible. I am working on a startup that is
>>>> currently
>>>> using hunchentoot and, as chance may have it, I am right about now
>>>> going to
>>>> be digging into hunchentoot and friends as part of a performance  
>>>> and
>>>> understanding push.
>>>>
>>>> Currently the BKNR repository is down, but once it gets back up I
>>>> would like
>>>> to set up a git repository of flexi-streams, hunchentoot, chunga,
>>>> and drakma
>>>> and I invite anyone that wishes to help contribute to this effort.
>>>>
>>>> I am most interested in figuring out and testing the performance
>>>> characteristics of the libraries with respects to threading/non-
>>>> threading,
>>>> select/epoll, and proxy/no-proxy on SBCL and am most willing to
>>>> put in the
>>>> time and effort to develop and test these different scenarios.
>>>>
>>>> Thanks to everyone.
>>>>
>>>> Peace,
>>>> Will
>>>>
>>>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
>>>>>
>>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> Thanks Hans Huebner for his kindly helps and Edi Weitz for his
>>>>>> uninterest in any effort.
>>>>>
>>>>> Volkan,
>>>>>
>>>>> If you think you're somehow entitled to an immediate reply or any
>>>>> action from me just because you sent a patch that is "not well
>>>>> tested"
>>>>> and "doesn't include any documentation", you're obviously living
>>>>> on a
>>>>> different planet or at least you don't know what it means to  
>>>>> have a
>>>>> job and a family in addition to taking care of more than a dozen
>>>>> open
>>>>> source libraries in your spare time.  I might look at these
>>>>> patches if
>>>>> and when I find the time to work on Hunchentoot again or I might
>>>>> not.
>>>>> If that's not acceptable to you, the license on all of my libs
>>>>> always
>>>>> allows you to fork them and basically do with them whatever you
>>>>> want.
>>>>>
>>>>> For those of you who wonder why Hunchentoot and some other
>>>>> libraries
>>>>> have been in limbo for quite some time now, here's a quick
>>>>> explanation: A company paid Hans to make a couple of additions to
>>>>> Hunchentoot which are now in the bknr.net repository.  I also
>>>>> worked
>>>>> on this a bit in my spare time and added some code, mainly for
>>>>> performance improvements.  The good thing is that due to Hans'  
>>>>> work
>>>>> the development version is much improved in several aspects over
>>>>> the
>>>>> current release.  The bad thing is that due to Hans' and my  
>>>>> changes
>>>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
>>>>> released together, because they are mutually incompatible with the
>>>>> released versions.  And, for them to become acceptable (for me)
>>>>> release versions, there's a certain amount of clean-up and
>>>>> documentation needed that still has to be done.
>>>>>
>>>>> Now, the deal with the afore-mentioned company was that they
>>>>> would pay
>>>>> Hans and me to do this clean-up and integration work so that we
>>>>> once
>>>>> again have "official" release versions that are feature-wise in
>>>>> sync
>>>>> with the current dev versions.  This hasn't happened so far, and
>>>>> right
>>>>> now I fail to see why I should spend a significant amount of my
>>>>> spare
>>>>> time to do this clean-up work when I have more interesting things
>>>>> to
>>>>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
>>>>> maybe there'll at some point just be another Hunchentoot release
>>>>> based
>>>>> on 0.15.7 and the dev changes will be lost.  Until then, I think
>>>>> the
>>>>> current release isn't perfect, but certainly something that can be
>>>>> used (and is used) without significant problems.
>>>>>
>>>>> Cheers,
>>>>> Edi.
>>>>>
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>
>>
>>
>> -- 
>> It does not matter how fast your code is, if it does not work!
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

----
Bob Hutchison
Recursive Design Inc.
http://www.recursive.ca/
weblog: http://www.recursive.ca/hutch






From whalliburton at gmail.com  Fri Jan 30 06:06:05 2009
From: whalliburton at gmail.com (William Halliburton)
Date: Fri, 30 Jan 2009 01:06:05 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
	<C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
Message-ID: <4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>

Yes! That the idea. Not to actually take any control away from the
maintainers but to open up the field to branching and experimental work,
while giving the maintainers the ability to easily cherry pick the desirable
branches.

To me, that's *the* main difference in distributed rcs, you *pull* from
other people, not *push* into a central repository.

On Thu, Jan 29, 2009 at 11:22 PM, Bob Hutchison <hutch-lists at recursive.ca>wrote:

> Hi,
>
> On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:
>
> > It would be, but (at the risk of being presumptuous) allowing for easy
> > forks and experimentation is not the goal of the maintainers.
> >
> >
> > I could see that as being the goal of a person that wanted to fork the
> > code and/or experiment.  As Edi said, you have the freedom to fork...,
> > or not.
>
> This 'fork' business when using git seems to be more due to github
> than git, and doesn't normally mean a forked project like, say, the
> Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a
> bunch of tools that allow for core maintainers (e.g. Edi and Hans) to
> keep control of the code base but to have other people contribute
> (without worrying about things like commit privileges, and messed up
> patch files). This made a *huge* difference to the Rails project
> starting last April or so. These two links give more information along
> the lines of that on the page linked to by cmo-0:
>
> <http://github.com/guides/fork-a-project-and-submit-your-modifications>
> <http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch>
>
> And they give you shiny baubles like:
>
> <http://github.com/madrobby/scriptaculous/network>
>
> This is the arbitrarily chosen (near the top of the most-forked list
> with a few forks yet to be pulled) scrit.aculo.us project, 292 forks
> -- but still only one script.aculo.us :-)
>
> I've been using github for my company and my personal work for about
> 10 months now. Works well for me. Big wins:
>
> -- works off line
> -- branching and tagging easy and fast
> -- master branch can be 'rebased' into the branches, and the branches
> commited as though a single commit (you can, if you want, lose all
> those micro commits and sub-branches -- if you look at the github
> network/fork graph, each of the forks can be reduced into a single
> 'dot' on the master branch, or not).
> -- commits are orders of magnitude faster than SVN, at least for me.
>
> I think git might make things easier for Edi and Hans at the cost of
> having to learn it. More importantly, things like Volkan's patch might
> be better tested or improved by having people contribute to the fork
> rather than the master branch. Keep this kind of thing out of their
> hair until it's more ready.
>
> Cheers,
> Bob
>
> >
> >
> > Chris.
> >
> > On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
> >
> >>> What is the plan for the git repository?  Why is it needed, what
> >>> makes
> >>> it useful?
> >>
> >> i find the following feature helpful (YMMV)
> >>
> >> http://github.com/guides/pull-requests
> >>
> >> it will be a helpful tool of using git to allow for easy forks and
> >> experimentation and easy cherry pick any changes made by other forks.
> >>
> >> cmo-0
> >>
> >> On Thu, Jan 29, 2009 at 11:27 PM, Hans H?bner
> >> <hans.huebner at gmail.com> wrote:
> >>> Hi,
> >>>
> >>> bknr.net was temporarily down due to a power failure at the data
> >>> center.  The machine is back up now.
> >>>
> >> I'm aware of the "centralized maintenance" "problem" of
> >>> Subversion, but as Hunchentoot is not going to convert into a
> >>> community project (i.e. we'll review all patches that we accept into
> >>> the repository that eventually becomes the release), I'm not sure
> >>> how
> >>> another level of indirection helps.  It may be possible to convince
> >>> us
> >>> to switch to git if there is a good reason to do so, but that'd need
> >>> some explanation.
> >>>
> >>> -Hans
> >>>
> >>> On Thu, Jan 29, 2009 at 18:28, William Halliburton
> >>> <whalliburton at gmail.com> wrote:
> >>>> Hello everyone...
> >>>>
> >>>> I would like to volunteer any amount of time needed to get Hans's
> >>>> changes
> >>>> folded into the main repository and/or get the development version
> >>>> moving
> >>>> forward and more accessible. I am working on a startup that is
> >>>> currently
> >>>> using hunchentoot and, as chance may have it, I am right about now
> >>>> going to
> >>>> be digging into hunchentoot and friends as part of a performance
> >>>> and
> >>>> understanding push.
> >>>>
> >>>> Currently the BKNR repository is down, but once it gets back up I
> >>>> would like
> >>>> to set up a git repository of flexi-streams, hunchentoot, chunga,
> >>>> and drakma
> >>>> and I invite anyone that wishes to help contribute to this effort.
> >>>>
> >>>> I am most interested in figuring out and testing the performance
> >>>> characteristics of the libraries with respects to threading/non-
> >>>> threading,
> >>>> select/epoll, and proxy/no-proxy on SBCL and am most willing to
> >>>> put in the
> >>>> time and effort to develop and test these different scenarios.
> >>>>
> >>>> Thanks to everyone.
> >>>>
> >>>> Peace,
> >>>> Will
> >>>>
> >>>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi at agharta.de> wrote:
> >>>>>
> >>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at ttmail.com
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Thanks Hans Huebner for his kindly helps and Edi Weitz for his
> >>>>>> uninterest in any effort.
> >>>>>
> >>>>> Volkan,
> >>>>>
> >>>>> If you think you're somehow entitled to an immediate reply or any
> >>>>> action from me just because you sent a patch that is "not well
> >>>>> tested"
> >>>>> and "doesn't include any documentation", you're obviously living
> >>>>> on a
> >>>>> different planet or at least you don't know what it means to
> >>>>> have a
> >>>>> job and a family in addition to taking care of more than a dozen
> >>>>> open
> >>>>> source libraries in your spare time.  I might look at these
> >>>>> patches if
> >>>>> and when I find the time to work on Hunchentoot again or I might
> >>>>> not.
> >>>>> If that's not acceptable to you, the license on all of my libs
> >>>>> always
> >>>>> allows you to fork them and basically do with them whatever you
> >>>>> want.
> >>>>>
> >>>>> For those of you who wonder why Hunchentoot and some other
> >>>>> libraries
> >>>>> have been in limbo for quite some time now, here's a quick
> >>>>> explanation: A company paid Hans to make a couple of additions to
> >>>>> Hunchentoot which are now in the bknr.net repository.  I also
> >>>>> worked
> >>>>> on this a bit in my spare time and added some code, mainly for
> >>>>> performance improvements.  The good thing is that due to Hans'
> >>>>> work
> >>>>> the development version is much improved in several aspects over
> >>>>> the
> >>>>> current release.  The bad thing is that due to Hans' and my
> >>>>> changes
> >>>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
> >>>>> released together, because they are mutually incompatible with the
> >>>>> released versions.  And, for them to become acceptable (for me)
> >>>>> release versions, there's a certain amount of clean-up and
> >>>>> documentation needed that still has to be done.
> >>>>>
> >>>>> Now, the deal with the afore-mentioned company was that they
> >>>>> would pay
> >>>>> Hans and me to do this clean-up and integration work so that we
> >>>>> once
> >>>>> again have "official" release versions that are feature-wise in
> >>>>> sync
> >>>>> with the current dev versions.  This hasn't happened so far, and
> >>>>> right
> >>>>> now I fail to see why I should spend a significant amount of my
> >>>>> spare
> >>>>> time to do this clean-up work when I have more interesting things
> >>>>> to
> >>>>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
> >>>>> maybe there'll at some point just be another Hunchentoot release
> >>>>> based
> >>>>> on 0.15.7 and the dev changes will be lost.  Until then, I think
> >>>>> the
> >>>>> current release isn't perfect, but certainly something that can be
> >>>>> used (and is used) without significant problems.
> >>>>>
> >>>>> Cheers,
> >>>>> Edi.
> >>>>>
> >>>>> _______________________________________________
> >>>>> tbnl-devel site list
> >>>>> tbnl-devel at common-lisp.net
> >>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> tbnl-devel site list
> >>>> tbnl-devel at common-lisp.net
> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>>>
> >>>
> >>> _______________________________________________
> >>> tbnl-devel site list
> >>> tbnl-devel at common-lisp.net
> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>>
> >>
> >>
> >>
> >> --
> >> It does not matter how fast your code is, if it does not work!
> >>
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> ----
> Bob Hutchison
> Recursive Design Inc.
> http://www.recursive.ca/
> weblog: http://www.recursive.ca/hutch
>
>
>
>
> _______________________________________________
> 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/20090130/884d7045/attachment.html>

From hans.huebner at gmail.com  Fri Jan 30 07:49:30 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 30 Jan 2009 08:49:30 +0100
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
	<C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
	<4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>
Message-ID: <fd2982320901292349q4dabde8t5668d31109f908cc@mail.gmail.com>

On Fri, Jan 30, 2009 at 07:06, William Halliburton
<whalliburton at gmail.com> wrote:
> Yes! That the idea. Not to actually take any control away from the
> maintainers but to open up the field to branching and experimental work,
> while giving the maintainers the ability to easily cherry pick the desirable
> branches.
>
> To me, that's *the* main difference in distributed rcs, you *pull* from
> other people, not *push* into a central repository.

Right.  Huchentoot (and Edi's libraries in general) follow a "push"
development model, so a distributed rcs does not help.  You can
certainly create a fork that is using a different development model.

I'm a bit unsure that we're solving any problem with this discussion.
As far as I can see, the current model does work.  I would thus
propose that we stick with it, as it guarantees a certain level of
quality, documentation and bug fix throughput.  Instead of discussing
revision control systems, we should be discussing changes to
Hunchentoot, and those are certainly not dependent on the version
control system that is used.

As a start, someone could revise Volcan's patch, or come up with a
proposal for event oriented processing or thread pools.

If we, at a later time, detect that Edi and I cannot handle the patch
volume pushed to us, we can still reconsider.

-Hans



From xach at xach.com  Fri Jan 30 09:39:52 2009
From: xach at xach.com (Zach Beane)
Date: Fri, 30 Jan 2009 04:39:52 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <fd2982320901292349q4dabde8t5668d31109f908cc@mail.gmail.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
	<C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
	<4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>
	<fd2982320901292349q4dabde8t5668d31109f908cc@mail.gmail.com>
Message-ID: <20090130093952.GN18525@xach.com>

On Fri, Jan 30, 2009 at 08:49:30AM +0100, Hans H?bner wrote:

> I'm a bit unsure that we're solving any problem with this discussion.
> As far as I can see, the current model does work.  I would thus
> propose that we stick with it, as it guarantees a certain level of
> quality, documentation and bug fix throughput. 

On frustrating aspect of the current state of development is that
minor fixes to seemingly unrelated libraries do not get applied or
rejected, but hang in limbo. (Why should Hunchentoot hold up Drakma
changes?)

Zach



From hans.huebner at gmail.com  Fri Jan 30 10:54:52 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 30 Jan 2009 11:54:52 +0100
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <20090130093952.GN18525@xach.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
	<C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
	<4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>
	<fd2982320901292349q4dabde8t5668d31109f908cc@mail.gmail.com>
	<20090130093952.GN18525@xach.com>
Message-ID: <fd2982320901300254v2e2b4067l12e6c1dde46819b3@mail.gmail.com>

On Fri, Jan 30, 2009 at 10:39, Zach Beane <xach at xach.com> wrote:
> On Fri, Jan 30, 2009 at 08:49:30AM +0100, Hans H?bner wrote:
>
>> I'm a bit unsure that we're solving any problem with this discussion.
>> As far as I can see, the current model does work.  I would thus
>> propose that we stick with it, as it guarantees a certain level of
>> quality, documentation and bug fix throughput.
>
> On frustrating aspect of the current state of development is that
> minor fixes to seemingly unrelated libraries do not get applied or
> rejected, but hang in limbo. (Why should Hunchentoot hold up Drakma
> changes?)

I can agree with that, and as Edi described, there is a certain,
singular cause for that, but said company seems to begin to move.  It
is fair to say that Edi has always been very diligent and prompt in
fixing bugs in his libraries as long as he was the only one who had
control over the source code.  What we now need is a workable model to
get the development process to move forward again without sacrificing
the quality of both the source code and the documentation of Edi's
software.  If you want to check out something from a source code
control system and work yourself through tests and sparse examples,
there are other HTTP libraries that one can work with.

-Hans



From edi at agharta.de  Fri Jan 30 15:08:43 2009
From: edi at agharta.de (Edi Weitz)
Date: Fri, 30 Jan 2009 10:08:43 -0500
Subject: [hunchentoot-devel] Maximum Request Size
In-Reply-To: <20090130093952.GN18525@xach.com>
References: <87prigzl0s.fsf@alamut.mobiliz.com.tr>
	<b56421a00901290452j123d6509l34a77eb6839cb9c7@mail.gmail.com>
	<4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com>
	<fd2982320901291127k60296d3es1ad230ada2a34a55@mail.gmail.com>
	<af6a3d2d0901291315r1b754108t4bc5e6aa07e92f0b@mail.gmail.com>
	<6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com>
	<C8920EEB-62CB-4653-B6D1-94ADA46D129E@recursive.ca>
	<4e7bd29e0901292206g7653022dk28444887e7ae757e@mail.gmail.com>
	<fd2982320901292349q4dabde8t5668d31109f908cc@mail.gmail.com>
	<20090130093952.GN18525@xach.com>
Message-ID: <b56421a00901300708y7b2dbd7fw4a5faec72e25fd00@mail.gmail.com>

On Fri, Jan 30, 2009 at 4:39 AM, Zach Beane <xach at xach.com> wrote:

> Why should Hunchentoot hold up Drakma changes?

The dev version of Drakma is different from the release version and it
depends on the dev version of Chunga which is incompatible with the
released versions of Drakma and Hunchentoot.  So, as I said earlier,
all three libraries have to be updated at once.  It is currently
unfortunately not possible to apply "quick fixes" to one of them and I
hate the situation as much as everyone else.

As Hans said, there has been some movement in the last days and we
might see the light at the end of the tunnel soon.



From sky at viridian-project.de  Fri Jan 30 17:04:41 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Fri, 30 Jan 2009 18:04:41 +0100 (CET)
Subject: [hunchentoot-devel] rfc2388: Handling of octets and strings is
 flawed
In-Reply-To: <fd2982320901270446v58c3eb8arca8ce5d49531aa5d@mail.gmail.com>
References: <61089.88.73.219.7.1233058805.squirrel@mail.stardawn.org>
	<fd2982320901270446v58c3eb8arca8ce5d49531aa5d@mail.gmail.com>
Message-ID: <64184.88.73.246.44.1233335081.squirrel@mail.stardawn.org>


> Replacing the rfc2388 system by something that is better has been on
> the "should be done" list for a very long time.  Are you volunteering
> to either repair it or come up with something that is better?

Maybe migrating to CL-MIME would make sense.
I'm going to check this later.





From christoph.senjak at web.de  Fri Jan 30 19:48:53 2009
From: christoph.senjak at web.de (christoph.senjak at web.de)
Date: Fri, 30 Jan 2009 20:48:53 +0100
Subject: [hunchentoot-devel] Is there any implementation of XML-RPC for
	Hunchentoot
In-Reply-To: <24f203480901281653g51eebc8eh7b10a6e65703770b@mail.gmail.com>
References: <9e4493f70901281606t664e8c5sdd22bd9691b9a1f7@mail.gmail.com>
	<24f203480901281653g51eebc8eh7b10a6e65703770b@mail.gmail.com>
Message-ID: <9e4493f70901301148x4ecc28b5v6e8649f32ec19443@mail.gmail.com>

Hello.

2009/1/29 Robert Synnott <rsynnott at gmail.com>:
> 2009/1/29  <christoph.senjak at web.de>:
>> Hello.
>>
>> Again a question. Is there already any Implementation of XML-RPC
>> running on Hunchentoot. I only found S-XML-RPC so far, and it seems
>> like it is using allegro serve. It may not be too hard to implement,
>> but if it is already there, I dont want to do it.
>>
>> Greetings
>> Christoph-Simon Senjak
>>
>
> This might be useful:
> http://boinkor.net/archives/2007/12/cxmlrpc_update_changed_interfa.html

Looks good. Thank you. I will try.

Christoph-Simon Senjak