[Nitro] New Nitro dispatcher proposal

George Moschovitis george.moschovitis at gmail.com
Mon Jan 22 09:01:05 EST 2007


Jonathan, thanks for the interesting remarks. Seems to me I have to get back
to the design board and think a bit about your points. In the meantime,
perhaps we will get some more suggestions.

-g.

On 1/22/07, Jonathan Buch <john at oxyliquit.de> wrote:
>
> 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
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070122/82fc1272/attachment.html 


More information about the Nitro-general mailing list