Yeah, "we" == Zimbra. :-) We've been using jSieve on the back end for about
3-4 years now. When a user creates mail filters, the web client code sends a
SOAP request to the server. The server processes the request, generates the
appropriate Sieve script, and saves it in the user's account settings. When a
message comes in, jSieve generates the filter actions that will be performed on
the incoming message.
When the user wants to modify his filters, we walk the jSieve parse tree to
generate the SOAP response. So we have SOAP->Sieve script code and jSieve
tree->SOAP code. The only thing we don't have is jSieve tree->Sieve script,
but I was able to use the other two to do a swift hack.
The only remaining case is the one I'm dealing with now. If a user moves or
renames a folder, I want to update all the scripts that reference that folder.
So I parse the script, walk the tree, and modify the nodes in-place. After I
modify the nodes, I want to save the updated script in the user's account
settings. This requires serializing the parse tree into a String.
I've attached a copy of the SOAP API planned for ZCS 6.0, for anyone that's
interested.
Boris
----- "Steve Brewin" <[EMAIL PROTECTED]> wrote:
> Boris Burtin [mailto:[EMAIL PROTECTED] wrote on: 18 October 2008
> 00:00
>
> > Thanks for following up so quickly. When a user moves or
> > renames a folder, we want to update any filter rules that
> > reference the folder. I actually have a workaround: Node ->
> > our XML syntax -> Sieve. Icky, but it works. I'll file an
> > enhancement request in JIRA to add a standard Node -> String
> > conversion API.
> >
> > Thanks!
> >
> > Boris
>
> Boris
>
> Again, just because I'm curious. A few questions.
>
> Is this needed because you don't keep the original Sieve scripts after
> parsing or because you are dynamically modifying the nodes and want to
> capture the results as a Sieve script?
>
> Does your workaround mean you have node->your XML syntax conversion
> coded already?
>
> Finally, when you say "we" does this mean Zimbra? What's the story? It
> is always a boost to know when a community's efforts are proving
> worthwhile to others. Often it is hard to tell.
>
> Cheers
>
> -- Steve
>
>
> > ----- "Steve Brewin" <[EMAIL PROTECTED]> wrote:
> >
> > > Boris Burtin [mailto:[EMAIL PROTECTED] wrote on: 17 October
> 2008
> > > 22:00
> > >
> > > > Is it possible to generate a Sieve script from a Node tree? I
> > > > have code that manipulates a tree in-place, and I'd like to
> > > > get the modified script as a String. I assumed this would be
> > > > easy, but I can't seem to find the right API to do it.
> > > >
> > > > Thanks in advance,
> > > >
> > > > Boris
> > >
> > > The only translation from nodes to another form I know of is to
> > > generate JSieve operations. You could mirror the same code
> > pattern to
> > > emit other forms such as a Sieve script.
> > >
> > > I'm curious about your use case. What is the driver for wanting
> this
> > > ability?
> > >
> > > Cheers
> > >
> > > --Steve
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
<GetFilterRulesRequest/>
<GetFilterRulesResponse>
<filterRules>
<filterRule name="{rule-name}" [active="{0|1}"]>
<filterTests condition="{allof | anyof"}>
{test}
[test]
...
</filterTests>
<filterActions>
{action}
[action]
...
</filterActions>
</filterRule>
[filter rule]
...
</filterRules>
</GetFilterRulesResponse>
<ModifyFilterRulesRequest>
<filterRules> ... </filterRules>
</ModifyFilterRulesRequest>
<ModifyFilterRulesResponse/>
* Default value for "active" is 1.
Tests:
<addressTest part="{all | local | domain}" stringComparison="{type}"
header="{header-name}" value="{value}" index="n"/>
<headerTest header="{header-name}" stringComparison="{type}" value="{value}"
index="n" />
<headerExistsTest header="{header-name}" index="n" />
<sizeTest numberComparison="{type}" s="{size}" index="n" />
<dateTest dateComparison="{type}" d="{date}" index="n" />
<bodyTest value="{value}" index="n" />
<attachmentTest index="n" />
<addressBookTest header="{header-name}" folderPath="{folder-path}" index="n"
/>
* Each test has an optional "negative" attribute, which specifies a "not"
condition for that test.
Actions:
<actionKeep index="n" />
<actionDiscard index="n" />
<actionFileInto folderPath="{folder-path}" index="n" />
<actionTag tagName="{tag-name}" index="n" />
<actionFlag flagName="{flag}" index="n" />
<actionRedirect a="{email-address}" index="n" />
<actionStop index="n" />
stringComparison values: is, contains, matches
numberComparison values: over, under
dateComparison values: before, after
size values are in bytes
flag values: flagged, read
date values are in seconds since epoch, and are truncated to the day. Hours,
minutes, and seconds are ignored.
index is an integer, used to maintain the order of filter tests and actions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
