james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mailet-api][proposal] MailAddress
Date Fri, 17 Aug 2007 00:21:22 GMT
Robert Burrell Donkin ha scritto:
> On 8/16/07, Danny Angus <danny@apache.org> wrote:
>> On 8/16/07, Norman Maurer <norman@apache.org> wrote:
>>> Stefano Bagnara schrieb:
>>> I fully agree with Stefano,
>> !!
>>
>> What is your point? That the API should enforce RFC compliance and not
>> the server?
>> Why? The servlet API doesn't enforce compliance with http or html
>> standards, the application server implementation might though.
> 
> there are good why it's rare for an API to actully insist on a
> particular parser implementation warts and all. including the parsing
> code in the API means that any fix will require a complete new version
> of the API to be issued.
> 
> if it's important that the address is RFC compliant then this can and
> should be stated clearly in the API. the parsing should be left to the
> implementor.

I'm not telling that the parsing have to be part of the API. I'm telling
I want to understand what is a MailAddress (as you propose to make it an
interface) and what is the contract for the MailAddress. If it is simply
2 nullable strings, then I am against this change, even if I already
declared I will not veto it: IMHO it does not make sense and does not
help anyone (users/implementors) having a similar interface.

>> If we leave this up to implementors then it is up to users to choose
>> ones which comply with appropriate standards. I don't think it is the
>> job of the mailet api to constrain things beyond what is necessary to
>> ensure that mailets work and are portable.
>>
>> James, or buni, or mailcatcher should validate addresses for compliance.
> 
> i'm not sure that it's the validation as much as the parsing that is
> important. there are ways that an address header could fail to be
> RFC822 compliant but still contain a parsable local part and domain.
> i'd be happy to insist that the data exposed by the implementation is
> valid RFC822 but feel it's important that there is implementation
> freedom for the parsing phase.
> 
> - robert

Let's talk about what the MailAddress *javadocs* will say to users and
implementors (as we cannot enforce any contract if it is an interface),
then we'll be able to discuss on how to implement it in JAMES Server,
IMHO. My main concern is about the mailet api, and not how server will
implement it (that's why I didn't understand the bounce back to server-dev).

IMHO trying to decide and agree that MailAddress must be an interface
without discussing the real interface and the real contract behind the
interface has no meaning. The decision about using an interface, an
abstract class or a concrete class *depends* by the contract we want to
expose... not viceversa.

But maybe you already explained this and I missed or misunderstood it
(too few sleep hours for me lately).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message