ladon-dev-team team mailing list archive

[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
>
>