ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: [xml-dev] Exposing resources/services vs hiding implementation details
by Bill de hÓra other posts by this author
Apr 5 2005 4:39PM messages near this date
Re: [xml-dev] Exposing resources/services vs hiding implementation details | Re: [xml-dev] Exposing resources/services vs hiding implementation details
& XSLT 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


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php> 
Thread:
Claude L Bullard
Marc de Graauw
Joe Gregorio
Bill de hÓra
Michael Champion
Uche Ogbuji
Jan Algermissen
Uche Ogbuji
Rich Salz
Jan Algermissen
Rich Salz
Michael Champion
Bill de hÓra
Michael Champion
Uche Ogbuji
Bill de hÓra
Robert Koberg
Peter Hunsberger
Michael Champion
Leigh Dodds
Jan Algermissen
Leigh Dodds
Bill de hÓra
Michael Champion
Leigh Dodds
Michael Champion
Rick Marshall
Bill de hÓra
Robert Koberg
Rich Salz
Leigh Dodds
Rich Salz
Leigh Dodds
Rich Salz
Leigh Dodds
Andrzej Jan Taramina
Rich Salz
Bob Foster
Jan Algermissen
Mark Baker
Michael Champion
Michael Champion
Mark Baker
Mark Baker
Michael Champion
Bill de hÓra
Rich Salz
David Lyon
Rich Salz
Joe Gregorio
Rich Salz
Joe Gregorio
Saptagirisa N
Arvind Singh
Rich Salz
Joe Gregorio
Rich Salz
Joe Gregorio
Rich Salz
Dave Pawson
Mark Baker
Joe Gregorio
Mark Baker
Rich Salz
Michael Champion
Elliotte Rusty Harold
Joe Gregorio
Michael Champion
Jan Algermissen
Bill de hÓra
Joe Gregorio
Charles Woerner
Rich Salz

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved