[UA-EAI] Seeking input UA-readiness of Open Source Code

[Arnt Gulbrandsen]

On Monday 2 September 2019 09:08:25 CEST, John Levine wrote:
> In article 
> <46afdf29-f7fd-4e71-9947-fe3a5941eb2e at gulbrandsen.priv.no> you 
> write:
>> No. EAI is designed such that APIs tend to need no changes.
>
> That's a rather debatable assertion.

At risk of digressing further, could you give some counterexample?

It was easy to find counterexamples during the draft stage, but I brought 
them up and they were quickly resolved. I didn't need to argue.

> I suppose it might be so in a
> world where everyone supports EAI, or in a trivial application that
> sends one message to one address, but in this world where we will have
> a mix of EAI and ASCII mail for the forseeable future, EAI software
> will have to deal with failures that ASCII mail doesn't.

That's a nice general statement with which I cannot possibly disagree.

> Even with one message to one address, applications will see new
> errors if they send an EAI message to an ASCII address that happens
> not to support EAI.

What does that mean for APIs?

I have reviewed three opensource libraries with EAI support (one each for 
python, java and c++). None of the three add new errors to their API, and 
that is quite appropriate in each case, given the scope of what these 
libraries do and don't.

For example, I mentioned a java class yesterday, one for email address 
validitation. That class doesn't go into detail. Applications that use that 
class can distinguish syntactically valid email addresses from other 
strings, and that's all. That's the entire API. Since it doesn't provide a 
list of possible errors, there's no list to be extended and apps that use 
this class cannot possibly handle any new EAI-related error cases. You say 
they "will have to". No. as far as these apps are concerned, the only error 
case is "invalid address", and if the internal details of that has changed, 
then these apps do not notice that.

Which brings me back to my original point. Perhaps I should elaborate on 
that, give an example...

The original python software I found was something to accept email into a 
webapp (a calendar thing, actually). Users would be able to send email to a 
specific address, and the webapp would create/update calendar entries.

This was solved using two separate pieces of software: One that accepts 
email via SMTP, and another that interprets messages as they arrive and 
reacts to calendar-related attachments.

Finding and classifying the first is simple. How does this survey mean to 
find and classify the second? (Ignoring it is a valid answer, of course.)

Arnt