Stefano Mazzocchi wrote:
>
> Federico Barbieri wrote:
> >
> > <match condition="UserIs="pluto">
>
> Note: the line above is invalid XML!!!
>
<match condition="UserIs=pluto">
Ok?
>
> Ok, there are two possible ways of doing this:
>
> 1) procedural (as Federico is proposing)
> 2) declarative (as I proposed)
>
> To summarize:
>
> 1) procedural
>
> if (testA)
> if (testB)
> do something
> fi
> if (testC)
> do something else
> fi
> fi
>
> 2) declarative
>
> do something when testA and testB
> do something else when testA and testC
>
Ok... I mislead you with a bad example.
writing 'condition="UserIs=pluto"' means that the condition string works
exactly the same as before and thus may have many Match calss:
condition="UserIs=pluto & SizeNotOver=100k"
So My point is to allow, not to force nesting.
>
> > This define a tree and each </match> is a leaf where the pipe ends thus
> > after each match spit a mail (recipients) there is no merge back. I
> > cannot draw the tree just with ascii... :-(
>
> That's the point. You can't even draw it with ascii!
C'mon! It will take 3 seconds to drow it on a piece of paper... the fact
that ascii is poor do not make trees (that are hard to draw) a bad
thing!
> It's much harder to
> visualize it. To find out what happens when your mail is sent to
> "[EMAIL PROTECTED]" you have to "debug" your flow.... Also, if you
> change one leaf, you could be messing up with the whole tree.
No. This is a tree, not a graph. So if you modify one node changes will
go up to all chindren nodes but it will not affect any parent or
"brother" node. And of course if you placed a mailet in a node is
exactly becouse you want to change it once for all children!
> [.....]
> > The second point is to use names instead of class (instances) inside the
> > tree definition so that mailet instance can appear in different places
> > in the tree. Mailet configuration should go somewhere else:
> >
>
> I agree with this. Also, as a suggestion, you should use XML "id"
> attribute instead of "name" which is automatically enforced by XML
> parsers.
Fine for me. What does exactly means "enforced" ?
>
> > Such a sintax should make configuration more readable and powerful
> > avoiding the risk of a "ad hoc" scripting language.
>
> I say exactly the opposite. :)
>
> my proposal? much flatter with the use of <continue/> and <stop/>
>
> <mailmap>
>
> <mailbox name="*">
> <match id="spam">
> <stop/>
> </match>
> <match id="local">
> <continue/>
> </match>
> <mailet id="remoteDelivery"/>
> </mailbox>
>
> [...]
>
> </mailmap>
>
> while this seems a hack to flatterize the tree at first, you should note
> its object orientation: what you do is extending each mailbox matching
> with some further parameters.
It IS an hack to flatterize a tree. And I can't see the need to write a
tree as a flat file. If the stucture is a tree I must provide the
ability to write it as a tree 'couse this is sure the easiest way. You
are forcing admin to think at their tree and flatter it.
Of course if the stucture is not a tree there is no reason to have
nested elements.
Agree with Serge 'bout <continue/>, <stop/> ... it's not up to the conf,
it must be the logic in the mailet to decide what to do with the Mail
(more on this soon).
And <continue/> looks like 'break' in a 'for' loop. <continue/> just
means 'jump to the next mailbox' which works as it is nested where the
<continue/> was.
>
> Also, such a schema allows you to "include" mailmap fragments and let to
> each user or subgroup include their schemas without having to tune the
> tree too much for that. This is important for ISP or places where a
> single mail server handles multiple domanins and each domain has
> separate policies maintained by different individuals.
Do not agree. If you change some condition on the first mailbox this
affect the whole tree but it's harder to see hierarchy.
>
> While my proposal is more verbose and harder to compose at first, it's
> easier to manage in the long run.
>
> I suggest you to play around with this idea a bit before judging....
> it's the same for XSLT: it appears very strange at first, because your
> mind doesn't work that way... but it's easy to find out that this is the
> way it worked before you learned programming :-)
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
I can't see very well you opinion... at beginning you say that my
example is procedural but your purpose is not less procedural.
So declarative is poor IMO because:
if (isLocal & UserIs=pippo)
mailet 1
mailet 2
stop
if (isLocal & UserIs=pluto)
mailet 1
mailet 3
stop
if (isLocal & UserIs=minnie)
mailet 1
mailet 4
stop
if (isLocal & UserIs=topolino)
mailet 1
mailet 5
stop
1 - is more verbose (that is opposite to readable) than the equivalent
tree
if (isLocal)
mailet 1
if (Useris=pippo) mailet 2
if (UserIs=pluto) mailet 3
...
you have to duplicate istances or reference and duplicate match where is
not necessary.
2 - each mail must goes trought all match while having a binary tree
matching structure makes it faster, much faster.
Your example is nothing but a tree. If you follow all possible path a
Mail can follow you will find the same tree I've wrote... so what is the
avantage of writing a tree in a flat way?
I have some code ready as example... I'll post it as soon as possible.
Fede
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
