[ http://issues.apache.org/jira/browse/JAMES-714?page=comments#action_12454660 ] Joachim Draeger commented on JAMES-714: ---------------------------------------
Yes, the SearchCommand is completely open. Don't know if we need to write something plugable for partial implementation here. Doing it well structured should make it easy to extend. The actual search has to be performed on the backend. For example: In the current implementation the header lines are split up, by using one row for each line. This way messages could be searched by one query. Different implementations could have different ways of doing this. The SearchCommand just builds up the SearchTerm, an object tree holding the search information, and passes it to the backend. I don't like to use JavaMail's SearchTerm directly. Why can't they use interfaces? Maybe we find a better way to construct the search object tree. For interoperability it should be congruent to allow to convert one to the other. At least we should draft our own one at first by reading IMAP RFC and value JavaMail's one afterwards. An argument for JavaMail's SearchTerm is that it should work on MimeMessages out-of-the-box. So we could load the complete MimeMessages and let JavaMail do the decision as a temporary solution. (Of course inside TorqueMailbox) The problem with an optimized solution is that I'm not sure if and how long we will stay with torque. To ANTLR: That sounds like a really good idea. It should be fast because of code generation. AFAIK it is used by Apache Directory. Is it possible to use the RFC ABNF directly? ;-) We should give it a try for the SearchCommand. Joachim > SearchCommand: Modular Implementation...? > ----------------------------------------- > > Key: JAMES-714 > URL: http://issues.apache.org/jira/browse/JAMES-714 > Project: James > Issue Type: Task > Components: IMAPServer > Affects Versions: Trunk > Reporter: Robert Burrell Donkin > Priority: Minor > > The Search command is a part of the IMAP specification that is yet to be > implemented in James. The wiring has already been outlined with > SearchCommandParser in SearchCommand returning a SearchTerm implementation. > All good so far. > I need to implement a solution for a small number of search keys in order to > allow my IMAP server to be accessed by an Apple Mail.app client. (Not sure > when I'll find the time so opening a JIRA rather than discussing on list.) > Implementing the complete Search command specification is likely to be time > consuming. However, the specification naturally breaks down into the > composite application of a number of search keys. So, it should be possible > to factor the design so that each search key implementation could be > implemented in isolation. This would allow a partial implementation of the > most commonly used search terms to be build up over time. > Opinions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
