I am sorry, I really have a problem following all this discussion and I
feel I have no idea of what is really discussed.
My understanding was that:
- we make a list of cases.
http://www.martin-stecher.de/opes/smtpusecases.html and keep adding to it
each case we would indentify as not covered
- we would discuss the best OPES architecture able to address them
- in testing the propositions against each of these cases.
I expected that in this process we would discover new services we could
enable this way, and at the same time to simplify the architecture to be used.
Today I feel (but I may be wrong) that we are sorting and filtering case
concepts (not real cases) along sorting and filtering concept corresponding
to a solution approach. I do not object that this may not be right and
brillant, but I am lost and cannot commit.
Now, I must confess that I am not interested in SMTP as such. I am
interested in real store and forward cases serviced by OPES over real life
MTAs, SMTP being part of their support, may be this is why I am
lost? Also, I am definitly interested in operational, legal local
constraints, as something a solution must support (and may be should we
list them all, as Hector is probably not the only one having some needs in
that area ? I listed at least one myself [to make sure mail would never
cross machines of a given domain/country]. But this should not be used to
limitate the architectural specifications.
If I am out of context, I apologize.
jfc
At 21:09 22/01/2005, Martin Stecher wrote:
>
>
> OPES is supposed to enable new services.
Absolutely.
>
> The call-forward wouldn't have been a hack if it had been done as
> part of an OPES service, using the same architectural model that
> we used for HTTP.
I fully agree.
> Further, we rule out a large number of useful
> identity-based services by eliminating the ability to do
> response modification.
Here I disagree.
Tonny describes again a use case that we've listed already last year.
See sample 2-2 on http://www.martin-stecher.de/opes/smtpusecases.html
No doubt that it is a very important one.
This and other examples of group 2 are the "useful identity-based services"
you are referring to, aren't they?
And these are all request satisfaction examples, not response modification.
Again: Response modification is only useful if the callout service makes
use of the original response data, which in SMTP is the SMTP reply.
The only service I can think of, that does this, is a logging service.
Is that one strong enough to have response modification in the SMTP
deployment?
Or can you please describe another important service that makes use of
the response and modifies it?
Regards
Martin