Thank Jacob, it's clear now. I think about this. Really nice idea...
2012/10/19 Jakob Simon-Gaarde <[email protected]> > OK I can understand why it's not that easy to see the idea from my initial > description of 1) > > The "Task" type should give the possibility to implement a method in the > "standard" way which spawns a subprocess (kind of a asynchronious method). > So you can start the "time-consuming" method and get a response > immediately. But the response is merely a reference to the task you just > started. Your application can then "forget" about the final result for the > time being and start polling for progress via the auto-expanded _status() > method. The task is run in the background and when it finishes, the > _result() will give whatever rtype your task-type method was defined to > return. > > If we can standardise this type of methods we will have Ladon leaping > ahead of all other web service frameworks I know of. > > I hope this clarifies the intention a bit :-) > > / Jakob > > > > > 2012/10/18 Mykhailo Stadnyk <[email protected]> > >> 1. Not very clear for me how the _status() and _result() methods >> implementation would be done. I mean that when I creating such methods >> manually I define the implementation myself. Like in my app there could be >> defined my own list of status and I decide which status to return. >> Than what is result? Do we need to define specific type object which >> would be served by these methods, like: >> >> class TimeConsumingTask(LadonType) : >> id >> arg1 >> arg2 >> status >> result >> etc.. >> >> Maybe you can explain your idea a bit widely, because as for me it's hard >> to catch the details... >> >> 2. Selenium? >> >> 3. roger currently working on implementation of JSON-RPC versions 1.0 and >> 2.0 (He currently has something near ready for 1.0, but is managed to >> implement testing first. So, hopefully, he will try to contribute something >> in a near future). However, I can assume only XML-RPC implementation then. >> Do you have anymore ideas about the protocols? >> >> About REST. I didn't investigated yet deeply if there is an ability to >> add support of this protocol into ladon, but theoretically I have the >> following idea. >> The problems as for me: >> - Only service designed to be RESTful could be accessed via REST. >> Means, that each service developer should take initial decision if his >> service would be restful or not WHEN HE DESIGN his service. >> - It is possible to map REST into SOAP, but not vice-versa. So if >> your service was designed as SOAP which could have any methods doing any >> job, it becomes >> impossible to map such service to REST, because each REST service >> provides only 4 methods which are strictly mapped into HTTP requests: >> * create (PUT) >> * read (GET) >> * update (POST) >> * delete (DELETE) >> So implementation of REST support in ladon CAN NOT be done via >> implementation of ladon.interfaces, because the handling of RESTful >> requests should be done on HTTP level. >> >> My concern to the possible decision: >> Lat's imagine that ladon provides a special class decorator @restful >> which marks a service object to be handled as restful. Here the object name >> should be found via HTTP request URL and an associated to the request type >> method should be called (so we need some extension to wsgi part of the >> ladon) >> >> What does it mean at the end? >> a) @restful should check if service object designed in a right manner >> (only 4 RESTful methods) >> b) User MUST understand that if he want to map existing >> SOAP/JSONWSP/etc service to REST is NOT POSSIBLE if service was not >> initially designed RESTful >> c) Services with RESTful design becomes available through other >> protocols, which implemented in ladon >> >> Please, let me know your thoughts >> >> Best regards, >> Mike >> >> 2012/10/18 Jakob Simon-Gaarde <[email protected]> >> >>> Here are some of the thoughts I have for the roadmap: >>> >>> 1. Task-Type methods. >>> Long ago I decided that Task-Type methods would be the feature to >>> round-up Ladon version 1.0.0. Task-Type methods are as the name implies the >>> ability to mark methods as tasks via the ladonize decorator. These methods >>> will automatically resolve into 3 methods. So if we have the method: >>> doMyTimeConsumingTask(self,arg1,arg2) >>> >>> it will expand to something like: >>> >>> 1. doMyTimeConsumingTask(self,arg1,arg2) >>> 2. doMyTimeConsumingTask_status(self, taskid) >>> 3. doMyTimeConsumingTask_result(self,taskid) >>> >>> 2. Integrated service testing via webbrowser input forms. >>> >>> 3. More protocols >>> >>> 4. Better documentation >>> >>> -- >>> Med venlig hilsen / Best regards >>> Jakob Simon-Gaarde >>> >>> -- >>> Mailing list: https://launchpad.net/~ladon-dev-team >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~ladon-dev-team >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> -- >> Mailing list: https://launchpad.net/~ladon-dev-team >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~ladon-dev-team >> More help : https://help.launchpad.net/ListHelp >> >> > > > -- > Med venlig hilsen / Best regards > Jakob Simon-Gaarde > > -- > Mailing list: https://launchpad.net/~ladon-dev-team > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ladon-dev-team > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~ladon-dev-team Post to : [email protected] Unsubscribe : https://launchpad.net/~ladon-dev-team More help : https://help.launchpad.net/ListHelp
