rest/opacity - Revision history

RyanKing: Reverted edits by AlcomOnerb (Talk) to last version by Brian

2009-01-08T20:07:53Z

Reverted edits by AlcomOnerb (Talk) to last version by Brian

← Older revision		Revision as of 20:07, 8 January 2009
Line 1:		Line 1:
	[http://spfortne.qsh.eu/20090101-appliance-audio.html appliance audio bernies video] [http://sedplxca.is-the-boss.com/sitemap.htm sitemap] [http://tulilre.strefa.pl/2008-12-31-pocket-pussy-video.html pocket pussy video] [http://golxando.0lx.net/1010212577.html japanese female masturbation movies] [http://lofaako.strefa.pl/sitemap.html links]
	''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''		''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

AlcomOnerb: http://spfortne.qsh.eu/20090101-appliance-audio.html

2009-01-08T13:43:00Z

http://spfortne.qsh.eu/20090101-appliance-audio.html

← Older revision		Revision as of 13:43, 8 January 2009
Line 1:		Line 1:
			[http://spfortne.qsh.eu/20090101-appliance-audio.html appliance audio bernies video] [http://sedplxca.is-the-boss.com/sitemap.htm sitemap] [http://tulilre.strefa.pl/2008-12-31-pocket-pussy-video.html pocket pussy video] [http://golxando.0lx.net/1010212577.html japanese female masturbation movies] [http://lofaako.strefa.pl/sitemap.html links]
	''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''		''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

Brian: Reverted edits by AlcomOnerb (Talk) to last version by DrErnie

2008-12-16T19:30:32Z

Reverted edits by AlcomOnerb (Talk) to last version by DrErnie

← Older revision		Revision as of 19:30, 16 December 2008
Line 1:		Line 1:
	~~liletovic~~
	''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''		''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

AlcomOnerb: alrodr

2008-12-16T17:11:04Z

alrodr

← Older revision		Revision as of 17:11, 16 December 2008
Line 1:		Line 1:
			liletovic
	''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''		''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

DrErnie: /* Questions by Mike Schinkel */

2007-01-23T21:48:52Z

Questions by Mike Schinkel

← Older revision		Revision as of 21:48, 23 January 2007
Line 133:		Line 133:
	<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>		<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>
	This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?		This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?
	:Sure, "the opacity axiom" is specifically about client-side implementations, but I was referring to the more general concept of an "opaque string." My point was merely to illustrate that the server could choose whether or not to treat the URI as opaque (contrast how Apache and Squid satisfy URI requests) '''because'' the client (absent information to the contrary for the server) '''is''' required to treat the URI as opaque.		:Sure, "the opacity axiom" is specifically about client-side implementations, but I was referring to the more general concept of an "opaque string." My point was merely to illustrate that the server could choose whether or not to treat the URI as opaque (contrast how Apache and Squid satisfy URI requests) '''because'' the client (absent information to the contrary for the server) '''is''' required to treat the URI as opaque.[[User:DrErnie\|Dr. Ernie]] 13:48, 23 Jan 2007 (PST)

	2.) Additionally, you state:		2.) Additionally, you state:
Line 140:		Line 140:

	Can you give an example of such a Microformat? Does one exist, or is it hypothetical on your part? Also, wouldn't such a "Microformat" be, almost by definition, non-visible and thus according to community concensus not a Microformat? (more of a "Microdirective", if you will. :)		Can you give an example of such a Microformat? Does one exist, or is it hypothetical on your part? Also, wouldn't such a "Microformat" be, almost by definition, non-visible and thus according to community concensus not a Microformat? (more of a "Microdirective", if you will. :)
			:Actually, it might be more helpful to think of this in the context of an HTML form, which is a type of semantic markup that provides guidance for humans (and potentially machines) about how to contruct appropriate URLs. A hypothetical microformat (no, I don't know of any so far) would most likely be some sort of "rel" relation on an anchor or form tag, and thus still "visible" in the usual sense.[[User:DrErnie\|Dr. Ernie]] 13:48, 23 Jan 2007 (PST)


	Thanks in advance for the clafifications.		Thanks in advance for the clafifications.

	[[User:MikeSchinkel\|MikeSchinkel]] 14:44, 19 Nov 2006 (PST)		[[User:MikeSchinkel\|MikeSchinkel]] 14:44, 19 Nov 2006 (PST)

DrErnie: /* Questions by Mike Schinkel */

2007-01-23T21:45:07Z

Questions by Mike Schinkel

← Older revision		Revision as of 21:45, 23 January 2007
Line 128:		Line 128:
	* Sean McGrath's parable on [http://www.itworld.com/Tech/2327/nlsebiz070123/pfindex.html ITworld].		* Sean McGrath's parable on [http://www.itworld.com/Tech/2327/nlsebiz070123/pfindex.html ITworld].

	=Questions by Mike Schinkel=		= Issues=
			==Questions by Mike Schinkel==
	1.) Ernie, you state the following:		1.) Ernie, you state the following:
	<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>		<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>
	This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?		This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?
			:Sure, "the opacity axiom" is specifically about client-side implementations, but I was referring to the more general concept of an "opaque string." My point was merely to illustrate that the server could choose whether or not to treat the URI as opaque (contrast how Apache and Squid satisfy URI requests) '''because'' the client (absent information to the contrary for the server) '''is''' required to treat the URI as opaque.

	2.) Additionally, you state:		2.) Additionally, you state:

DrErnie: /* See Also */ added link

2007-01-23T21:36:31Z

MikeSchinkel: /* See Also */ Added questions for Ernie's writings

2006-11-19T22:44:33Z

See Also: Added questions for Ernie's writings

← Older revision		Revision as of 22:44, 19 November 2006
Line 126:		Line 126:

	The treatment of URI opacity on the RestWiki. http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity]		The treatment of URI opacity on the RestWiki. http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity]

			=Questions by Mike Schinkel=
			1.) Ernie, you state the following:
			<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>
			This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?

			2.) Additionally, you state:

			<blockquote>''This implies to me that the server could use a specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service. ''</blockquote>

			Can you give an example of such a Microformat? Does one exist, or is it hypothetical on your part? Also, wouldn't such a "Microformat" be, almost by definition, non-visible and thus according to community concensus not a Microformat? (more of a "Microdirective", if you will. :)

			Thanks in advance for the clafifications.

			[[User:MikeSchinkel\|MikeSchinkel]] 14:44, 19 Nov 2006 (PST)

DrErnie: edited final comment, added See Also

2006-10-25T21:36:25Z

edited final comment, added See Also

← Older revision		Revision as of 21:36, 25 October 2006
Line 121:		Line 121:
	= Final Comment By Dr. Ernie Prabhakar =		= Final Comment By Dr. Ernie Prabhakar =

	This implies to me that the ''server'' ~~should~~ use an specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.		This implies to me that the ''server'' could use a specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.

			= See Also =

			The treatment of URI opacity on the RestWiki. http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity]

MikeSchinkel: /* Final Comment By Ernie */ included Ernie's full name

2006-10-25T19:29:26Z

Final Comment By Ernie: included Ernie's full name

← Older revision		Revision as of 19:29, 25 October 2006
Line 119:		Line 119:
	chose the wrong solution.		chose the wrong solution.

	= Final Comment By Ernie =		= Final Comment By Dr. Ernie Prabhakar =

	This implies to me that the ''server'' should use an specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.		This implies to me that the ''server'' should use an specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.

← Older revision		Revision as of 21:36, 23 January 2007
Line 125:		Line 125:
	= See Also =		= See Also =

	The treatment of URI opacity on the ~~RestWiki.~~ http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity]		* The treatment of URI opacity on the [http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity RestWiki].
			* Sean McGrath's parable on [http://www.itworld.com/Tech/2327/nlsebiz070123/pfindex.html ITworld].

	=Questions by Mike Schinkel=		=Questions by Mike Schinkel=