[Nitro] New Nitro dispatcher proposal

Jonathan Buch john at oxyliquit.de
Mon Jan 22 07:48:50 EST 2007


On Mon, 22 Jan 2007 11:39:21 +0100, George Moschovitis <george.moschovitis at gmail.com> wrote:

>>
>> This is only true with Webrick (as far as I skimmed the code).
>
>
> no, it  works for mongrel and fastcgi too.
>
>> I propose the following change:
>> >
>> > If the uri contains no extension automatically add the .html extension
>> > Does the file pointed to by the uri exist?
>> >   - yes ? -> the request is handled by the front web server
>> >   - no? -> the request is handled by Nitro (append x at the end of the
>> > extension)
>>
>> I would rewrite that to:
>>
>> - Does the file to uri exist?
>>    - yes : handled by webserver
>>    - no : handled by nitro
>> - append .html to uri
>>    Does the file to uri exist?
>>    - yes : handled by webserver

> you can't go back to the web server.

This is correct, but you snipped the last two lines, in the lines above my
example didn't do anything yet, it just set a few variables.

>    - no : handled by nitro, remove .html
>> - handle(webserver | nitro) according to above

> you have to pre-apply the html extension. I want the webserver to check for
> the (potentially cached) version first and only then proxy to nitro.

What about moving mine around?

>> - Does the file to uri + '.html' exist?
>>    - yes : handled by webserver
>>    - no : next
>> - Does the file to uri exist?
>>    - yes : handled by webserver
>>    - no : handled by nitro


>> The 'always append .html' because we can't reliably check what is a file-
>> extension and what is not, it just doesn't work out in all cases.
> I can't see the problem.

What about:

/tags/nitro/0.40.0
/tags/.jpg
/pictures/new.png

How do you know that those are actual extensions?  Or not?

Regular expressions wouldn't be enough (you can't check for thousands of
recognized file extensions), there would have to be extra logic if the uri
actually could be a filename.  There are filenames without extensions, those
gotta be served as well.

/\.\w{1,10}$/

As an example for such a regex, if it would match, there would be something
looking like an extension.  But it is also unreliable for reasons above.

> index.htmlx -> index__html == index
> screen.cssx -> screen__css

Alright, this would solely operate on file extensions.

>> Isn't __ right now used for / ?  How would you 'choose' between those
>> modes?
>
> hmm you are right here, we have to find another way to encode this. In fact
> there is a better solution
> (what Rails does btw): pass the extension as a content type, ie both
> trigger the same action (my_action)  but nitro setups a special content_type
> parameter.

I looked up how Rails does this:
http://weblog.rubyonrails.org/2006/11/26/1-2-new-in-actionpack

That together with the 'cheat sheet' describes it quite nicely....

I prefer your idea with normal switch/case instead of that extra DSL rails
is doing there.  And passing the content-type directly to the action...
I don't know, I like the content_type param better.

Nitro::Mime::Type.register("image/jpeg", :jpg, :jpeg)

Something like that perhaps...

Or to be consistent with current Configuration approach:

Nitro::Mime.types.update("image/jpeg" => [:jpg, :jpeg])

Or Controller specific:

MyController.mime_types

>> What would happen with types Nitro doesn't recognize as 'templateable'?
>> Like '.jpg' (maybe dynamic captcha images)?
>
> dynamic.jpg -> dynamic.jpgx -> dynamic(content = jpg)

So it would just  dynamic.jpg => dynamic__jpg (or `dynamic` (type jpg))

>> Would this 'x' appending simplify nitro internal code or would it add
>> another layer of indirection?
> the x just denotes a template, ie:

When using the rails-like approach the x wouldn't be neccessary, right?

I would love to think more about this, but exams being so close now, this
would quite hurt me.  ;/

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png


More information about the Nitro-general mailing list