DAP4: DAP Versions - Revision history

Jimg at 19:11, 31 August 2012

2012-08-31T19:11:57Z

← Older revision		Revision as of 19:11, 31 August 2012
Line 1:		Line 1:
	[[Category:Development\|Development]][[Category:DAP4\|DAP4]]		[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
	<font size="+1" color="red">This is an old document that captures the starting point of the OPULS design work. It's out of date and should be referenced only as a baseline for the work.</font>		<font size="+1" color="red">This is an old document that captures the starting point of the OPULS design work. It's out of date and should be referenced only as a baseline for the work.</font>

			[[OPULS_Development \| <-- back to OPULS Development]]

			Author: [[User:Jimg\|Jimg]]
	== Supporting both DAP2 and DAP4 ==		== Supporting both DAP2 and DAP4 ==
	Originally, DAP4 included the notion of support for various versions of the protocol (e.g., 2.0, 3.1, 3.2, ..., 4.0, 4.1, ...). A number of schemes to support this range of behaviors was discussed and one that closely emulates how HTTP handles this task is recommended.		Originally, DAP4 included the notion of support for various versions of the protocol (e.g., 2.0, 3.1, 3.2, ..., 4.0, 4.1, ...). A number of schemes to support this range of behaviors was discussed and one that closely emulates how HTTP handles this task is recommended.

Jimg at 19:10, 31 August 2012

2012-08-31T19:10:17Z

← Older revision		Revision as of 19:10, 31 August 2012
Line 1:		Line 1:
	[[Category:Development\|Development]][[Category:DAP4\|DAP4]]		[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
			<font size="+1" color="red">This is an old document that captures the starting point of the OPULS design work. It's out of date and should be referenced only as a baseline for the work.</font>
	== Supporting both DAP2 and DAP4 ==		== Supporting both DAP2 and DAP4 ==
	Originally, DAP4 included the notion of support for various versions of the protocol (e.g., 2.0, 3.1, 3.2, ..., 4.0, 4.1, ...). A number of schemes to support this range of behaviors was discussed and one that closely emulates how HTTP handles this task is recommended.		Originally, DAP4 included the notion of support for various versions of the protocol (e.g., 2.0, 3.1, 3.2, ..., 4.0, 4.1, ...). A number of schemes to support this range of behaviors was discussed and one that closely emulates how HTTP handles this task is recommended.

Jimg: moved DAP4: Versioning to DAP4: DAP Versions: I hate the 'word' versioning...

2012-02-07T22:34:57Z

moved DAP4: Versioning to DAP4: DAP Versions: I hate the 'word' versioning...

← Older revision	Revision as of 22:34, 7 February 2012
(No difference)

Jimg: /* Supporting both DAP2 and DAP4 */

2012-02-03T20:49:20Z

Supporting both DAP2 and DAP4

← Older revision		Revision as of 20:49, 3 February 2012
Line 17:		Line 17:
	# Leaving the suffix ''ddx'' for DAP2 servers prevents name collisions, which is part of what this idea addresses. It's hard for clients to support several versions of servers. Leaving the ''ddx'' name behind solves this problem, even though it is no formally part of the DAP2 specification.		# Leaving the suffix ''ddx'' for DAP2 servers prevents name collisions, which is part of what this idea addresses. It's hard for clients to support several versions of servers. Leaving the ''ddx'' name behind solves this problem, even though it is no formally part of the DAP2 specification.
	# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4		# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4
			# I will also propose that finer grained version information be used in the responses along the lines of [http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-16#section-3.2.3 HTTP/1.1 Cache-Control headers extensibility policy].

	== The Old Version Options ==		== The Old Version Options ==

Jimg: /* Old text below */

2012-02-03T19:29:12Z

Old text below

← Older revision		Revision as of 19:29, 3 February 2012
Line 18:		Line 18:
	# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4		# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4

	= Old ~~text below~~ =		== The Old Version Options ==
	=~~= Version ==~~
			<font color="red">This text is presented to provide (partial) context for the design above. What follows is '''not''' the proposed design for DAP4</font>

	See [[DAP_4.0_Design#Version \| Version]] in the [[DAP 4.0 Design]] for the low down on this feature.		See [[DAP_4.0_Design#Version \| Version]] in the [[DAP 4.0 Design]] for the low down on this feature.

Jimg: /* An Alternative Approach */

2012-02-03T19:26:19Z

An Alternative Approach

← Older revision		Revision as of 19:26, 3 February 2012
Line 1:		Line 1:
	[[Category:Development\|Development]][[Category:DAP4\|DAP4]]		[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
	== ~~An Alternative Approach~~ ==		== Supporting both DAP2 and DAP4 ==
	~~Below in [[#Version \| Version]]~~, various ~~ways to support clients and servers negotiating~~ the protocol ~~version they will use are discussed~~. ~~In the end~~, ~~a technique~~ that closely emulates how HTTP handles this task is recommended.		Originally, DAP4 included the notion of support for various versions of the protocol (e.g., 2.0, 3.1, 3.2, ..., 4.0, 4.1, ...). A number of schemes to support this range of behaviors was discussed and one that closely emulates how HTTP handles this task is recommended.
			That is a fine idea for a protocol like HTTP because, in its case, the negotiation takes place between two C/C++/Java programs. However, DAP lives in the realm of both procedural languages and ''web applications''. For the latter, version negotiation is far more cumbersome (cf. WCS). In addition, support for a rang of versions in the server makes their development cumbersome and more error prone. All of this ''decreases'' the likelihood that any arbitrary pair of client and server will work together.

	That is a fine idea for a protocol like HTTP because, in that case, the negotiation takes place between two C/C++/Java programs. However, DAP lives in the realm of both C, ..., and ''web applications''. For the latter, version negotiation is far more cumbersome (cf. WCS). I propose that we do not support version negotiation in the commonly-used sense of the phrase, but instead adopt a new ~~way~~ of ~~asking~~ for DAP4 responses. I propose that the URL suffixes ''.das'', ''.dds'' and ''.dods'' be used only for DAP2 requests (which always return DAP2 ~~reponses~~) and that the suffixes ''.xml'' and ''.dap'' be used only for DAP4 requests (and which only return DAP4 responses). This way, clients never need to negotiate. If all a client understands is DAP2, that's all it can ask for. For clients that do know DAP4, they ask for ~~and get that or an error~~. Note that the [[DAP Service Terminus]] response provides a way for simple web browsers to display links to these different ~~response formats~~, all in a way that's transparent to the browser, something that the 'version negotiation' techniques cannot do nearly as well.		I propose that we do not support version negotiation in the commonly-used sense of the phrase, but instead adopt a new set of suffixes to ask for DAP4 responses. I propose that the URL suffixes ''.das'', ''.dds'' and ''.dods'' be used only for DAP2 requests (which always return DAP2 responses) and that the suffixes ''.xml'' and ''.dap'' be used only for DAP4 requests (and which only return DAP4 responses). This way, clients never need to negotiate. If all a client understands is DAP2, that's all it can ask for (because by definition and in reality, it only has software to request those things). For clients that do know DAP4, they ask for the DAP4 responses using the two new suffixes. Note that the [[DAP Service Terminus]] response provides a way for simple web browsers to display links to these different responses, all in a way that's transparent to the browser, something that the 'version negotiation' techniques cannot do nearly as well.

	What the suffixes mean:		What the suffixes mean:

Jimg at 18:52, 3 February 2012

2012-02-03T18:52:21Z

← Older revision		Revision as of 18:52, 3 February 2012
Line 17:		Line 17:
	# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4		# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4

			= Old text below =
	== Version ==		== Version ==

Jimg: /* An Alternative Approach */

2012-02-03T00:53:05Z

An Alternative Approach

← Older revision		Revision as of 00:53, 3 February 2012
Line 1:		Line 1:
	[[Category:Development\|Development]][[Category:DAP4\|DAP4]]		[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
	== An Alternative Approach ==		== An Alternative Approach ==
	Below in [[#Version \| Version]] various ways to support clients and servers negotiating the protocol version they will use are discussed. In the end, a technique that closely emulates how HTTP handles this task is recommended.		Below in [[#Version \| Version]], various ways to support clients and servers negotiating the protocol version they will use are discussed. In the end, a technique that closely emulates how HTTP handles this task is recommended.

	That is a fine idea for a protocol like HTTP because the negotiation takes place between two C/C++/Java programs. However, DAP lives in the realm of both C, ..., and ''web applications''. For the latter, version negotiation is far more cumbersome (cf. WCS). I propose that we ''do not support version negotiation in the commonly-used sense of the phrase'' but instead adopt a new way of asking for DAP4 responses. I propose that the URL suffixes ''.das'', ''.dds'' and ''.dods'' be used only for DAP2 requests (which always return DAP2 reponses) and that the suffixes ''.~~ddx~~'' and ''.dap'' be used only for DAP4 requests (and which only return DAP4 responses).		That is a fine idea for a protocol like HTTP because, in that case, the negotiation takes place between two C/C++/Java programs. However, DAP lives in the realm of both C, ..., and ''web applications''. For the latter, version negotiation is far more cumbersome (cf. WCS). I propose that we do not support version negotiation in the commonly-used sense of the phrase, but instead adopt a new way of asking for DAP4 responses. I propose that the URL suffixes ''.das'', ''.dds'' and ''.dods'' be used only for DAP2 requests (which always return DAP2 reponses) and that the suffixes ''.xml'' and ''.dap'' be used only for DAP4 requests (and which only return DAP4 responses). This way, clients never need to negotiate. If all a client understands is DAP2, that's all it can ask for. For clients that do know DAP4, they ask for and get that or an error. Note that the [[DAP Service Terminus]] response provides a way for simple web browsers to display links to these different response formats, all in a way that's transparent to the browser, something that the 'version negotiation' techniques cannot do nearly as well.

	What the suffixes mean:		What the suffixes mean:

Jimg: /* An Alternative Approach */

2012-02-03T00:48:28Z

An Alternative Approach

← Older revision		Revision as of 00:48, 3 February 2012
Line 6:		Line 6:

	What the suffixes mean:		What the suffixes mean:
	~~For DAP2:~~
	;das: Request the DAP2 ''use metadata'' response (aka attributes)		;das: Request the DAP2 ''use metadata'' response (aka attributes)
	;dds: Request the DAP2 ''structural metadata'' response (aka syntax)		;dds: Request the DAP2 ''structural metadata'' response (aka syntax)
	;dods: Request the DAP2 ''data response''		;dods: Request the DAP2 ''data response''
	;ddx: Request the DAP2 ''combined metadata'' response (With the understanding that this is not part of the formal DAP2 spec, but it's out and being used. Preventing name collisions is what this new take on how to approach the version problem is all about.)		;ddx: Request the DAP2 ''combined metadata'' response
	~~For DAP4:~~
	;xml: Request the DAP4 ''combined metadata'' response		;xml: Request the DAP4 ''combined metadata'' response
	;dap: Request the DAP4 ''data response''		;dap: Request the DAP4 ''data response''

			Notes:
			# Leaving the suffix ''ddx'' for DAP2 servers prevents name collisions, which is part of what this idea addresses. It's hard for clients to support several versions of servers. Leaving the ''ddx'' name behind solves this problem, even though it is no formally part of the DAP2 specification.
			# Using ''xml'' to request the DAP4 metadata response is perfectly legal and, if we use namespaces correctly, might open the door to wider adoption of DAP4

	== Version ==		== Version ==

Jimg: /* Version */

2012-02-03T00:44:25Z

Version

← Older revision		Revision as of 00:44, 3 February 2012
Line 1:		Line 1:
	[[Category:Development\|Development]][[Category:DAP4\|DAP4]]		[[Category:Development\|Development]][[Category:DAP4\|DAP4]]
			== An Alternative Approach ==
			Below in [[#Version \| Version]] various ways to support clients and servers negotiating the protocol version they will use are discussed. In the end, a technique that closely emulates how HTTP handles this task is recommended.

			That is a fine idea for a protocol like HTTP because the negotiation takes place between two C/C++/Java programs. However, DAP lives in the realm of both C, ..., and ''web applications''. For the latter, version negotiation is far more cumbersome (cf. WCS). I propose that we ''do not support version negotiation in the commonly-used sense of the phrase'' but instead adopt a new way of asking for DAP4 responses. I propose that the URL suffixes ''.das'', ''.dds'' and ''.dods'' be used only for DAP2 requests (which always return DAP2 reponses) and that the suffixes ''.ddx'' and ''.dap'' be used only for DAP4 requests (and which only return DAP4 responses).

			What the suffixes mean:
			For DAP2:
			;das: Request the DAP2 ''use metadata'' response (aka attributes)
			;dds: Request the DAP2 ''structural metadata'' response (aka syntax)
			;dods: Request the DAP2 ''data response''
			;ddx: Request the DAP2 ''combined metadata'' response (With the understanding that this is not part of the formal DAP2 spec, but it's out and being used. Preventing name collisions is what this new take on how to approach the version problem is all about.)
			For DAP4:
			;xml: Request the DAP4 ''combined metadata'' response
			;dap: Request the DAP4 ''data response''

	== Version ==		== Version ==