Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 83150 invoked by uid 500); 28 Nov 2001 13:58:43 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 83127 invoked from network); 28 Nov 2001 13:58:43 -0000 Message-ID: <3C04EDF7.7080406@apache.org> Date: Wed, 28 Nov 2001 09:00:23 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Negative Matching Constructs && Mime Type Matching References: <3C03BB17.3090204@apache.org> <3C03EB05.692AA996@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > Berin Loritsch wrote: > >>While using Cocoon to generate the developer's docs, I have discovered some use >>cases where a more flexible matcher should be considered. First, let me outline >>how it works (now that we can follow links....): >> >> >> >> >> >>The Aggregate matching would change the way patterns are expressed. I know we have >>a RegExp matcher--which is great, but sometimes we want something more familiar: >> >> >> >> >> > > 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! > 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...). What did you think about being able to *explicitly* raise an error from the sitemap? Sometimes the implied error thing is a pain to deal with. This is especially true if you want fine control over your URI space and it is either impossible to exclude a range using RegExp, or the resulting match pattern is too complex for any mortal to understand. The errors I would explicitly like to raise are the 400 series errors: 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed (Although I am not sure that I know how to enforce this at the sitemap level). 406 Not Acceptable (I have to examine what this is for again--I am going through the HTTP spec contents...) 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required (disallow chunking on SOAP requests or uploads....) 412 Precondition Failed 413 Request Entity Too Large 414 Request URI Too Long 415 Unsupported Media Type 416 Request Range Not Satisfiable 417 Expectation Failed And possible the 500 series errors: 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported >>This also opens the door for something equally powerful on the positive matching side: >> >> >> >> >> >> >> >> >> >> >> >> >> > > or even > > > > > > since nobody forces you to use three-letters extensions for your URIs :) True--though it is a common convention. 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. >>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. >> >> >> >> >>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: >> >> >> >>Of course It can be grouped for maintenance purposes like this: >> >> >> >> >> >> >> >> >> >>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? -- "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org