On Wed, 28 Nov 2001, Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
> > > Gosh, I had the *exact* same feeling that we need something in between
> > > star-matching and regexp-mathing.
> >
> > That's my point. In fact, it would be Really cool if this hybrid matcher was a
>wrapper
> > around the RegExp matcher, and merely did a translation on the pattern!
>
> It should be fairly trivial once you know regexp (and I don't!)
>
> > > I already proposed it and it got rejected, I'd be all for it!!!
> >
> > No-one said we can't implement a third matcher. It would be worth
>investigating--then
> > we have the advantage of seeing which is most useful by natural selection
>(following
> > Darwinian theory, which doesn't always apply to every situation...).
>
> yep
>
> > What did you think about being able to *explicitly* raise an error from the
>sitemap?
>
> Uh, I probably missed that. What do you mean?
>
> [snip]
>
> > > <map:match patter="**/images/*.{gif|jpeg|png}">
> > > <map:read src="images/{2}.{3}" mime-type="image/{3}"/>
> > > </map:match>
> > >
> > > since nobody forces you to use three-letters extensions for your URIs :)
> >
> > True--though it is a common convention.
>
> so? did you ever had to try to guess an image URI by hand? would anybody
> be able to notice that change from a normal browsing experience?
>
> > Note: Giacomo mentioned that the Readers and Serializers are supposed to rely
> > on the environment's Mime Mapping to handle the cases where it is not
> > declared either in the component section or the pipeline section.
>
> yes
>
> > >>Of course, then I would want to go a step further and explicitly state my
>mime-type
> > >>first in the select statement and only have one read.
> > >>
> > >><map:mime-type value="image/jpeg"/>
> > >><map:read/>
> > >>
> > >>Although, we can apply separation of concerns again. In other words, mime-type
>matching
> > >>is not always a concern of the sitemap. URIs with standard extensions should
>not need
> > >>to have the mime-type matched by the sitemap. IOW, standard extensions such as
>".pdf",
> > >>".jpg", ".gif", ".png", ".rtf", etc. should have a table that automatically gets
>looked
> > >>up and applied to the response. This can be be a mimetypes file that can either
>be a
> > >>simple properties file (there are only a flat hierarchy to mime-type resolution)
>or a
> > >>simplified configuration file:
> > >>
> > >><mime:entry extension="pdf" type="application/pdf"/>
> > >>
> > >>Of course It can be grouped for maintenance purposes like this:
> > >>
> > >><mime:table group="application">
> > >><mime:entry extension="pdf" type="pdf"/>
> > >></mime:table>
> > >><mime:table group="image">
> > >><mime:entry extension="jpg" type="jpeg"/>
> > >><mime:entry extension="gif" type="gif"/>
> > >></mime:table>
> > >>
> > >>The table approach can be further shortened by removing the "type" attribute if
>it is the
> > >>same as the extension. Keep in mind that command line environments and other
>yet-to-be
> > >>created environments won't have the same mechanisms for mime-type resolution,
>and it should
> > >>be easy to create a general component that performs the resolution for you.
>This way 90%
> > >>of all mime-type declarations can be resolved in a maintainable and uniform
>manner.
> > >>
> > >>The only need for the mime-type would be when your URI does not have an
>extension, or it is
> > >>non-standard.
> > >>
> > >
> > > I thought this was already implemented? isn't it?
> >
> > This is only implemented for the servlet environment. There is no way to have a
>standard suite
> > of mime-mappings independently of the environment. IOW, the Servlet environment
>has it's way,
> > the CLI environment has another way (or ignores it), a Block embedded Cocoon would
>have yet
> > another way.
> >
> > Do you see the conundrum?
>
> Yep. So, do you propose to have a mime-mapper Avalon component?
>
> [note that the Cocoon CLI already performs the reverse mapping between
> mime/type and extension, so we need a component that is able to obtain
> an extension for a mime type and a mime type from an extension]
Good point. This in fact would solve it for all environments as well as
for other Blocks or Composers (Avalon speaking) being able to use such a
Component.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
