[Mapbender_dev] User Story 1: Publishing a service

[Seven (aka Arnulf)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vikas Banjara wrote:
> Hi all,
> 
> I will try to write a flow of steps for the use case. Please correct me
> wherever I am wrong.

Hi Vikas,
I will answer inline and as approprite update the Wiki in parallel. It
was suggested that we need to be more wordy when describing the user
stories. What is your opinion? Can you understand what the user wants to
do? Would a more detailed description help to understand better?

One important thing I did not mention yet is that we should always keep
in mind that the "user" we are talking about can also be a "user agent".
This means it can well be a machine! This is important to keep in mind.
Especially the more complex issues regarding monitoring, usage of RSS
and anything that can be automized will be highly relevant for machine
to machine communication.


More answers to your questions inline. All cases that I do not comment I
assume that we are thinking along the same lines.

> On Tue, Jun 1, 2010 at 10:26 PM, Arnulf Christl <
> arnulf.christl at metaspatial.net> wrote:
> 
> Hi Vikash,
> here goes the first try for a user story:
> 
> User finds a new service / creates a new service and wants to publish
> it. All that is needed to register a new service is a user name
> (authentication) with email for confirmation, the Capabilities URL of
> the service and whether it should be public.
> 
> 
>> First the user needs to authenticate himself using a username/password. For
>> this I am working on plain http authentication with the mapbender server.

For a start that is OK. Later we might want to look into how we can make
the authentication more persistant (see also: user agent / machine
scenario).

>> The registering of a new service is a Create operation. So, it should be a
>> POST operation. And the URI should be like this  (assuming that the url of
>> the mapbender server is www.mapbender.org) -
>> http://www.mapbender.org/resources/resourceID
> 
>> So to post this user would send four parameters username, email id and
>> capabilities url and public/private status of the service.
> 
> 
> 
> Q: What happens if this URL (or a similar one?) has already been
> uploaded earlier? Add a counter for the the same URL (uploaded several
> times)?
> A: The Capabilities URL needs to be checked against the ones already in
> the database. -> What happens then?
> 
> 
>> In case, the capabilities URL already exists, we can send an error to the
>> user saying that it already exists.

The response (artefact: "Representation returned to the client") should
include option of how to continue processing. That could be the link to
the existing resource and maybe one to the "Update" REST interface.

> Q: What happens if the user gets "lost", is deleted, etc.?
> A: ?

A user can be deleted from the Mapbender database. What happens to the
"owner" of the resource in that case? We could trigger an SQL cascade
DELETE on the database but in my opinion it would be nicer to keep
resource URL even if the owner disappears. We could introduce a garbage
or public user for those cases but then must take care that we do not
get mixed up with permissions and the security proxy.

>> I didn't really get this?
> 
> 
> Q: What happens if the service is deleted by another user? (This is
> currently not possible, it would generate an error message).
> 
> 
> 
> 
> Q: What happens if Mapbender cannot read the capabilities document?
> A: Error message & ?
> 
> 
> 
>> Again can you explain me this?

An example might help:
This URL delivers an OGC WMS Capabilities Document that Mapbender can
parse and store in the database:
http://demowms.fossgis.de/wms/simple?SERVICE=WMS&REQUEST=GetCapabilities
(even although the URL misses the parameter VERSION=x.x.x)

This URL on the other hand does not deliver an OGC WMS Capabilities
Document that Mapbender can parse:
http://gdz.bkg.bund.de/wms_dtk25&v_service=wms&response_xml=wms_dtk25

In my opinion it (should) return a 401 or 403 but instead sends a 200
(OK) and then says in the XML that it returns that it is not OK. We will
have lots of confusing response codes but should therefore still not
ignore them but make as best use of them as we can.

Find more examples of working OGC WMS URLs from this page:
http://www.mapbender.org/Test

Please add to this list when you find an interesting or "strange" OGC
service.

> Q: Are we going to use this "interface" also to update services or do we
> need to create another one?
> A: ?
> 
> 
>> To update the service we need to create a separate interface. And that would
>> be using PUT HTTP command.

Yes. This "interface" (or is it not rather a resource too?) should be
included in the response to a request that wants to create a resource
that already exists.

Best regads,
Arnulf


> We add these User Stories to the Wiki so that we can refine them there:
> http://www.mapbender.org/Talk:RESTful_API
> 
> 
> Best regads,
> Arnulf.
> 
> 
> 
> 
> 
_______________________________________________
Mapbender_dev mailing list
Mapbender_dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>

> ------------------------------------------------------------------------

> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev


- --
Arnulf Christl

Exploring Space, Time and Mind
http://arnulf.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwI+pgACgkQXmFKW+BJ1b1f/QCdHo3nhNjsyHz5zL7NTex4V0Of
EpYAmwT9+AN+PRg1maCj82wRaZvSqUPj
=x4Hb
-----END PGP SIGNATURE-----