Comparison with rpclib

Asked by Burak Arslan

Hello,

I've been working on rpclib, which is almost the same project as ladon, just a bit more mature from the looks of it. I'm currently working on 2.x series documentation. In the comparison section, here's what I'm going to say about ladon:

* Supports JsonRPC, JsonWSP(Author's response to the inadequacies of JsonRPC), which rpclib does not support.
* Does not support ZeroMQ (rpclib supports both client and server)
* Uses standard python tools for xml parsing (Rpclib uses lxml, due to its excellent namespace support and speed) which is good for pure-python deployments.
* Does not do input validation. (Rpclib does schema validation)
* Does not support events.
* Does not support HttpRpc (Rest-ish protocol implemented by Rpclib author)
* Does not have a Soap client.
* Rpclib uses own classes for denoting types, whereas ladon uses python callables. This lets ladon api to be simpler, but gives the rpclib api the power to have declarative restrictions on input types.
* Does not test against ws-i.org deliverables for testing soap compatibility.

I also have some questions:
1) Does it provide an api for implementing own transports and/or protocols?
2) Does it support modifying protocol & transport headers for input & output? (e.g. soap headers and/or http headers)

Maybe we could collaborate. It'd be a waste of time and effort to keep the two projects separated.
1) Would you be interested in writing interop tests for rpclib?
2) Would you be interested in contributing a JsonWSP protocol for rpclib?
3) Will you work on a soap client that parses wsdl? If so, let me know.
4) Will you work on Soap 1.2/Wsdl 2.0 spec? If so, let me know.

Also fyi, <email address hidden> a forum for soap implementors in python. You're invited to join there.

So, what do you think about rpclib compared to ladon?

Best,
Burak

Question information

Language:
English Edit question
Status:
Solved
For:
ladon Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
jsgaarde (jakob-simon-gaarde) said :
#1

Hi Burak.

That was a lot at once :-) I will get back to you tonight (CET), I am at work right now.

Best Regards
Jakob Simon-Gaarde

Revision history for this message
Burak Arslan (burak+lp) said :
#2

Hello Jakob,

No worries ;) Be sure to get latest docs from http://github.com/plq/rpclib. They're still under heavy development.

git clone git://github.com/plq/rpclib.git
cd rpclib
make -C doc html
firefox doc/build/html/index.html

burak

Revision history for this message
jsgaarde (jakob-simon-gaarde) said :
#3

> Hello,

> I've been working on rpclib, which is almost the same project as ladon,
> just a bit more mature from the looks of it. I'm currently working on
> 2.x series documentation. In the comparison section, here's what I'm
> going to say about ladon:

Matureness can be measured in many ways :-) My guess is that rpclib is more mature in some aspects and Ladon is more mature in other aspects. For instance Ladon runs on both Python 2 and Python 3 as far as I can see rpclib is limited to Python 2 - just to mention an aspect where Ladon is more mature.

My comment to your comparison bullets:

> * Supports JsonRPC, JsonWSP(Author's response to the inadequacies of
> JsonRPC), which rpclib does not support.
(True)
Remarks: The main motive for designing JSON-WSP was the need for a JSON-based RPC protocol with a service description specification with built-in service/method documentation.

> * Does not support ZeroMQ (rpclib supports both client and server)
(True)
Remarks: I must admit I didn't know ZeroMQ - looks very cool, and might be something I want to integrate later on. So for now Ladon is a TCP/WSGI based application.

> * Uses standard python tools for xml parsing (Rpclib uses lxml, due
> to its excellent namespace support and speed) which is good for
> pure-python deployments.
(True)
For the small part of Ladon that represents the SOAP protocol. Xml is not used internally in the Ladon framework.

> * Does not do input validation. (Rpclib does schema validation)
(True)
I'm guessing you mean incomming SOAP requests. Instead we try to be tolerant to bad XML cause there was some complaints about specific SOAP clients not honoring the specification completely.

> * Does not support events.
Can you explain what events are? I can't find anything about it in the docs.

> * Does not support HttpRpc (Rest-ish protocol implemented by Rpclib author)
(True)
Remarks: It will before the end of 2011, it is a top priority.

> * Does not have a Soap client.
(True)
Remarks: Ladon is pure server-side software - the whole idea of supporting a standard protocol like SOAP is that clients are already out there. That being said Ladon does provide client software for JSON-WSP (Python/JavaScript) because that is a relatively new protocol, and I have only found one other JSON-WSP client implementaion out there. We have planned to make JSON-WSP client support for C++ also before the end of 2011 - and bindings from the C++ implementation to several other languages. We hope to see JSON-WSP grow in popularity cause it is a cool protocol which is very powerful if you want to communicate directly from a browser application (client-side) to your webservice.

> * Rpclib uses own classes for denoting types, whereas ladon uses
> python callables. This lets ladon api to be simpler, but > gives
> the rpclib api the power to have declarative restrictions on input
> types.
(True)
Remarks: But declarative restrictions (value based validation) can easilly be integrated into Ladon. Ladon using python's built-in types does not prevent us from doing this. Ladon operates with a so-called ServiceCollection where all information about service classes and exposed methods are stored, we can pretty effortless add the possibility to hook value based validation callbacks via the ladonize decorator.

> * Does not test against ws-i.org deliverables for testing soap
> compatibility.
(True)

> I also have some questions:
> 1) Does it provide an api for implementing own transports
> and/or protocols?
As I mentioned earlier, Ladon is only WSGI based for now, and there is no api for creating new transports. As for protocols, yes there is an API (unfortunately almost undocumented for now) http://packages.python.org/ladon/extending.html

> 2) Does it support modifying protocol & transport headers
> for input & output? (e.g. soap headers and/or http headers)
I haven't identified a reason to why you would want to do modification of incomming requests?
For output the answer is yes. It is a new class (not commit'ed yet) called CustomResponse. You can apply CustomResponses on method level and have full control over both headers and data.

> Maybe we could collaborate. It'd be a waste of time and effort
> to keep the two projects separated.
> 1) Would you be interested in writing interop tests for rpclib?
Please can you elabourate?

> 2) Would you be interested in contributing a JsonWSP protocol
> for rpclib?
It sounds tempting, but I have a full-time job, the Ladon project, kids and a wife - so it can be hard to find time. I am not dismissing it, just noting that I have limited time-resources ;-)

> 3) Will you work on a soap client that parses wsdl? If so, let
> me know.
I can say no to this right away :-) There are plenty of SOAP clients already.

> 4) Will you work on Soap 1.2/Wsdl 2.0 spec? If so, let me know.
I am hoping that the community will help with that in time, some people have expressed the possibility of helping out.

> Also fyi, <email address hidden> a forum for soap implementors in
> python. You're invited to join there.
Sounds like a good idea - thanks for the invitation :-)

> So, what do you think about rpclib compared to ladon?
I do not have a complete overview over rpclib. But from what I have seen in the source code it looks well written and well documented. And indeed rpclib is better on the transport aspect.

Here are some things I think you should remember to mention about Ladon in your comparison:
* Auto-generates browsable API documentation ( example: http://ladonize.org/python-demos/AlbumService )
* Supports both Python 2 and Python 3
* Serves up all protocols at once on same port (see the example above)
* Makes string encoding operations easy (You can control on method level whether you want all strings delivered as unicode or as str in a specific encoding)

(I haven't been able to check whether rpclib supports all, some or none of the bullets, maybe you can respond to this)

Best regards
Jakob Simon-Gaarde

Revision history for this message
Burak Arslan (burak+lp) said :
#4

Hi Jakob,

Thank you very much for your detailed response.

On 09/21/11 12:20, jsgaarde wrote:
> Your question #171664 on ladon changed:
> https://answers.launchpad.net/ladon/+question/171664
>
> jsgaarde proposed the following answer:
>> Hello,
>
>> I've been working on rpclib, which is almost the same project as ladon,
>> just a bit more mature from the looks of it. I'm currently working on
>> 2.x series documentation. In the comparison section, here's what I'm
>> going to say about ladon:
>
> Matureness can be measured in many ways :-) My guess is that rpclib is
> more mature in some aspects and Ladon is more mature in other aspects.
> For instance Ladon runs on both Python 2 and Python 3 as far as I can
> see rpclib is limited to Python 2 - just to mention an aspect where
> Ladon is more mature.
>

All I said was Rpclib *looked* a bit more mature to the eyes of an outsider. E.g. code history goes back to 2007, its ohloh page is maintained, has more documentation, has ~10 people who have contributed code some time in the past, integrates with more packages etc.

> My comment to your comparison bullets:
>
>> * Does not do input validation. (Rpclib does schema validation)
> (True)
> I'm guessing you mean incomming SOAP requests. Instead we try to be tolerant to bad XML cause there was some complaints about specific SOAP clients not honoring the specification completely.

in fact, validation is optional with rpclib.

>> * Does not support events.
> Can you explain what events are? I can't find anything about it in the docs.
>

demo: https://github.com/arskom/rpclib/blob/master/examples/events.py
practical: http://arskom.github.com/rpclib/manual/sqlalchemy.html

>> * Rpclib uses own classes for denoting types, whereas ladon uses
>> python callables. This lets ladon api to be simpler, but > gives
>> the rpclib api the power to have declarative restrictions on input
>> types.
> (True)
> Remarks: But declarative restrictions (value based validation) can easilly be integrated into Ladon. Ladon using python's built-in types does not prevent us from doing this. Ladon operates with a so-called ServiceCollection where all information about service classes and exposed methods are stored, we can pretty effortless add the possibility to hook value based validation callbacks via the ladonize decorator.

For example in rpclib, you can do this:

DomainType = String(pattern=r'([a-z0-9_-]+\.)+[a-z0-9]+')

and then use this new type anywhere. E.g.

class Company(ComplexObject):
    domain_name = DomainType
    company_name = String(max_len=256)

etc.

Can you give the equivalent example in ladon?

>
>> * Does not test against ws-i.org deliverables for testing soap
>> compatibility.
> (True)
>
>> I also have some questions:
>> 1) Does it provide an api for implementing own transports
>> and/or protocols?
> As I mentioned earlier, Ladon is only WSGI based for now, and there is no api for creating new transports. As for protocols, yes there is an API (unfortunately almost undocumented for now) http://packages.python.org/ladon/extending.html
>
>> 2) Does it support modifying protocol & transport headers
>> for input & output? (e.g. soap headers and/or http headers)
> I haven't identified a reason to why you would want to do modification of incomming requests?

Don't forget that rpclib works both ways. You may want to set request headers in clients.

> For output the answer is yes. It is a new class (not commit'ed yet) called CustomResponse. You can apply CustomResponses on method level and have full control over both headers and data.

This also includes parsing of soap request headers, yes? i.e. the data under <SOAP-ENV:Header> tag.

>
>> Maybe we could collaborate. It'd be a waste of time and effort
>> to keep the two projects separated.
>> 1) Would you be interested in writing interop tests for rpclib?
> Please can you elabourate?
>

e.g. to test rpclib soap client works with ladon soap server.

>> 2) Would you be interested in contributing a JsonWSP protocol
>> for rpclib?
> It sounds tempting, but I have a full-time job, the Ladon project, kids and a wife - so it can be hard to find time. I am not dismissing it, just noting that I have limited time-resources ;-)

sure :) support by more libraries would be another factor that'd help JsonWSP adoption, and support for more protocols would help rpclib adoption. if you decide to attempt this, i'd like to help you.

>> So, what do you think about rpclib compared to ladon?
> I do not have a complete overview over rpclib. But from what I have seen in the source code it looks well written and well documented. And indeed rpclib is better on the transport aspect.

thank you. it was very fun to work on, and I'm glad to hear positive things from someone who works on a similar project.

>
> Here are some things I think you should remember to mention about Ladon in your comparison:
> * Auto-generates browsable API documentation ( example: http://ladonize.org/python-demos/AlbumService )

Hey that's neat! I'm going to steal this :)

> * Serves up all protocols at once on same port (see the example above)

You can do this with rpclib with http as well, it's just not implicit. I should write an example illustrating how to do this.

> * Makes string encoding operations easy (You can control on method level whether you want all strings delivered as unicode or as str in a specific encoding)

Rpclib doesn't offer anything specially for this purpose, but then the procotol implementors have the power to do as they want. In rpclib, we have a String class, which is always a unicode object, and ByteArray which is always an iterable of str objects.

Revision history for this message
Burak Arslan (burak+lp) said :
#5

Here's the initial revision: https://github.com/plq/rpclib/blob/master/doc/source/comparison.rst

I omitted non-released or experimental features like rpclib's sqlalchemy support or ladon's header parsing support.

again, thank you for your cooperation.

Revision history for this message
jsgaarde (jakob-simon-gaarde) said :
#6

Hi Burak.

No problem :-) I hope we can cooperate later on when I have time to get back to work on Ladon. Right now I am very busy at work. Btw: Well-written comparison.

Best Regards Jakob Simon-Gaarde

Revision history for this message
jsgaarde (jakob-simon-gaarde) said :
#7

The comparison has been written

Revision history for this message
jsgaarde (jakob-simon-gaarde) said :
#8

"Does not do input validation for SOAP"

Ladon now provides the new filtering feature which allows the service developer to inject functions for value validation or modification at 4 different stages of an RPC process:

1. incoming_raw (before request arguments have been converted to python types)
2. incoming (after the request arguments have been converted)
3. outgoing (after method invokation, before conversion from python type to protocol response object)
4. outgoing_raw (After converting value to protocol response object)

You can add as many filters as you want to each stage.

Best Regards
Jakob Simon-Gaarde

Revision history for this message
Burak Arslan (burak+lp) said :
#9

Hello Jakob,

Howdy :)

I'm still subscribed to this thread, so if you need the comparison document updated in any way, let me know.

I'm currently in the process of finalizing the documentation for spyne, (I renamed rpclib to spyne btw) so you can find the latest doc here: https://github.com/arskom/spyne/blob/master/doc/source/comparison.rst#ladon

Best,
Burak