[
Lists Home |
Date Index |
Thread Index
]
Oops... forgot to reply to the list.
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
--- Begin Message ---
On Fri, 2006-02-24 at 15:32, Jan Algermissen wrote:
> Hi,
>
> On Feb 24, 2006, at 3:41 PM, Bullard, Claude L ((Len)) wrote:
>
> > It's like
> > asking your mailman to do your taxes instead of moving the
> > form to the IRS and bringing the payment back.
>
> To extend the analogy:
>
> There is your mailman and your tax consultant, both having a
> processThis() method.
> You send you tax stuff to the tax consultant because you know it is a
> tax consultant and you send your mail to your mail man because you
> know that it is a mailman.
>
> But the give-stuff-to-operation is uniform ("take this and do what
> your job is"), I do not have to know about a processMail() or
> processTaxStuff() method.
>
> If the mailman changes jobs and you still hand him your mail (say
> because he happens to live in the same street now and passes by)
> he'll be able to respond: "No, go away...that ain'y my business anymore"
>
> Aside: the 'that' in the last sentence implies that the (former)
> mailman understands your intent.
>
> I wonder if it is sufficient for the receiver to infer the intent
> from recognizing what the stuff is that you handed to him (e.g. looks
> like mail => must be mail[1]) or if a protocol mechanism is needed
> such as HTTP's Expect header.
>
> If not, the out of band coordination (besides the protocol) would be
> reduced to a shared (loose?) understanding of what mail is.
> [1] Aka "Duck Typing":
> http://www.propylon.com/news/ctoarticles/040224_duckmodeling.html
Yeah, but that only works in a "show me yours and I'll tell you if I
want it" type of scenario. It won't always work that way, because you
may not want to have to try multiple recipients just to figure out if
they want to take your package. Why? Because that would a) tell them
you exist and b) possibly require you to tell people things which are
none of their business.
ast
--- End Message ---
|
