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) <[email protected]> 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 < > > [email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapbender_dev > >> > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > Mapbender_dev mailing list > > [email protected] > > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapbender_dev >
_______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
