<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.lisp.web">
    <title>gmane.lisp.web</title>
    <link>http://blog.gmane.org/gmane.lisp.web</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/979"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/969"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/968"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/966"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/965"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/964"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/957"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/947"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/947"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/943"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/943"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/941"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/941"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/930"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/930"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/926"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/926"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/924"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/924"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.web/922"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/979">
    <title>The Common Lisp Directory finally crashed after 823 days.</title>
    <link>http://comments.gmane.org/gmane.lisp.web/979</link>
    <description>[Is this list still somewhat alive?]

The Common Lisp Directory (http://www.cl-user.net) lisp process crashed
yesterday after 823 days of continuous service.
 
In these 2 years and 93 days, the same lisp process (LispWorks on Linux
Debian) served 273M requests without any problem. Even the crash was not
really lisp's fault as it was caused by a swap disk problem which caused
the kernel to kill a lot of processes.
 
During these 823 days, I had to restart Apache every few months and the
firewall router every several days. I also got several electric power
outages but fortunately none longer than the 3h of UPS battery time.
BTW this shows than Debian is also a stable platform for this kind of
applications.
 
So the CLD lisp process uptime experiment is now over and I will move
the CLD to a better place than a simple server in my basement.
 
Marc
</description>
    <dc:creator>Marc Battyani</dc:creator>
    <dc:date>2008-03-15T17:05:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/969">
    <title>serving very large files from allegroserve</title>
    <link>http://comments.gmane.org/gmane.lisp.web/969</link>
    <description>Testing downloads of large audio recordings from ilc2007, I find that
the bytes stop flowing after five minutes. Allegroserve (version
1.2.43 on ACL 8.0) spits out a 500 return code and the transaction is
over.

I find in AServe doc the following:

    (wserver-response-timeout wserver) - the number of seconds
    AllegroServe allows for an http request function to be run and
    finished sending back its response. The initial value for this
    slot of the wserver object is found in *http-response-timeout*
    which defaults to 300 seconds. You can alter this timeout value
    with the :timeout argument to with-http-response or by specifying
    a :timeout argument to the publish function creating the entity.

and I'm sure this is exactly what I've hit. 

The thought of just cranking this number up and hoping for the best
makes me cringe a little. Surely there must be better? Well, the folks
at Franz obviously thought so too, because a couple of paragraphs up
they say:

    In Acl 6.1 we added the capability of having each I/O operation to
    a socket stream time out.  This means that we don't have to
    predict how long it should take to get a request or send a
    response.  As long as we're making progress reading or writing we
    know that the client on the other end of the network connection is
    alive and well.

Fine words. But totally contradicted by having a response-timeout slot
in the server.

Does anyone have any experience with getting AServe to monitor whether
it's "making progress reading" and so knows "that the client on the
other end of the network connection is alive and well"?

Thanks,

- nick
</description>
    <dc:creator>Nick Levine</dc:creator>
    <dc:date>2007-05-03T09:00:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/968">
    <title>Announcement: CL-WEBDAV</title>
    <link>http://comments.gmane.org/gmane.lisp.web/968</link>
    <description>A WebDAV server based on Hunchentoot:

  http://weitz.de/cl-webdav/

Cheers,
Edi.
</description>
    <dc:creator>Edi Weitz</dc:creator>
    <dc:date>2007-04-18T20:14:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/966">
    <title>web development with lisp</title>
    <link>http://comments.gmane.org/gmane.lisp.web/966</link>
    <description>Hey this is Patrick, from Pippen Enterprises LLC.
Our company is starting up a web development company, using Common Lisp
of course :-)

We wondering what tools do many lisp developers, use that support
Versign SSL, and other
technologies for commercial use.

</description>
    <dc:creator>Patrick X</dc:creator>
    <dc:date>2007-03-16T04:46:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/965">
    <title>Araneida: request-authorized-p (implementation of genericfunctionto yield authorization status)</title>
    <link>http://comments.gmane.org/gmane.lisp.web/965</link>
    <description>Hi,

I'm trying to create an authorization scheme in Araneida. Basically
whenever a location in my URL space is called I want to check whether
the user is authorized and redirect to a login page if he isn't.

I found this post on usenet:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a6990567666934d2/12bca167849b64e9?lnk=gst&amp;q=request-authorized-p&amp;rnum=1&amp;hl=en&amp;fwc=2

According to this post, the generic function "request-authorized-p" is
called for every request to determine whether a client is authorized.

To test this, I've got:

============= snip ==================
(defclass root-page-handler (araneida:handler) ())

(defmethod request-authorized-p ((araneida:handler root-page-handler)
method request)
  (format t "not authorized"))

(defmethod request-not-authorized ((araneida:handler root-page-handler)
method request)
  (araneida:request-redirect request
     *login-urlstring*))

(defmethod handle-request-response ((araneida:handler root-page-handler)
method request)
  (araneida:request-send-headers request)
  (araneida:html-stream
   (araneida:request-stream request)
   `(html (body (p "logged in")))))


(defparameter *root-page-handler-instance*
  (make-instance 'root-page-handler))

(araneida:install-handler 
 (http-listener-handler *listener*)
 *root-page-handler-instance*
 *app-urlstring* t)
============= snip ==================


So, I've got request-authorized-p on class root-page-handler. However, I
find that this method is never called by Araneida; instead,
handle-request-response is still called.

What gives? What am I missing?

Joubert
</description>
    <dc:creator>Joubert Nel</dc:creator>
    <dc:date>2007-03-06T03:53:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/964">
    <title>problems installing lisp on xen vps on amd64 machine</title>
    <link>http://comments.gmane.org/gmane.lisp.web/964</link>
    <description>_______________________________________________
lispweb mailing list
lispweb&lt; at &gt;red-bean.com
http://www.red-bean.com/mailman/listinfo/lispweb
</description>
    <dc:creator>Naveen Garg</dc:creator>
    <dc:date>2007-02-25T07:55:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/957">
    <title>[ANN] cl-migrations 0.0.1</title>
    <link>http://comments.gmane.org/gmane.lisp.web/957</link>
    <description>Hi all,

I would like to announce the availability of cl-migrations, a port of
the migrations feature of Ruby on Rails to Common Lisp. cl-migrations is
a simple tool to manage your changes to a database as you develop your
web application or any database-backed application.

It works by generating a new file to for each database change, which
contains the DDL required to enable and disable that change. So,
effectively you can version-control your entire database structure.

You can install this tool with asdf:

(asdf-install:install :cl-migrations)

This tool depends on clsql, so you can run migrations on any database
that is supported by clsql. Many thanks to Kevin Rosenberg for
maintaining such a useful library.

For more info, please go to this page:

http://common-lisp.net/project/cl-migrations/

Kindly raise any questions/feature requests/bug-reports here:

http://common-lisp.net/cgi-bin/mailman/listinfo/cl-migrations-devel


Regards,
Vamsee Kanakala.
</description>
    <dc:creator>Vamsee Kanakala</dc:creator>
    <dc:date>2006-11-12T03:43:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/947">
    <title>Hello</title>
    <link>http://comments.gmane.org/gmane.lisp.web/947</link>
    <description>_______________________________________________
lispweb mailing list
lispweb&lt; at &gt;red-bean.com
http://www.red-bean.com/mailman/listinfo/lispweb
</description>
    <dc:creator>George Erick Tasso</dc:creator>
    <dc:date>2006-10-23T00:05:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/947">
    <title>Hello</title>
    <link>http://comments.gmane.org/gmane.lisp.web/947</link>
    <description>_______________________________________________
lispweb mailing list
lispweb&lt; at &gt;red-bean.com
http://www.red-bean.com/mailman/listinfo/lispweb
</description>
    <dc:creator>George Erick Tasso</dc:creator>
    <dc:date>2006-10-23T00:05:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/943">
    <title>How does reverse proxy helps araneida?</title>
    <link>http://comments.gmane.org/gmane.lisp.web/943</link>
    <description>I do not understand. "Araneida ... designed to sit behind proxying Apache
... ".
What for? How does Apache helps (without regard for https)?

Explain it me, someone, please.

Regards,
-Anton
</description>
    <dc:creator>Anton Vodonosov</dc:creator>
    <dc:date>2006-10-20T23:57:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/943">
    <title>How does reverse proxy helps araneida?</title>
    <link>http://comments.gmane.org/gmane.lisp.web/943</link>
    <description>I do not understand. "Araneida ... designed to sit behind proxying Apache
... ".
What for? How does Apache helps (without regard for https)?

Explain it me, someone, please.

Regards,
-Anton
</description>
    <dc:creator>Anton Vodonosov</dc:creator>
    <dc:date>2006-10-20T23:57:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/941">
    <title>Redirects and caching</title>
    <link>http://comments.gmane.org/gmane.lisp.web/941</link>
    <description>
Suppose you have a page that requires cookie-based authentication, and that
redirects when that cookie is not found.  How do you make sure neither page is
incorrectly cached?

Right now, I am able to access a cached page after the cookie has been
removed.  Worse, after accessing a protected page, being redirected, then
logging in and going *back* to that page, I am still getting the redirect.

Is there a way around this?  I have "no-store, no-cache" in the cache-control
headers.

Jonathon McKitrick
--
My other computer is your Windows box.
</description>
    <dc:creator>Jonathon McKitrick</dc:creator>
    <dc:date>2006-10-20T01:16:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/941">
    <title>Redirects and caching</title>
    <link>http://comments.gmane.org/gmane.lisp.web/941</link>
    <description>
Suppose you have a page that requires cookie-based authentication, and that
redirects when that cookie is not found.  How do you make sure neither page is
incorrectly cached?

Right now, I am able to access a cached page after the cookie has been
removed.  Worse, after accessing a protected page, being redirected, then
logging in and going *back* to that page, I am still getting the redirect.

Is there a way around this?  I have "no-store, no-cache" in the cache-control
headers.

Jonathon McKitrick
--
My other computer is your Windows box.
</description>
    <dc:creator>Jonathon McKitrick</dc:creator>
    <dc:date>2006-10-20T01:16:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/930">
    <title>Unclosed file descriptors</title>
    <link>http://comments.gmane.org/gmane.lisp.web/930</link>
    <description>
Is it any reason to worry about 'unable to close fd 6' and 'trying harder'?

Jonathon McKitrick
--
My other computer is your Windows box.
</description>
    <dc:creator>Jonathon McKitrick</dc:creator>
    <dc:date>2006-10-11T16:50:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/930">
    <title>Unclosed file descriptors</title>
    <link>http://comments.gmane.org/gmane.lisp.web/930</link>
    <description>
Is it any reason to worry about 'unable to close fd 6' and 'trying harder'?

Jonathon McKitrick
--
My other computer is your Windows box.
</description>
    <dc:creator>Jonathon McKitrick</dc:creator>
    <dc:date>2006-10-11T16:50:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/926">
    <title>extending Allegroserve time-out period</title>
    <link>http://comments.gmane.org/gmane.lisp.web/926</link>
    <description>    I've got a slow back end executable
producing new files that I need to serve,  and it takes
about 20 to 45 seconds for it to complete.
Meanwhile,  my PortableAserve
thread times out and I get a
NET.ASERVE::STREAM-ERROR-IDENTIFIER
error in the aserve-worker thread.

   Is there a way to extend the
time-out period to 45 seconds?
I'm using PortableAserve on Lispworks.

Lawrence Au
Q-Phrase LLC
</description>
    <dc:creator>Lawrence Au</dc:creator>
    <dc:date>2006-10-10T23:23:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/926">
    <title>extending Allegroserve time-out period</title>
    <link>http://comments.gmane.org/gmane.lisp.web/926</link>
    <description>    I've got a slow back end executable
producing new files that I need to serve,  and it takes
about 20 to 45 seconds for it to complete.
Meanwhile,  my PortableAserve
thread times out and I get a
NET.ASERVE::STREAM-ERROR-IDENTIFIER
error in the aserve-worker thread.

   Is there a way to extend the
time-out period to 45 seconds?
I'm using PortableAserve on Lispworks.

Lawrence Au
Q-Phrase LLC
</description>
    <dc:creator>Lawrence Au</dc:creator>
    <dc:date>2006-10-10T23:23:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/924">
    <title>Announcement: Drakma</title>
    <link>http://comments.gmane.org/gmane.lisp.web/924</link>
    <description>While I'm at it, I should probably also mention Drakma which I think I
haven't announced on this list yet.  Drakma is a fully-featured web
client (implemented in Common Lisp, obviously) that knows how to
handle HTTP/1.1 chunking, persistent connections, re-usable sockets,
SSL, continuable uploads, file uploads, cookies, and other things.

It is known to work with LispWorks, AllegroCL, CMUCL, SBCL, and
OpenMCL.  I /think/ it will also work with CLISP and ABCL, but I
haven't tested.

More info here:

  http://weitz.de/drakma/

OK, enough advertising for tonight - back to our regular scheduled
program...
</description>
    <dc:creator>Edi Weitz</dc:creator>
    <dc:date>2006-10-10T19:53:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/924">
    <title>Announcement: Drakma</title>
    <link>http://comments.gmane.org/gmane.lisp.web/924</link>
    <description>While I'm at it, I should probably also mention Drakma which I think I
haven't announced on this list yet.  Drakma is a fully-featured web
client (implemented in Common Lisp, obviously) that knows how to
handle HTTP/1.1 chunking, persistent connections, re-usable sockets,
SSL, continuable uploads, file uploads, cookies, and other things.

It is known to work with LispWorks, AllegroCL, CMUCL, SBCL, and
OpenMCL.  I /think/ it will also work with CLISP and ABCL, but I
haven't tested.

More info here:

  http://weitz.de/drakma/

OK, enough advertising for tonight - back to our regular scheduled
program...
</description>
    <dc:creator>Edi Weitz</dc:creator>
    <dc:date>2006-10-10T19:53:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/922">
    <title>Announcement: Hunchentoot</title>
    <link>http://comments.gmane.org/gmane.lisp.web/922</link>
    <description>Hi!

I'd like to announce that Hunchentoot has now been ported to SBCL,
CMUCL, AllegroCL, and OpenMCL.  Hunchentoot is a fully-featured web
server written in Common Lisp which can be operated stand-alone but
also as a back-end for mod_lisp.  Hunchentoot was previously only
available for LispWorks, as a wrapper around TBNL.  The latest version
doesn't depend on TBNL anymore and is intended to replace it.

More information about Hunchentoot is here:

  http://weitz.de/hunchentoot/

Cheers,
Edi.
</description>
    <dc:creator>Edi Weitz</dc:creator>
    <dc:date>2006-10-10T19:16:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.web/922">
    <title>Announcement: Hunchentoot</title>
    <link>http://comments.gmane.org/gmane.lisp.web/922</link>
    <description>Hi!

I'd like to announce that Hunchentoot has now been ported to SBCL,
CMUCL, AllegroCL, and OpenMCL.  Hunchentoot is a fully-featured web
server written in Common Lisp which can be operated stand-alone but
also as a back-end for mod_lisp.  Hunchentoot was previously only
available for LispWorks, as a wrapper around TBNL.  The latest version
doesn't depend on TBNL anymore and is intended to replace it.

More information about Hunchentoot is here:

  http://weitz.de/hunchentoot/

Cheers,
Edi.
</description>
    <dc:creator>Edi Weitz</dc:creator>
    <dc:date>2006-10-10T19:16:59</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.lisp.web">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.web</link>
  </textinput>
</rdf:RDF>
