ladon-dev-team team mailing list archive

[Mykhailo Stadnyk <mikhus@xxxxxxxxx>]

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
> 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 <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) :
>>     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 <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:
>>> 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     : 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
>
>