[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Exposing resources/services vs hiding implementationdetail

• To: Michael Champion <michaelc.champion@g...>
• Subject: Re: Exposing resources/services vs hiding implementationdetails
• From: Bill de hÓra <bill.dehora@p...>
• Date: Wed, 06 Apr 2005 00:11:47 +0100
• Cc: xml-dev <xml-dev@l...>
• In-reply-to: <e3a5cb2c050405144329d3ed74@m...>
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...> <4252B1D7.8090707@t...> <1112725099.7722.400.camel@borgia> <4252EE77.1080604@d...> <4252F528.5050503@t...> <e3a5cb2c050405144329d3ed74@m...>
• User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Michael Champion wrote:

> What if I'm looking for John Smith  and don't know his person-id?  Or
> whether it is Smythe or Smyth...  or Jon, or Jan ... or which office
> he works in?   A centralized name disambiguation and forwarding
> service would come in very handy.

Agreed. There is always a need for reference by description (and that 
need is not a bug).  The beauty is that you can have both; they're not 
exclusive. That's why I mentioned search earlier.


> Or, consider those acm.org forwarding addresses many of us use ... why
> not expose the actual email address?    

You mean like 302 redirects ;)


> I suspect a) we don't want to
> expose the real address to slimeball spammers, b) we want to be able
> to keep the same logical address if one changes "implementation
> details" such as employer, ISP, etc. c) we want a centralized point of
> management (at acm.org) for this and other personal metadata we choose
> to make public. Similar  reasons apply to the address example.

Agreed. Central management is good, but uniform management is as good, 
if not better. The beauty is that you can have both; they're not 
exclusive. That's why I mentioned RSS earlier.


> *if* your users do far more read operations than create/update/delete
> operations, and there is a high probability that a document that is
> retrieved once will be requested again soon..  Very true on the Web. 
> Not true for data enty applications.  Nightmarishly difficult in the
> distributed read/write case.

Don't understand the last bit - nightmarishly difficult how? For the 
firs bit, data entry, being able to ask the system you've entered the 
data to what the current state is now is a big win. The only time 
systems don't fail is where they're on whiteboards ;)

cheers
Bill

• Follow-Ups:
  • Re: Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>

• References:
  • RE: What Does SOAP/WS Do that A REST System Can't?
    • From: "Marc de Graauw" <marc@m...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Bill de hÓra <bill.dehora@p...>
  • Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Jan Algermissen <jalgermissen@t...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Uche Ogbuji <Uche.Ogbuji@f...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Rich Salz <rsalz@d...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Jan Algermissen <jalgermissen@t...>
  • Re: Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>

• Prev by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: Exposing resources/services vs hiding implementation details
• Next by thread: Re: Exposing resources/services vs hiding implementation details
• Index(es):
  • Date
  • Thread