Serge Knystautas wrote:
>
> Stefano Mazzocchi wrote:
> > Unfortunately not (yet!).
> >
> > The Sitemap idea was added in Cocoon (you can read the Cocoon2
> > document), it's all we have now. Or download the Cocoon2 alpha source
> > from the xml-cocoon2 branch of the xml-cocoon CVS module.
>
> I did read the docs on cocoon2 and it does look similar, but I'm not
> sure if we have identical models.
True, I have the same concern. This is why I raised the issue.
> > Exactly. This is the idea. What i don't like is the "url-encoding" of
> > this. so, instead of doing
> >
> > <servlet match="[EMAIL PROTECTED]"...>
> >
> > I would do
> >
> > <process address="[EMAIL PROTECTED]">
> > <matcher type="agentChecker">
> > <parameter name="agent" value="Outlook Express 5.0"/>
> > </matcher>
> > ...
> > </process>
> >
> > leaving the "recipient-is" matching the default one (like we do in
> > Cocoon2 leaving the URI matching the default one).
>
> I'm guessing you have equated URL's and recipients as comparable, which
> is why you suggested <process address="[EMAIL PROTECTED]">.
Yes.
> However, many matches will not use recipient info, and few will have
> "condition" parameters.
I disagree. The parallel to me is evident: just like you use an HTTP URI
to indicate your browser where to go and what to do, you tell your
mailer with the recipient list.
> The piping of email addresses have to support
> checks based on recipients, ip address, sender information, and
> theoretically any information contained in the message (for instance, I
> was going to write a match class that checked if the Date header was off
> by more than 5 minutes and whether this was the outgoing server, so
> email timestamps are correct).
Exactly like HTTP matching could be based on cookie information,
user-agent, time of day, or server load.
> I do see how both models use a piping approach, but JAMES can't rely on
> a single routing parameter (a URL in HTTP servers) so Federico
> implemented a more flexible solution.
Why not?
Oh... wait, maybe I wasn't clear enough... look at this
<process address="stefano@localhost">
<...>
</process>
<process address="stefano@localhost">
<match type="timestampBroken"/>
</process>
<process address="*@localhost">
<...>
</process>
> I'm not saying it's perfect...
> it'd be nice if it could support multiple match criteria to a single
> servlet (without making the parameters very ugly).
I'm _very_ afraid of having things like
<process
match="(recipientIs=stefano@localhost)and((timestamp!=currenttime())or(x-mailer!=regexp(.x./.)))">
...
</process>
don't you agree? It's a slippy road this one.
There is another issue: XML validation. It's easy to come up with a
schema for this sitemap if we use the matching element, it's almost
impossible if we create a matching logic encoded in the attribute value.
> Does your sitemap
> docs support the lack of a single piece of routing information (no URL)
> and does it support boolean/multiple match conditions? I didn't see how
> the sample would accomplish this.
It can do "and" but not "or".
<process address="[EMAIL PROTECTED]">
<match type="firstMatcher"/>
<match type="secondMatcher"/>
...
</process>
<process address="[EMAIL PROTECTED]">
<match type="firstMatcher"/>
...
</process>
Anyway, don't get me wrong: I'm more than open to suggestions :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
