Hyrax Catalogs - Revision history

PatrickWest: /* Questions */

2011-04-21T14:14:40Z

Questions

← Older revision		Revision as of 14:14, 21 April 2011
Line 113:		Line 113:
	** As for your jgofs question, directories are shown and can be traversed, just like the default catalog. But no files are listed. The jgofs objects are listed in the .remoteobjects file, if there is one in that directory.		** As for your jgofs question, directories are shown and can be traversed, just like the default catalog. But no files are listed. The jgofs objects are listed in the .remoteobjects file, if there is one in that directory.
	* <font color="red">JG: If we do this, will the SQL handler work? Almost? (and we can change the color or these questions once you all see them... I don't wan to make it all ugly.</font>		* <font color="red">JG: If we do this, will the SQL handler work? Almost? (and we can change the color or these questions once you all see them... I don't wan to make it all ugly.</font>
			** I'm afraid I have not yet had time to look at the SQL handler, so am not sure.

	== Old Notes with Comments ==		== Old Notes with Comments ==

PatrickWest: /* Questions */

2011-04-21T14:14:02Z

Questions

← Older revision		Revision as of 14:14, 21 April 2011
Line 108:		Line 108:

	===Questions===		===Questions===
	* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out. [<font color="red">JG: Can you remind me what the JGOFS directory holds - the catalog is the collection of served data sets, yes?</font>]		* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out.
			** [<font color="red">JG: Can you remind me what the JGOFS directory holds - the catalog is the collection of served data sets, yes?</font>]
			** This is just an example. Change the name from jgofs to foobar. What do I do if there's a catalog names foobar and a directory in the root of the default catalog named foobar? In the response to a showCatalog, do I include them both? I say yes.
			** As for your jgofs question, directories are shown and can be traversed, just like the default catalog. But no files are listed. The jgofs objects are listed in the .remoteobjects file, if there is one in that directory.
	* <font color="red">JG: If we do this, will the SQL handler work? Almost? (and we can change the color or these questions once you all see them... I don't wan to make it all ugly.</font>		* <font color="red">JG: If we do this, will the SQL handler work? Almost? (and we can change the color or these questions once you all see them... I don't wan to make it all ugly.</font>

Jimg: /* Comments */

2011-04-21T04:02:05Z

Comments

← Older revision		Revision as of 04:02, 21 April 2011
Line 222:		Line 222:

	===Comments===		===Comments===
	~~<font color="red">~~Why does this matter? Do we need to use multiple catalogs for something? [[User:Jimg\|jimg]] 10:43, 12 August 2009 (PDT)		Why does this matter? Do we need to use multiple catalogs for something? [[User:Jimg\|jimg]] 10:43, 12 August 2009 (PDT)

	:Yes. As we grow Hyrax we will need to support additional catalogs and services. Because both the BES and the OLFS can independently (and as part of their regular usage pattern) modify the catalog by adding either services which are connected to a URL or catalog content that is mapped into the URL space.		:Yes. As we grow Hyrax we will need to support additional catalogs and services. Because both the BES and the OLFS can independently (and as part of their regular usage pattern) modify the catalog by adding either services which are connected to a URL or catalog content that is mapped into the URL space.

	:I guess one way to think of this is that the catalog for a particular instance of Hyrax is the ~~colection~~ of all URLs that are valid. (Where valid means that they return an HTTP status of 200.) Can't we consider the collection of URL stings to represent a tree? Doesn't it define a collection of named nodes? Some which are leaves and some which contain more stuff?		:I guess one way to think of this is that the catalog for a particular instance of Hyrax is the collection of all URLs that are valid. (Where valid means that they return an HTTP status of 200.) Can't we consider the collection of URL stings to represent a tree? Doesn't it define a collection of named nodes? Some which are leaves and some which contain more stuff?
	:--[[User:Ndp\|ndp]] 09:21, 7 March 2010 (PST)		:--[[User:Ndp\|ndp]] 09:21, 7 March 2010 (PST)
	~~</font>~~
	[[User:pwest \| Patrick]]		[[User:pwest \| Patrick]]

	[[Category:Development\|Fixing the Broken Hyrax Catalogs]][[Category:Hyrax Development\|Fixing the Broken Hyrax Catalogs]]		[[Category:Development\|Fixing the Broken Hyrax Catalogs]][[Category:Hyrax Development\|Fixing the Broken Hyrax Catalogs]]

Jimg: /* Questions */

2011-04-21T02:58:17Z

Questions

← Older revision		Revision as of 02:58, 21 April 2011
Line 109:		Line 109:
	===Questions===		===Questions===
	* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out. [<font color="red">JG: Can you remind me what the JGOFS directory holds - the catalog is the collection of served data sets, yes?</font>]		* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out. [<font color="red">JG: Can you remind me what the JGOFS directory holds - the catalog is the collection of served data sets, yes?</font>]
			* <font color="red">JG: If we do this, will the SQL handler work? Almost? (and we can change the color or these questions once you all see them... I don't wan to make it all ugly.</font>

	== Old Notes with Comments ==		== Old Notes with Comments ==

Jimg: /* Questions */

2011-04-21T02:55:09Z

Questions

← Older revision		Revision as of 02:55, 21 April 2011
Line 108:		Line 108:

	===Questions===		===Questions===
	* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out.		* Should the request for the root node include both the jgofs directory and the jgofs catalog? Would be confusing to user, so would say no. But might be a good thing if users send messages to the data admins to point this out. [<font color="red">JG: Can you remind me what the JGOFS directory holds - the catalog is the collection of served data sets, yes?</font>]


	== Old Notes with Comments ==		== Old Notes with Comments ==

PatrickWest: /* What does the Patrick do differently */

2011-04-20T23:44:24Z

What does the Patrick do differently

← Older revision		Revision as of 23:44, 20 April 2011
Line 105:		Line 105:
	* When requesting a node, if the node is in the root of the default catalog AND there's a catalog with that name, then log an error message using BESLog		* When requesting a node, if the node is in the root of the default catalog AND there's a catalog with that name, then log an error message using BESLog
	* Might want to move the catalog stuff into the bes_dispatch library instead of the bes_dap library		* Might want to move the catalog stuff into the bes_dispatch library instead of the bes_dap library
	* Might want to remove the non-catalog version of BES.RootDirectory (etc...) and just use the catalog stuff
	* In the setContainer request, look at the value of the element (the node) and see if it starts with a catalog name (if store/space="catalog")		* In the setContainer request, look at the value of the element (the node) and see if it starts with a catalog name (if store/space="catalog")

PatrickWest: /* What does the BES do differently */

2011-04-20T23:43:49Z

What does the BES do differently

← Older revision		Revision as of 23:43, 20 April 2011
Line 93:		Line 93:
	* If the first part of the node (before a slash, or whole thing if no slash) matches the name of a catalog, then use the catalog		* If the first part of the node (before a slash, or whole thing if no slash) matches the name of a catalog, then use the catalog
	* Unless where the name matches an element in the default catalog root, at which point the default catalog wins		* Unless where the name matches an element in the default catalog root, at which point the default catalog wins
	* in a setContainer request, store/space="catalog" still needs to be used ~~(unless we drop that out of the BES as well)~~		* in a setContainer request, store/space="catalog" still needs to be used
	** the value of the setContainer element needs to also be parsed to see if there is a catalog name at the front		** the value of the setContainer element needs to also be parsed to see if there is a catalog name at the front

PatrickWest: /* What does the Patrick do differently */

2011-04-20T23:42:56Z

What does the Patrick do differently

← Older revision		Revision as of 23:42, 20 April 2011
Line 104:		Line 104:
	** if there's a duplicate between the root of the default and a catalog name, leave it in. Make the admins change this		** if there's a duplicate between the root of the default and a catalog name, leave it in. Make the admins change this
	* When requesting a node, if the node is in the root of the default catalog AND there's a catalog with that name, then log an error message using BESLog		* When requesting a node, if the node is in the root of the default catalog AND there's a catalog with that name, then log an error message using BESLog
			* Might want to move the catalog stuff into the bes_dispatch library instead of the bes_dap library
			* Might want to remove the non-catalog version of BES.RootDirectory (etc...) and just use the catalog stuff
			* In the setContainer request, look at the value of the element (the node) and see if it starts with a catalog name (if store/space="catalog")

	===Questions===		===Questions===

PatrickWest: /* What does the BES do differently */

2011-04-20T23:40:25Z

What does the BES do differently

← Older revision		Revision as of 23:40, 20 April 2011
Line 93:		Line 93:
	* If the first part of the node (before a slash, or whole thing if no slash) matches the name of a catalog, then use the catalog		* If the first part of the node (before a slash, or whole thing if no slash) matches the name of a catalog, then use the catalog
	* Unless where the name matches an element in the default catalog root, at which point the default catalog wins		* Unless where the name matches an element in the default catalog root, at which point the default catalog wins
			* in a setContainer request, store/space="catalog" still needs to be used (unless we drop that out of the BES as well)
			** the value of the setContainer element needs to also be parsed to see if there is a catalog name at the front

	===What does the Patrick do differently===		===What does the Patrick do differently===

PatrickWest: /* What does the Patrick do differently */

2011-04-20T23:37:39Z

What does the Patrick do differently

← Older revision		Revision as of 23:37, 20 April 2011
Line 96:		Line 96:
	===What does the Patrick do differently===		===What does the Patrick do differently===
	* Currently, in doing ncml and jgofs work, modified the request to include a catalog="" attribute in a showCatalog request		* Currently, in doing ncml and jgofs work, modified the request to include a catalog="" attribute in a showCatalog request
			** remove this attribute
			* Somewhere (perhaps in the XML request parsing) grab the node attribute in showCatalog, grab the first part (if there is one), and see if a catalog by that name exists
			** also need to see if it's something in the root of the default catalog (SUCKS)
			* When showing the root, instead of displaying the names of the catalogs, display the root of the default catalog, and the names of the other catalogs
			** if there's a duplicate between the root of the default and a catalog name, leave it in. Make the admins change this
			* When requesting a node, if the node is in the root of the default catalog AND there's a catalog with that name, then log an error message using BESLog

	===Questions===		===Questions===