ladon-dev-team team mailing list archive
Mailing list archive
Thank Jacob, it's clear now. I think about this. Really nice idea...
2012/10/19 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
> 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
> 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 <mikhus@xxxxxxxxx>
>> 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) :
>> 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
>> 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,
>> 2012/10/18 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>>> 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:
>>> 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 : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ladon-dev-team
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~ladon-dev-team
>> Post to : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
>> 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 : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ladon-dev-team
> More help : https://help.launchpad.net/ListHelp