You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Norman Maurer (JIRA)" <se...@james.apache.org> on 2010/12/15 09:07:02 UTC
[jira] Created: (JAMES-1147) Remove MailServer interface and move
the methods to other Interfaces
Remove MailServer interface and move the methods to other Interfaces
--------------------------------------------------------------------
Key: JAMES-1147
URL: https://issues.apache.org/jira/browse/JAMES-1147
Project: JAMES Server
Issue Type: Task
Affects Versions: 3.0-M2
Reporter: Norman Maurer
Assignee: Norman Maurer
Fix For: 3.0-M3
Attachments: mailserver_removal.diff
>From ML:
Hi there,
after spending some thoughts about last optimization before the next
release, I stumpled again over the MailServer interface.
The Mailserver interface has corrently 5 methods listed. I think a few
of them should be moved and a few should get removed at all. Let me
propose the following changes:
* MailServer.getId();
This method is only used by MailImpl to generate a new Mail name.
I think there are two things which would make sense...
1) Remove the method from the interface and just move the Id
generation code to MailImpl. In fact its only some kind of UUID and
long combination
2) Create a new Interface called MailNameGenerator with the method
createName() which will generate a new name to use in the Mail.
I think I would prefer 1.
* MailServer.supportVirtualHosting();
This method returns true if the server supports virtualhosting.
Which in fact means that the users must be added with an
"@domainpart". So your users would look like: user1@domain1,
user2@domain2 etc.
So I think it would make more sense to move the method to
UsersRepository interface. By default it would return false
* MailServer.getDefaultDomain();
Return the default domain which will get used if an email is
delivered to an user via smtp and no domainpart was given. As this is
clearly about domains I would suggest to move it to DomainList
interface
* MailServer.getHelloName();
Return the default hello name which will be used if no other is
configured for the service. I would just remove this method at all and
fallback to dnsservice.getLocalHost() by default if no hello name is
configured for the service.
* MailServer.getPostMaster():
Is only used by MailetContext.getPostMaster() as a wrapped call. So
just remove it.
Wdyt ?
Bye,
Norman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-1147) Remove MailServer interface and move
the methods to other Interfaces
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer resolved JAMES-1147.
----------------------------------
Resolution: Fixed
done
> Remove MailServer interface and move the methods to other Interfaces
> --------------------------------------------------------------------
>
> Key: JAMES-1147
> URL: https://issues.apache.org/jira/browse/JAMES-1147
> Project: JAMES Server
> Issue Type: Task
> Affects Versions: 3.0-M2
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 3.0-M3
>
> Attachments: mailserver_removal.diff
>
>
> From ML:
> Hi there,
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
> I think I would prefer 1.
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
> Wdyt ?
> Bye,
> Norman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-1147) Remove MailServer interface and move
the methods to other Interfaces
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer updated JAMES-1147:
---------------------------------
Attachment: (was: mailserver_removal.diff)
> Remove MailServer interface and move the methods to other Interfaces
> --------------------------------------------------------------------
>
> Key: JAMES-1147
> URL: https://issues.apache.org/jira/browse/JAMES-1147
> Project: JAMES Server
> Issue Type: Task
> Affects Versions: 3.0-M2
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 3.0-M3
>
> Attachments: mailserver_removal.diff
>
>
> From ML:
> Hi there,
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
> I think I would prefer 1.
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
> Wdyt ?
> Bye,
> Norman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-1147) Remove MailServer interface and move
the methods to other Interfaces
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer updated JAMES-1147:
---------------------------------
Attachment: mailserver_removal.diff
Proposed code changes
> Remove MailServer interface and move the methods to other Interfaces
> --------------------------------------------------------------------
>
> Key: JAMES-1147
> URL: https://issues.apache.org/jira/browse/JAMES-1147
> Project: JAMES Server
> Issue Type: Task
> Affects Versions: 3.0-M2
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 3.0-M3
>
> Attachments: mailserver_removal.diff
>
>
> From ML:
> Hi there,
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
> I think I would prefer 1.
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
> Wdyt ?
> Bye,
> Norman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-1147) Remove MailServer interface and move
the methods to other Interfaces
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer updated JAMES-1147:
---------------------------------
Attachment: mailserver_removal.diff
This is the correct one
> Remove MailServer interface and move the methods to other Interfaces
> --------------------------------------------------------------------
>
> Key: JAMES-1147
> URL: https://issues.apache.org/jira/browse/JAMES-1147
> Project: JAMES Server
> Issue Type: Task
> Affects Versions: 3.0-M2
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 3.0-M3
>
> Attachments: mailserver_removal.diff, mailserver_removal.diff
>
>
> From ML:
> Hi there,
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
> I think I would prefer 1.
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
> Wdyt ?
> Bye,
> Norman
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org