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
