chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I'm starting using chicken4 (Re: [Chicken-users] 4.6.1 performance b


From: Daishi Kato
Subject: Re: I'm starting using chicken4 (Re: [Chicken-users] 4.6.1 performance boost
Date: Mon, 04 Oct 2010 20:13:35 +0900
User-agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI)

At Fri, 1 Oct 2010 20:10:36 +0200,
Peter Bex wrote:
> 
> On Sat, Oct 02, 2010 at 12:22:22AM +0900, Daishi Kato wrote:
> > > Yes, this is uglier.  There are several different request handling
> > > eggs now though!  They make it easier to handle incoming requests.
> > 
> > Is it that ugly?
> > None of the request handling eggs in the spiffy manual
> > was not so low level.
> 
> I'm confused; do you think the eggs are lower-level than your code, or
> do you think the spiffy code itself is low-level, or what?

OK, I meant:
a) chicken3/http-server was low level so that I can write my handler.
b) chicken3/spiffy was not low level.
c) chicken4/spiffy is low level enough to port my code thanks to vhost support.

> > I don't understand the discussion here. How felix isn't happy?
> 
> He's unhappy that the way to define request handlers has become so
> much more complicated.

I see.

> > I thought the vhost support is very powerful.
> 
> It is, but it comes at the price of not being able to simply define
> request handlers at the global path level, since those would apply
> to all vhosts.

I'm not so motivated since I'm already moved to chicken4,
but I'm happy to contribute to the community, so let me try writing it.

;;;; raw-handler.scm
; handler to emulate chicken3-style request-handler

(define (raw-handler fn)
  (let* ([req (current-request)]
         [m (request-method req)]
         [a (assq m request-method-handlers)])
    ((cdr a) req)))
  ;; how can it handle errors?

(define request-method-handlers '())

(define (http:request-method-handler m . h)
  (let ([a (assq m request-method-handlers)])
    (if (pair? h)
        (if a 
            (set-cdr! a (car h))
            (set! request-method-handlers (alist-cons m (car h) 
request-method-handlers)) )
        (and a (cdr a)) ) ) )


However, this is not compatible with chicken3/http-server,
because of the structure of req, which is port-based instead of string-based.
If it is required, we could make it really compatible.
 
> > > > There were many tiny things for porting my code, such as dealing
> > > > with the fancy uri-common egg and string-match -> string-search.
> > > 
> > > Are you using "fancy" in a good way or in a bad way?  I'm really eager
> > > to hear how these new http libraries are being used and how people like
> > > them, so I can improve where things are not as smooth as they should be.
> > 
> > Good question. I used "fancy" in a good way, but if you ask me:
> > it might be too premitive, or there are too many procedures to understand.
> 
> URI-common exports 30 identifiers, I guess you could call that a lot :)
> However, most of those are simply record accessors and constructors.
> There are a bunch of predicates and conversion procedures which are
> sorely needed.
> 
> If you have more specific questions about the various procedures, feel
> free to ask them.  Maybe you can help me out improving the documentation,
> to make it easier for other people and ensure they won't run into the
> same problems you have.

How about splitting lower-level procedures and higher-level procedures?
I also don't understand why there are uri-generic and uri-common.
Can it be just like uri-generic provides the structure,
and uri-common provides processing procedures?

> > My code was (since it was from chicken3) based on the string-based
> > representation of URLs, hence I made some util functions as follows:
> > 
> > (define (get-path-from-uri uri)
> >   (define len (- (string-length prefix) 1))
> >   (let ([path (string-intersperse (cdr (uri-path uri)) "/")])
> >     (and path
> >          (string-prefix? prefix path)
> >          (string-drop path len))))
> 
> What's "prefix" here?  It seems like an undefined variable.

It's something I use for my project, i.e. (define prefix "waitless/")

> If it's some directory which you want to strip from the path, you
> can use matchable (or do manual cons/car/cdring):
> 
> (match (uri-path uri)
>   (('/ "my" "prefix" . rest) (string-intersperse rest "/")) ;; Remove 
> /my/prefix
>   (else #f))

Oh, I've never used matchable. let me try.

> You can also construct the base URI and generate a relative reference
> using uri-relative-from, but then you have to be careful when the string
> is not a proper prefix (which you can verify by checking the first
> element for not being '/ or "..").
> 
> > (define (get-ref-url-from uri)
> >   (let ([baseuri (uri-reference (sprintf "~a://~a:~a/" (uri-scheme uri) 
> > (uri-host uri) (uri-port uri)))])
> >     (uri->string (uri-relative-from uri baseuri))))
> 
> I'm not sure what the purpose of this one is, but you could do it
> with either

I'm creating 302 response without specifying the host.

>   (uri->string (update-uri uri scheme: #f host: #f))
> 
> or
> 
>   (uri->string
>     (uri-relative-from uri (update-uri uri path: #f query: #f fragment: #f)))

how nice.

> I think it would make more sense to take a look at your code and see
> why you need to do this.  It rarely makes sense to convert an absolute
> URI to a relative one like this, I think.

Maybe you are right. All the reason is that my code was
written for chicken3 and url/uri/path are all string-based.

> > (define (get-query-from-uri uri)
> >   (let ([query (uri-query uri)])
> >     (and (pair? query)
> >          (map (lambda (x) (cons (symbol->string (car x)) (cdr x)))
> >               query))))
> 
> Things like this can be done easily by creating an "empty" uri reference
> and copying over those things you need:
> 
> (uri->string (update-uri (uri-reference "") query: (uri-query uri)))

wow. I wish you include those examples in the doc.

> > Please let me know if there's a better way of doing it.
> 
> I hope you like these examples.  If I missed something or if there's
> a cleaner way to do one of these, I'm sure people will correct me :)

I liked them pretty much. I would use (or might be start using)
them when I redesign my code. Thanks a lot.

Best,
Daishi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]