Start your own thread, this is not what we are discussing here.
On Tue, Jul 23, 2013 at 1:04 PM, Ido Barkan <ido(a)cloudshare.com> wrote:
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).
Do you have any better experience and/or comments about the forked projects
performance?
We think that the best performance improvement is to replace the xml parser
layer of suds with a C one.
what do you think?
was this done in one of the forked projects?
Thanks,
Ido
On Tue, Jul 23, 2013 at 12:33 PM, Mathieu Dupuy <deronnax(a)gmail.com> wrote:
>
> On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
> <jurko.gospodnetic(a)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(a)lists.fedoraproject.org
> >
https://admin.fedoraproject.org/mailman/listinfo/suds
> _______________________________________________
> suds mailing list
> suds(a)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