petascope service identification and provider should be configurable in a file

[Vlad Merticariu]

Currently, in order to change the service identification and the service provider in petascope one has to edit the entries in petascopedb, tables ps_service_provider and ps_service_identification.

One of ECMWF's requests is to be able to change this easier, for example by editing a file. I'm thinking about adding this information in a file such as petascope_service.properties.

[Bang Pham Huu]

Hi Vlad, I can handle this as we can make a configuration file as you proposed, so we have a 1 file for this configuration and 1 file (I prefer python scrip named update_petascope_info.py to do this).

I suppose they just want to change some main information as default Petascope. However, I just tried to add all the fields in 3 tables ps_service_provider, ps_service_identification and ps_description) and the output from Petascope webpage is below.

I can see difficulty in here when user want to change Role and Telephone as it is 'Foreign Key' to ps_role_code and ps_telephone respectively. The role table has 11' role value so user could just type one of 11 name then it is done by return the id of 'role name' but the telephone is not easy as it need add a new entry and return the Primary Key to table ps_service_provider.

What do you think, should we allow to config most values or just some basic value as default of Petascope when install?

Service identification

Title:
	rasdamanabcdef
Abstract:
	rasdaman server - free download from www.rasdaman.org + bangph.org

# Should we allow to change title and abstract?

Fees:
	abcdef
Fees:
	'no contraisnt'
Service type:
	OGC WCS
Service type version:
	2.0.1

Service Provider

Provider name:
	Jacobs University Bremen
Provider site:
	http://rasdaman.org/
Contact person:
	Prof. Dr. Peter Baumann
Position name:
	Project Leader
Role:
	pointOfContact   
# (it has 11 role name, we can allow user define a new Role as 'service centre' 
or 'service process'....).

Hours of service:
	hours_of_service
Contact instructions:
	instructions
City:
	Bremen
Postal code:
	28717
Administrative area:
	administrative_area1, Bremen
Country:
	Germany
Electronic mail address:
	b.phamhuu@jacobs-university.de3 p.baumann@jacobs-universit.de
Telephone:
	abccdefef 3423423423
Facsimile:
	asdsadsaDAD 234234234

[Vlad Merticariu]

Hi Bang,

Thanks for taking up this task.

In my opinion, adding another script is not optimal, we are trying to move away from this as it creates maintenance problems down the road.

I see 2 possible solutions:

1. Add a new section in the petascope.properties file, that contains the information about the service provider. Then, when petascope is started the information is read in ConfigManager, from where it is fed in the Capabilities document when requested.

2. Keep the information in the database, but make it editable in the WCS client via a form. This would mean adding basic authentication for some parts of the WCS client first.

I am in favor of option 2 if we want to move towards making the WCS client the main user interface to petascope. Adding the other guys on cc to listen to further opinions.

[Peter Baumann]

good discussion! I wouldn't see our WCS client as the main interface: (i) it is addressing WCS only, not WMS; (ii) we are far from having a solid authentication concept.
That said, on principle I like the idea of having relevant data in the database and not in config files. And we already have entries in the database, and removing this is a harsh step either. OTOH, a database solution comes at the cost of an extra editing client API + web interface, and I just don't see resources available.
So we are between a rock and a hard place.

Hm, option 3: we provide a request type UploadCapabilities which accepts an XML file with the provider section (AFAIK it comes from OWS Common, so its structure should be shared among all services). A GetCap request then would deliver the full Cap document, which gets completed individually for WCS and WMS.

• pro: simple(r) for us to implement; security is a cncern not more or less than WCS-T and can be handled with the same methods (protecting the request in Apache etc).
• con: XML is unwieldy for users

Opinions?

[Bang Pham Huu]

I'll update the solution as Dimitar has suggested.

+ A web page in rasdaman/admin will prompt user with username and password to login (this is the petauser and petapasswd in petascope.properties). Alternatively, using the credential that petascope using.

+ A java servlet will control the process of user (login, edit the service identifier and provider information) and upate to petascopedb. Again, using petascope's functionality to update to petascopedb.

+ The GUI should be used as petascope WCSClient (I'm doing it as it just using CSS, Javascript from WCSClient) and it is much friendlier with user without understanding JSON, XML or web services. Also with session in Java Servlet, it will refresh these information in WCSClient immediately without need to restart Web Application.

[Bang Pham Huu]

close ticket here as patch was accepted.