[Mapbender_dev] User Story 1: Publishing a service

Armin Retterath armin.retterath at lvermgeo.rlp.de
Tue Jun 8 04:48:36 EDT 2010


hi vikas,

if you have further questions about the module, please ask.
i think i can answer them without bigger problems ;-).

armin

Am Dienstag 08 Juni 2010 10:38:14 schrieb Vikas Banjara:
> Hi Armin,
>
> Thanks for pointing this to me. I will go through it. There is no english
> version of this page. but thanks to Google translate :-)
>
> 2010/6/8 Armin Retterath <armin.retterath at lvermgeo.rlp.de>
>
> > hi vikas,
> >
> > the authentication should be done as a digest authentication. we have an
> > authentication module to secure the registrated service as an ows proxy.
> > the
> > digest hashes for all users are already stored in the mapbender mb_user
> > table
> > since 2.7 (trunk)
> > see
> > http://www.mapbender.org/Http_auth
> >
> > regards
> > armin
> >
> > Am Montag 07 Juni 2010 21:36:28 schrieb Vikas Banjara:
> > > 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
> >
> > --
> > Im Auftrag
> > --
> > Armin Retterath
> >
> > Kompetenz- und Geschäftsstelle Geodateninfrastruktur Rheinland-Pfalz
> > beim
> > Landesamt für Vermessung und Geobasisinformation Rheinland-Pfalz
> >
> > Ferdinand-Sauerbruch-Straße 15
> > 56073 Koblenz
> > Telefon 0261/492-466
> > Telefax 0261/492-492
> > armin.retterath at lvermgeo.rlp.de
> > http://www.geoportal.rlp.de
> > _______________________________________________
> > Mapbender_dev mailing list
> > Mapbender_dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapbender_dev



-- 
Im Auftrag
--
Armin Retterath

Kompetenz- und Geschäftsstelle Geodateninfrastruktur Rheinland-Pfalz
beim
Landesamt für Vermessung und Geobasisinformation Rheinland-Pfalz

Ferdinand-Sauerbruch-Straße 15
56073 Koblenz
Telefon 0261/492-466
Telefax 0261/492-492
armin.retterath at lvermgeo.rlp.de
http://www.geoportal.rlp.de


More information about the Mapbender_dev mailing list