Current state of suds

[Gauthier Bastien]

Hi everybody,

we currently use suds for different projects and it works as expected 
but regarding last messages on the mailing list, we wonder what is the 
current state of the project.

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.

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?

Regards,
-- 
Gauthier Bastien
<http://www.imio.be>
Zoning industriel, 34
5190 Mornimont
Tél: [phone]
Fax: [phone]
gauthier.bastien(a)imio.be <mailto:[e-mail]>
	
La mutualisation informatique
au service des pouvoirs locaux

[Jurko Gospodnetić]

   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ć

[Mathieu Dupuy]

On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
<jurko.gospodnetic(a)pke.hr&gt; 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

[Ido Barkan]

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(a)gmail.com&gt; wrote:

>  On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
>  <jurko.gospodnetic(a)pke.hr&gt; 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

[Mathieu Dupuy]

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&gt; 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&gt; wrote:
> >
> > On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
> > <jurko.gospodnetic(a)pke.hr&gt; 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

[Victor Varvaryuk]

Hi, Jurko!
What about merging this: https://fedorahosted.org/suds/ticket/353

Victor

On 23.07.2013 13:33, Mathieu Dupuy wrote:
>  On Thu, Jun 13, 2013 at 12:27 PM, Jurko Gospodnetić
>  <jurko.gospodnetic(a)pke.hr&gt; 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