commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NET-333) would you provide a class used for imap protocol?
Date Tue, 22 Mar 2011 13:19:05 GMT

    [ https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009636#comment-13009636
] 

Bogdan Drozdowski commented on NET-333:
---------------------------------------

Why not an enum? The reason I had was simple: although enums provide type safety (which is
very good), I believe enums can't be subclassed nor they can derive from other classes, so
if we have "enum IMAPCommand", we can't have a class, say "public class IMAPSCommand extends
IMAPCommand" or "public enum IMAPSCommand extends IMAPCommand". This means that additional
commands must either be inserted into the base class, say IMAPCommand (now what if you're
using just the binary release?), or inserted into the class that uses them (like I did in
the AuthenticatingSMTPClient or ExtendedPOP3Client), or have their own class, completely unrelated
to the base class. The first is possible only if you have the source and either build it yourself
or wait for your patch to be applied, because it's impossible to subclass the base class currently.
The second and third solutions, on the other hand, spread the set of commands among many classes.
That's why I did it this way. With this in mind, the "final" keyword on the IMAPReply class
declaration is an error, I copied too much from other classes. If these classes aren't made
enum/final, users can subclass them without the source code and inherit all the commands/replies
automatically, so they can, for example, subclass *Client classes and have them use or produce
their own subclasses of *Command and *Reply.

I'm not currently subscribed to the mailing list, I'll browse the archives to check the volume
and perhaps I'll join you. Yes, some code is plainly copied between the classes, but the details
vary. Every clas has a __getReply() but, for example, the line continuation algorithm varies.
This could be made abstract, but what if we want just a SocketClient? We couldn't instantiate
it now. Currently (in the classes I'm interested in: IMAP, POP3, SMTP, FTP) I can see that
add/removeProtocolCommandListener could be immediately pushed up either to SocketClient or
to something new between the SocketClient class and the protocol classes (not the *Client
classes).

Did you verify that POP3SClient and SMTPSClient work for you? I used them and they worked
fine for me, but the IMAPSClient shows that they shouldn't (because they don't replace _reader
and _writer from the SSLSocket) and I'm puzzled.

> would you provide a class used for imap protocol?
> -------------------------------------------------
>
>                 Key: NET-333
>                 URL: https://issues.apache.org/jira/browse/NET-333
>             Project: Commons Net
>          Issue Type: Improvement
>            Reporter: iceviewer
>         Attachments: IMAP.zip
>
>
> would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message