Hi guys,
We are currently trying to use suds and are bumping into a few performance problems.
We assume that this is largely due to the very heavy wsdl (vmware vsphere soap api).
  1. Do you have any better experience and/or comments about the forked projects performance?
  2. We think that the best performance improvement is to replace the xml parser layer of suds with a C one.
    1. what do you think?
    2. was this done in one of the forked projects?
Thanks,
Ido



On Tue, Jul 23, 2013 at 12:33 PM, Mathieu Dupuy <deronnax@gmail.com> wrote:
On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
<jurko.gospodnetic@pke.hr> wrote:
>   Hi.
>
>
>> We saw several forks :
>>
>> https://bitbucket.org/daevaorn/suds-ews/
>> suds-jurko
>> ...
>>
>> I think it would be nice to refer to the suds version to use on the
>> official suds page, and if the repository displayed on the official page
>> is no more the most accurate one, maybe list another repository in the
>> TRAC or at least add a link to the most useable suds version.
>
>
>   Not really sure if there is anyone administering the main suds project any
> more, so it becomes questionable what the 'official suds page' is or
> represents.
>
>
>
>> Currently, suds is the main SOAP Python client that we can use and
>> looking at the official page, no changes for years, it seems dead...
>> And in fact it is not...
>>
>> What could be done about this?
>
>
>   Well, I may be wrong but I do believe the SUDS project, as originally
> developed, is dead, most likely due to having a single central developer
> whose goals in life stopped including work on SUDS (and this is just me
> guessing, I have not detailed info on this).
>
>   On the other hand, the project has had a lot of quality work put into it,
> and generally 'just plain works and does what you'd like it to do'. Since
> this is so, and since Python is such a great language to hack around in -
> people find it simple to fork the project, quick-fix whatever is needed to
> satisfy their local itch, and use that. That would be my guess on why there
> are now many forks laying around.
>
>   Note that each of those forks has been prepared by different developers,
> of different skill levels and with differing goals in mind. Also, there is
> no 'central entity' in charge of synchronizing such patches ... it's a true
> bazaar... :-)
>
>   That means the whole project's future will be one of the following:
>
> 1. It dies.
>   Possible if some other usable SOAP web service calling solution becomes
> available in Python.
>
> 2. One of the forks gets enough traction by finding someone interested
> enough to back further quality work on it.
>   Always a possibility, but never a certainty - developers change interests,
> and, unless financially backed, need to spend most of their time on their
> day job whose goals may or may not coincide with working on suds, etc.
>   And if something like this does happen - there is no guarantee that the
> project does not end up in the same state as the original one at some later
> time - and possibly serves as a basis for another cycle. :-)
>
> 3. Things stay the same - we basically have one unchangeable central legacy
> suds project and lots of little forks that come and go.
>   This seems the most likely scenario for the foreseeable future. However,
> there are so many ways to use this software, so many nooks & crannies in the
> standard, so many non-standard server implementations and so many ways the
> code base needs to be updated to work with updated technologies surrounding
> it that the current state of affairs seems unlikely to work in the long run.
>
>   Well, that's my 2c worth... or more :-)
>
>   And as to the question of my own fork (suds-jurko, hosted on BitBucket),
> I'll try to describe its state, why it got started & what my hopes are for
> it in a separate thread to avoid confusing the issue in this one.
>
>   Best regards,
>     Jurko Gospodnetić

Hi.
Here my 1c:
Indeed the main suds project seems dead since 2010
I searched and look around for suds fork, and there is only two that
seem really alive :
jurko's suds : https://bitbucket.org/jurko/suds
philpem suds : https://bitbucket.org/philpem/suds
I didn't found anything else worth using it.
Both are available from pip. Philpem's is as active as Jurko's suds
is, it merges from time to time with other Suds fork with small
improvements, the kind of small (and probably dirty) fix Jurko talked
about above. Since commit messages are not really explicit, it's hard
to know what's has been done. The last commit is a rollback of the
last feature added, it doesn't make feel confident for a serious use.
In contrast Jurko's suds seems by far more professional in its
development, and for me that's the spiritual official suds
continuation.

Jurko, what about releasing the 0.4.5 ? It has been more than a year
since 0.4.4 I'm not really an advanced user user of Suds but the
library looks pretty mature. It would strengthen jurko's suds status
of unofficial continuation of suds, since the concurrence is pretty
weak. You could even regenerate the documentation and host it on a
dedicated website, and with time, you should appear first in google
when asking for "python suds".

Cheers,

>
> _______________________________________________
> suds mailing list
> suds@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
_______________________________________________
suds mailing list
suds@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds



--
Ido Barkan
SW engineer,  CloudShare

CloudShare, Ltd.
http://www.CloudShare.com
Replicate & Share Entire IT Environments, Online