[Mapbender_dev] User Story 1: Publishing a service

Mon Jun 7 15:36:28 EDT 2010

Hi all,

First of all, sorry for not attending the IRC meeting today. There was a
power cut in our city today. And the laptop battery was drained.

Now coming to the progress of the project. I have started writing
authentication code. I will commit the code after I have done with the
authentication module.

Discussion about the use case inline -

On Fri, Jun 4, 2010 at 6:37 PM, Seven (aka Arnulf) <seven at arnulf.us> wrote:

> -----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.
>

Yeah, user stories and the following discussion should be as wordy as
possible. Also, I am keeping in mind the fact that "user" will actually be a
machine. And we are writing code for machine-machine interaction.
I will take care of RSS usage.

>
>
> 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).
>
>
What do you mean by user agent/machine scenario authentication? IP based
authentication?

> >> 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.
>

Point noted.

>
> > 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 guess this is not really a part of api. This is a part of mapbender core
feature. Am I correct?

>
> >> 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.
>

I will compile a list of response codes in the wiki page.

>
> > 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.
>

Yeah, as you mentioned above also.

>
> Best regads,
> Arnulf
>

So, if everything is ok. I will write a set of conclusions for this
discussion in my next mail and will also compile it in the wiki page. And
then we can start with next user story.

Regards
Vikas

>
>
> > 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-----
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20100608/dc01143d/attachment.html