ladon-dev-team team mailing list archive

[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