RPC server implemented using Python (Cherrypy)

[delaney]

I noticed there is no is no official Python server so I made an initial stab at creating one using the awesome and fast http cherrypy server (www.cherrypy.org).  Created with svn trunk of cherrypy but 3.1 should work as well.  Obviously my tests need work but I implemented everything on http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made a bitbucket project for it at http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or thoughts for this are welcomed.

~Delaney

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[omicron-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

See this project : http://en.letras.ru/2009/01/qooxdoo-controller-for-cherrypy

Jacques

Delaney Gillilan a écrit :

I noticed there is no is no official Python server so I made an initial stab at creating one using the awesome and fast http cherrypy server (www.cherrypy.org).  Created with svn trunk of cherrypy but 3.1 should work as well.  Obviously my tests need work but I implemented everything on http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made a bitbucket project for it at http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or thoughts for this are welcomed.

~Delaney

------------------------------------------------------------------------------
  

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
  

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Andreas Ecker-2]

Howdy!

On Wed, 2009-06-24 at 07:53 +0200, Jacques Bousseau wrote:

> See this project :
> http://en.letras.ru/2009/01/qooxdoo-controller-for-cherrypy
>
> Jacques
>
> Delaney Gillilan a écrit :
> > I noticed there is no is no official Python server so I made an
> > initial stab at creating one using the awesome and fast http
> > cherrypy server (www.cherrypy.org).  Created with svn trunk of
> > cherrypy but 3.1 should work as well.  Obviously my tests need work
> > but I implemented everything on
> > http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made
> > a bitbucket project for it at
> > http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or
> > thoughts for this are welcomed.

Seems there is quite some effort to implement Python RPC solutions for
qooxdoo. Besides the two approaches mentioned here there is the
original, "official" implementation by Viktor Ferenczi, see
http://qooxdoo.org/documentation/0.8/rpc_python

I'd like to have Viktor on board as the creator of the original
qooxdoo/Python RPC solution, as he's always had many ideas to improve
the current solution but lacking time/resources. Also Thomas (at least
as an observer/supporter) as he's maintaining and advancing the
Python-based qooxdoo tool chain.

It would be great the qooxdoo/Python devs would enjoy to collaborate in
providing an up-to-date RPC solution. This could also ensure the project
kept being actively maintained and not going stale. Is there more than
one environment to target (e.g. built around Cherry.py or not), which
would mean more than on project?

Let's see what the technical discussion leads to (for now I'd suggest to
use the mailinglist for discussion, not a dedicated enhancement request
in bugzilla). Whatever the proposals might be, I can well envision to
start to host and incubate at least one such project as a contribution
in qooxdoo-contrib.

qooxdoo/Python people speak up!   ;-)

Andreas

--
Andreas Ecker
Project Lead
http://qooxdoo.org



------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Burak Arslan-4]

Andreas Ecker wrote:
> qooxdoo/Python people speak up!   ;-)
>
>  

i keep repeating this but here it is again: i got a soap-rpc server in
the soap contrib.
http://qooxdoo.org/contrib/project#soap

it uses soaplib-lxml.
http://github.com/plq/soaplib-lxml

btw, http://qooxdoo-contrib.sf.net has a bad link.

best regards,
burak

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

In my opinion the biggest issue with Python RPC is that so far nobody
undertook the (rather limited) effort of creating a corresponding
contribution in qooxdoo-contrib, for whatever reasons. Doing so would
both improve visibility to the community (so people use it) and the
chances of multiple people maintaining the code (so we could have a
common effort to create a good and usable Python backend; the
corresponding Php solution shines in that regard).

But as things are, now three different implementations surface, by
different people, in different repositories, and at different levels of
currentness and completeness. I don't care if a contrib is called
RpcPython or RpcPythonCherrypy or something else, as long as it gets in.
But of course the original authors have to make the first step.

Just my 2 cent.

Thomas


Andreas Ecker wrote:

> Howdy!
>
> On Wed, 2009-06-24 at 07:53 +0200, Jacques Bousseau wrote:
>  
>> See this project :
>> http://en.letras.ru/2009/01/qooxdoo-controller-for-cherrypy
>>
>> Jacques
>>
>> Delaney Gillilan a écrit :
>>    
>>> I noticed there is no is no official Python server so I made an
>>> initial stab at creating one using the awesome and fast http
>>> cherrypy server (www.cherrypy.org).  Created with svn trunk of
>>> cherrypy but 3.1 should work as well.  Obviously my tests need work
>>> but I implemented everything on
>>> http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made
>>> a bitbucket project for it at
>>> http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or
>>> thoughts for this are welcomed.
>>>      
>
> Seems there is quite some effort to implement Python RPC solutions for
> qooxdoo. Besides the two approaches mentioned here there is the
> original, "official" implementation by Viktor Ferenczi, see
> http://qooxdoo.org/documentation/0.8/rpc_python
>
> I'd like to have Viktor on board as the creator of the original
> qooxdoo/Python RPC solution, as he's always had many ideas to improve
> the current solution but lacking time/resources. Also Thomas (at least
> as an observer/supporter) as he's maintaining and advancing the
> Python-based qooxdoo tool chain.
>
> It would be great the qooxdoo/Python devs would enjoy to collaborate in
> providing an up-to-date RPC solution. This could also ensure the project
> kept being actively maintained and not going stale. Is there more than
> one environment to target (e.g. built around Cherry.py or not), which
> would mean more than on project?
>
> Let's see what the technical discussion leads to (for now I'd suggest to
> use the mailinglist for discussion, not a dedicated enhancement request
> in bugzilla). Whatever the proposals might be, I can well envision to
> start to host and incubate at least one such project as a contribution
> in qooxdoo-contrib.
>
> qooxdoo/Python people speak up!   ;-)
>
> Andreas
>
>  

--
Thomas Herchenröder
Development Technology & Architecture - Web Technologies

1&1 Internet AG       phone: [phone]
Ernst-Frey-Str.9      web  : www.1und1.de    
76135 Karlsruhe              qooxdoo.org

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler,
Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren



------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Yes, please! For all that might bother people about Subversion or Sourceforge, the qooxdoo-contrib architecture is simple the most efficient way for end users to profit from the contributions. The fact that one has to install yet another (exotic or not) revision control system might users deter from using a project. Subversion is well established and part of the qooxdoo ecosystem.

Thanks, Christian

thron7-2 wrote:

In my opinion the biggest issue with Python RPC is that so far nobody
undertook the (rather limited) effort of creating a corresponding
contribution in qooxdoo-contrib, for whatever reasons. Doing so would
both improve visibility to the community (so people use it) and the
chances of multiple people maintaining the code (so we could have a
common effort to create a good and usable Python backend; the
corresponding Php solution shines in that regard).

But as things are, now three different implementations surface, by
different people, in different repositories, and at different levels of
currentness and completeness. I don't care if a contrib is called
RpcPython or RpcPythonCherrypy or something else, as long as it gets in.
But of course the original authors have to make the first step.

Just my 2 cent.

Thomas


Andreas Ecker wrote:
> Howdy!
>
> On Wed, 2009-06-24 at 07:53 +0200, Jacques Bousseau wrote:
>  
>> See this project :
>> http://en.letras.ru/2009/01/qooxdoo-controller-for-cherrypy
>>
>> Jacques
>>
>> Delaney Gillilan a écrit :
>>    
>>> I noticed there is no is no official Python server so I made an
>>> initial stab at creating one using the awesome and fast http
>>> cherrypy server (www.cherrypy.org).  Created with svn trunk of
>>> cherrypy but 3.1 should work as well.  Obviously my tests need work
>>> but I implemented everything on
>>> http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made
>>> a bitbucket project for it at
>>> http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or
>>> thoughts for this are welcomed.
>>>      
>
> Seems there is quite some effort to implement Python RPC solutions for
> qooxdoo. Besides the two approaches mentioned here there is the
> original, "official" implementation by Viktor Ferenczi, see
> http://qooxdoo.org/documentation/0.8/rpc_python
>
> I'd like to have Viktor on board as the creator of the original
> qooxdoo/Python RPC solution, as he's always had many ideas to improve
> the current solution but lacking time/resources. Also Thomas (at least
> as an observer/supporter) as he's maintaining and advancing the
> Python-based qooxdoo tool chain.
>
> It would be great the qooxdoo/Python devs would enjoy to collaborate in
> providing an up-to-date RPC solution. This could also ensure the project
> kept being actively maintained and not going stale. Is there more than
> one environment to target (e.g. built around Cherry.py or not), which
> would mean more than on project?
>
> Let's see what the technical discussion leads to (for now I'd suggest to
> use the mailinglist for discussion, not a dedicated enhancement request
> in bugzilla). Whatever the proposals might be, I can well envision to
> start to host and incubate at least one such project as a contribution
> in qooxdoo-contrib.
>
> qooxdoo/Python people speak up!   ;-)
>
> Andreas
>
>  

--
Thomas Herchenröder
Development Technology & Architecture - Web Technologies

1&1 Internet AG       phone: [phone]
Ernst-Frey-Str.9      web  : www.1und1.de    
76135 Karlsruhe              qooxdoo.org

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler,
Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren



------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Derrell Lipman]

On Wed, Jun 24, 2009 at 8:10 AM, Burak Arslan <burak.arslan@...> wrote:

Andreas Ecker wrote:
> qooxdoo/Python people speak up!   ;-)
>
>

i keep repeating this but here it is again: i got a soap-rpc server in
the soap contrib.
http://qooxdoo.org/contrib/project#soap

I would suggest that you create an RpcSoap directoory in qooxdoo-contrib and put, at a minimum, a README file containing a link to the soap project. That way, when people are looking for an RPC implementation, they'll see it. All other RPC implementations in qooxdoo-contrib are RpcSomething, so creating that directory and readme will make it much more obvious.

Derrell

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

Burak Arslan wrote:

> Andreas Ecker wrote:
>  
>> qooxdoo/Python people speak up!   ;-)
>>
>>  
>>    
>
> i keep repeating this but here it is again: i got a soap-rpc server in
> the soap contrib.
> http://qooxdoo.org/contrib/project#soap
>  

i think it's good you keep repeating that, since i'm not sure people
know how to make use of that. Your contrib wiki docu could use brush-up,
if you ask me (in fact there is none). You could add a section how to
plug the qooxdoo RPC classes to your server?!

> it uses soaplib-lxml.
> http://github.com/plq/soaplib-lxml
>
> btw, http://qooxdoo-contrib.sf.net has a bad link.
>  

what's that?!

t.

> best regards,
> burak
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

panyasan wrote:
> Yes, please! For all that might bother people about Subversion or
> Sourceforge, the qooxdoo-contrib architecture is simple the most efficient
> way for end users to profit from the contributions.

Mind you: End users don't need SVN to use a contrib! Only developers of
the contrib do.

T.

>  The fact that one has to
> install yet another (exotic or not) revision control system might users
> deter from using a project. Subversion is well established and part of the
> qooxdoo ecosystem.
>
> Thanks, Christian
>
>
> thron7-2 wrote:
>  
>> In my opinion the biggest issue with Python RPC is that so far nobody
>> undertook the (rather limited) effort of creating a corresponding
>> contribution in qooxdoo-contrib, for whatever reasons. Doing so would
>> both improve visibility to the community (so people use it) and the
>> chances of multiple people maintaining the code (so we could have a
>> common effort to create a good and usable Python backend; the
>> corresponding Php solution shines in that regard).
>>
>> But as things are, now three different implementations surface, by
>> different people, in different repositories, and at different levels of
>> currentness and completeness. I don't care if a contrib is called
>> RpcPython or RpcPythonCherrypy or something else, as long as it gets in.
>> But of course the original authors have to make the first step.
>>
>> Just my 2 cent.
>>
>> Thomas
>>
>>
>> Andreas Ecker wrote:
>>    
>>> Howdy!
>>>
>>> On Wed, 2009-06-24 at 07:53 +0200, Jacques Bousseau wrote:
>>>  
>>>      
>>>> See this project :
>>>> http://en.letras.ru/2009/01/qooxdoo-controller-for-cherrypy
>>>>
>>>> Jacques
>>>>
>>>> Delaney Gillilan a écrit :
>>>>    
>>>>        
>>>>> I noticed there is no is no official Python server so I made an
>>>>> initial stab at creating one using the awesome and fast http
>>>>> cherrypy server (www.cherrypy.org).  Created with svn trunk of
>>>>> cherrypy but 3.1 should work as well.  Obviously my tests need work
>>>>> but I implemented everything on
>>>>> http://qooxdoo.org/documentation/0.8/rpc_server_writer_guide.  Made
>>>>> a bitbucket project for it at
>>>>> http://bitbucket.org/delaney/cooks_do_cherry_pie/.  Any comments or
>>>>> thoughts for this are welcomed.
>>>>>      
>>>>>          
>>> Seems there is quite some effort to implement Python RPC solutions for
>>> qooxdoo. Besides the two approaches mentioned here there is the
>>> original, "official" implementation by Viktor Ferenczi, see
>>> http://qooxdoo.org/documentation/0.8/rpc_python
>>>
>>> I'd like to have Viktor on board as the creator of the original
>>> qooxdoo/Python RPC solution, as he's always had many ideas to improve
>>> the current solution but lacking time/resources. Also Thomas (at least
>>> as an observer/supporter) as he's maintaining and advancing the
>>> Python-based qooxdoo tool chain.
>>>
>>> It would be great the qooxdoo/Python devs would enjoy to collaborate in
>>> providing an up-to-date RPC solution. This could also ensure the project
>>> kept being actively maintained and not going stale. Is there more than
>>> one environment to target (e.g. built around Cherry.py or not), which
>>> would mean more than on project?
>>>
>>> Let's see what the technical discussion leads to (for now I'd suggest to
>>> use the mailinglist for discussion, not a dedicated enhancement request
>>> in bugzilla). Whatever the proposals might be, I can well envision to
>>> start to host and incubate at least one such project as a contribution
>>> in qooxdoo-contrib.
>>>
>>> qooxdoo/Python people speak up!   ;-)
>>>
>>> Andreas
>>>
>>>  
>>>      
>> --
>> Thomas Herchenröder
>> Development Technology & Architecture - Web Technologies
>>
>> 1&1 Internet AG       phone: [phone]
>> Ernst-Frey-Str.9      web  : www.1und1.de    
>> 76135 Karlsruhe              qooxdoo.org
>>
>> Amtsgericht Montabaur HRB 6484
>>
>> Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
>> Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler,
>> Dr. Oliver Mauss, Jan Oetjen
>> Aufsichtsratsvorsitzender: Michael Scheeren
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> qooxdoo-devel mailing list
>> qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>>    
>
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

> I would suggest that you create an RpcSoap directoory in
> qooxdoo-contrib and put, at a minimum, a README file containing a link
> to the soap project. That way, when people are looking for an RPC
> implementation, they'll see it. All other RPC implementations in
> qooxdoo-contrib are RpcSomething, so creating that directory and
> readme will make it much more obvious.

I'm not so sure about that. If I got it right, Burak's Soap server needs
specific JavaScript Soap classes on the client side to talk to. So, if I
got that right, it doesn't fit straight in the row of backends that work
interchangeably with the standard qooxdoo RPC client classes. I think
the Soap contrib is an *alternative* transport mechanism, and adding a
RpcSoap contrib would actually mislead people in believing that would
work with vanilla qooxdoo RPC classes.

T.

>
> Derrell
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[delaney]

I have no problem putting my version in the contrib, just didn't know if I'd be stepping on anyone's toes doing so.  The thing I like about my version is A) handles errors gracefully B) don't need to subclass anything, just use add_service() function C) can place the rpc controller in any URL scheme D) only one I saw that implements the test functions laid out in the rpc server wiki page.  Before I add it to contrib has anyone tried running it to make sure it works? if you don't use mercurial you can still get the source as a zip/gz from http://bitbucket.org/delaney/cooks_do_cherry_pie/src/ to try out.

On Wed, Jun 24, 2009 at 7:36 AM, thron7 <thomas.herchenroeder@...> wrote:

Burak Arslan wrote:
> Andreas Ecker wrote:
>
>> qooxdoo/Python people speak up!   ;-)
>>
>>
>>
>
> i keep repeating this but here it is again: i got a soap-rpc server in
> the soap contrib.
> http://qooxdoo.org/contrib/project#soap
>

i think it's good you keep repeating that, since i'm not sure people
know how to make use of that. Your contrib wiki docu could use brush-up,
if you ask me (in fact there is none). You could add a section how to
plug the qooxdoo RPC classes to your server?!

> it uses soaplib-lxml.
> http://github.com/plq/soaplib-lxml
>
> btw, http://qooxdoo-contrib.sf.net has a bad link.
>

what's that?!

t.

> best regards,
> burak
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Burak,

Am 24.06.2009 um 14:10 schrieb Burak Arslan:

> Andreas Ecker wrote:
>> qooxdoo/Python people speak up!   ;-)
>>
>>
>
> i keep repeating this but here it is again: i got a soap-rpc server in
> the soap contrib.

The problem is that SOAP is (IMHO) a bad choice for RPC calls from  
JavaScript. In fact, I think it's a bad choice for almost _any_ RPC  
environment, but that's another story :-P  (Here's a funny, sad, and  
true piece about its history - more than two years old, but still  
valid: http://72.249.21.88/nonintersecting/?year=2006&monthnum=11&day=15&name=the-s-stands-for-simple&page=)

There's a lot of processing involved for even the simplest of calls.  
And there's just sooo much that can go wrong. Just try passing nested  
arrays or anything remotely complex, and more often than not the whole  
thing breaks down.

Personally, I'm trying to stay away from SOAP in the browser as far as  
I can. It's bloated, fragile, and slow. The only usecase I see is for  
calling an existing SOAP service that you cannot wrap in or proxy with  
JSON-RPC. I guess I'm not alone with my assessment, which might  
explain why your SOAP implementation doesn't elicit a lot of feedback.

Disclaimer: I'm not in any way criticizing your implementation (which  
I haven't looked at). I'm talking about the protocol itself and its  
usefulness (or not) for browser-based applications.

Regards,

   Andreas J.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

Delaney Gillilan wrote:
> I have no problem putting my version in the contrib, just didn't know
> if I'd be stepping on anyone's toes doing so.  The thing I like about
> my version is A) handles errors gracefully B) don't need to subclass
> anything, just use add_service() function C) can place the rpc
> controller in any URL scheme D) only one I saw that implements the
> test functions laid out in the rpc server wiki page.  Before I add it
> to contrib has anyone tried running it to make sure it works? if you
> don't use mercurial you can still get the source as a zip/gz from
> http://bitbucket.org/delaney/cooks_do_cherry_pie/src/ to try out.

I'd say go ahead and create the contrib. It doesn't prevent anybody from
adding their own as an alternative if they feel it's substantially
different, so there shouldn't be any toes hurt :). And it doesn't have
to be polished, on the contrary: Once it is in qooxdoo-contrib it should
be much easier for people to try out and give feedback. That's what the
repository is for.

T.

>
> On Wed, Jun 24, 2009 at 7:36 AM, thron7 <thomas.herchenroeder@...
> <mailto:thomas.herchenroeder@...>> wrote:
>
>
>
>     Burak Arslan wrote:
>     > Andreas Ecker wrote:
>     >
>     >> qooxdoo/Python people speak up!   ;-)
>     >>
>     >>
>     >>
>     >
>     > i keep repeating this but here it is again: i got a soap-rpc
>     server in
>     > the soap contrib.
>     > http://qooxdoo.org/contrib/project#soap
>     >
>
>     i think it's good you keep repeating that, since i'm not sure people
>     know how to make use of that. Your contrib wiki docu could use
>     brush-up,
>     if you ask me (in fact there is none). You could add a section how to
>     plug the qooxdoo RPC classes to your server?!
>
>     > it uses soaplib-lxml.
>     > http://github.com/plq/soaplib-lxml
>     >
>     > btw, http://qooxdoo-contrib.sf.net has a bad link.
>     >
>
>     what's that?!
>
>     t.
>
>     > best regards,
>     > burak
>     >
>     >
>     ------------------------------------------------------------------------------
>     > _______________________________________________
>     > qooxdoo-devel mailing list
>     > qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     >
>     >
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     qooxdoo-devel mailing list
>     qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[delaney]

I sent off my info to the contrib email I'll let the thread know when this is all setup.

On Wed, Jun 24, 2009 at 7:58 AM, thron7 <thomas.herchenroeder@...> wrote:

Delaney Gillilan wrote:
> I have no problem putting my version in the contrib, just didn't know
> if I'd be stepping on anyone's toes doing so.  The thing I like about
> my version is A) handles errors gracefully B) don't need to subclass
> anything, just use add_service() function C) can place the rpc
> controller in any URL scheme D) only one I saw that implements the
> test functions laid out in the rpc server wiki page.  Before I add it
> to contrib has anyone tried running it to make sure it works? if you
> don't use mercurial you can still get the source as a zip/gz from
> http://bitbucket.org/delaney/cooks_do_cherry_pie/src/ to try out.

I'd say go ahead and create the contrib. It doesn't prevent anybody from
adding their own as an alternative if they feel it's substantially
different, so there shouldn't be any toes hurt :). And it doesn't have
to be polished, on the contrary: Once it is in qooxdoo-contrib it should
be much easier for people to try out and give feedback. That's what the
repository is for.

T.


>
> On Wed, Jun 24, 2009 at 7:36 AM, thron7 <thomas.herchenroeder@...

> <mailto:thomas.herchenroeder@...>> wrote:
>
>
>
>     Burak Arslan wrote:
>     > Andreas Ecker wrote:
>     >
>     >> qooxdoo/Python people speak up!   ;-)
>     >>
>     >>
>     >>
>     >
>     > i keep repeating this but here it is again: i got a soap-rpc
>     server in
>     > the soap contrib.
>     > http://qooxdoo.org/contrib/project#soap
>     >
>
>     i think it's good you keep repeating that, since i'm not sure people
>     know how to make use of that. Your contrib wiki docu could use
>     brush-up,
>     if you ask me (in fact there is none). You could add a section how to
>     plug the qooxdoo RPC classes to your server?!
>
>     > it uses soaplib-lxml.
>     > http://github.com/plq/soaplib-lxml
>     >
>     > btw, http://qooxdoo-contrib.sf.net has a bad link.
>     >
>
>     what's that?!
>
>     t.
>
>     > best regards,
>     > burak
>     >
>     >
>     ------------------------------------------------------------------------------
>     > _______________________________________________
>     > qooxdoo-devel mailing list
>     > qooxdoo-devel@...

>     <mailto:qooxdoo-devel@...>

>     > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     >
>     >
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     qooxdoo-devel mailing list
>     qooxdoo-devel@...

>     <mailto:qooxdoo-devel@...>

>     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

Delaney Gillilan wrote:
> I sent off my info to the contrib email I'll let the thread know when
> this is all setup.

Great.



------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Gene Amtower]

Burak and I touched on this subject in posts during this past week related to my question on an Oracle RPC server for Qooxdoo.

In that discussion, I mentioned that I think SOAP is more appropriate where two server systems are exchanging data in order to extend the usefulness of existing server systems.  In the context of a client-server interaction, especially where Javascript is involved as in Qooxdoo, I also think the JSONRPC protocol is more appropriate.  Where you have control of both the client and server environments, JSONRPC may be optimal.  Outside of Javascript and Qooxdoo, SOAP probably has a stronger use case.

In all I've read on this list, it appears that JSONRPC is the prevalent method of performing RPC communications among those using Qooxdoo.  Of course, if an existing SOAP service (unrelated to Qooxdoo) exists on a server, Qooxdoo *should* have the capability to query those types of services in order to maximize the usefulness of the Qooxdoo client framework.  Since I've not looked for those types of features, I don't know if they exist in the production framework.  If Burak's contribution provides missing client-side SOAP capability to use SOAP services outside of Qooxdoo, this would be a significant benefit, maybe more so than the SOAP server component itself.

HTH,

  Gene

On Wed, 2009-06-24 at 16:52 +0200, Andreas Junghans wrote:

Hi Burak,

Am 24.06.2009 um 14:10 schrieb Burak Arslan:

> Andreas Ecker wrote:
>> qooxdoo/Python people speak up!   ;-)
>>
>>
>
> i keep repeating this but here it is again: i got a soap-rpc server in
> the soap contrib.

The problem is that SOAP is (IMHO) a bad choice for RPC calls from  
JavaScript. In fact, I think it's a bad choice for almost _any_ RPC  
environment, but that's another story :-P  (Here's a funny, sad, and  
true piece about its history - more than two years old, but still  
valid: http://72.249.21.88/nonintersecting/?year=2006&monthnum=11&day=15&name=the-s-stands-for-simple&page=)

There's a lot of processing involved for even the simplest of calls.  
And there's just sooo much that can go wrong. Just try passing nested  
arrays or anything remotely complex, and more often than not the whole  
thing breaks down.

Personally, I'm trying to stay away from SOAP in the browser as far as  
I can. It's bloated, fragile, and slow. The only usecase I see is for  
calling an existing SOAP service that you cannot wrap in or proxy with  
JSON-RPC. I guess I'm not alone with my assessment, which might  
explain why your SOAP implementation doesn't elicit a lot of feedback.

Disclaimer: I'm not in any way criticizing your implementation (which  
I haven't looked at). I'm talking about the protocol itself and its  
usefulness (or not) for browser-based applications.

Regards,

   Andreas J.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

I've looked again at Victor's implementation ("qxjsonrpc",
http://qooxdoo.org/documentation/0.6/user_manual/rpc/python), which was
a library that could again be hosted by two server environments:

  * a stand-alone HTTP server based on Python's BaseHTTTPServer
  * a WSGI interface

Now we have a CherryPy implementation.

Is this a general pattern: You have an RPC layer which in turn is hosted
by some HTTP-savvy environment? Could the RPC layer be abstracted away
from the HTTP environment, so that it would be general and then be
plugged into multiple environments, maybe by the use of adaptors? So you
have only one generic RPC layer and a set of adaptors to maintain?!

Or could we reduce ourselves on the WSGI interface, since it's widely
supported (Cherrypy, Django, TurboGears, Pylons, Zope, ..., mod_wsgi for
Apache)?!

If people tend to think we should account for different server
environments rather than just develop for WSGI, then maybe in the first
step we should try to isolate the two parts in, say, the RpcPython
contrib e.g. by creating submodules for the RPC layer and the Cherrypy,
.... adaptors, and if it seems sensible maybe later reduce RpcPython to
the RPC layer and put the adaptors in dedicated contributions.

What do you guys think?

T.

Delaney Gillilan wrote:

> I sent off my info to the contrib email I'll let the thread know when
> this is all setup.
>
> On Wed, Jun 24, 2009 at 7:58 AM, thron7 <thomas.herchenroeder@...
> <mailto:thomas.herchenroeder@...>> wrote:
>
>
>
>     Delaney Gillilan wrote:
>     > I have no problem putting my version in the contrib, just didn't
>     know
>     > if I'd be stepping on anyone's toes doing so.  The thing I like
>     about
>     > my version is A) handles errors gracefully B) don't need to subclass
>     > anything, just use add_service() function C) can place the rpc
>     > controller in any URL scheme D) only one I saw that implements the
>     > test functions laid out in the rpc server wiki page.  Before I
>     add it
>     > to contrib has anyone tried running it to make sure it works? if you
>     > don't use mercurial you can still get the source as a zip/gz from
>     > http://bitbucket.org/delaney/cooks_do_cherry_pie/src/ to try out.
>
>     I'd say go ahead and create the contrib. It doesn't prevent
>     anybody from
>     adding their own as an alternative if they feel it's substantially
>     different, so there shouldn't be any toes hurt :). And it doesn't have
>     to be polished, on the contrary: Once it is in qooxdoo-contrib it
>     should
>     be much easier for people to try out and give feedback. That's
>     what the
>     repository is for.
>
>     T.
>
>
>     >
>     > On Wed, Jun 24, 2009 at 7:36 AM, thron7
>     <thomas.herchenroeder@... <mailto:thomas.herchenroeder@...>
>     > <mailto:thomas.herchenroeder@...
>     <mailto:thomas.herchenroeder@...>>> wrote:
>     >
>     >
>     >
>     >     Burak Arslan wrote:
>     >     > Andreas Ecker wrote:
>     >     >
>     >     >> qooxdoo/Python people speak up!   ;-)
>     >     >>
>     >     >>
>     >     >>
>     >     >
>     >     > i keep repeating this but here it is again: i got a soap-rpc
>     >     server in
>     >     > the soap contrib.
>     >     > http://qooxdoo.org/contrib/project#soap
>     >     >
>     >
>     >     i think it's good you keep repeating that, since i'm not
>     sure people
>     >     know how to make use of that. Your contrib wiki docu could use
>     >     brush-up,
>     >     if you ask me (in fact there is none). You could add a
>     section how to
>     >     plug the qooxdoo RPC classes to your server?!
>     >
>     >     > it uses soaplib-lxml.
>     >     > http://github.com/plq/soaplib-lxml
>     >     >
>     >     > btw, http://qooxdoo-contrib.sf.net has a bad link.
>     >     >
>     >
>     >     what's that?!
>     >
>     >     t.
>     >
>     >     > best regards,
>     >     > burak
>     >     >
>     >     >
>     >    
>     ------------------------------------------------------------------------------
>     >     > _______________________________________________
>     >     > qooxdoo-devel mailing list
>     >     > qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     >     <mailto:qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>>
>     >     > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     >     >
>     >     >
>     >     >
>     >
>     >    
>     ------------------------------------------------------------------------------
>     >     _______________________________________________
>     >     qooxdoo-devel mailing list
>     >     qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     >     <mailto:qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>>
>     >     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > qooxdoo-devel mailing list
>     > qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     qooxdoo-devel mailing list
>     qooxdoo-devel@...
>     <mailto:qooxdoo-devel@...>
>     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Burak Arslan-4]

thron7 wrote:

I would suggest that you create an RpcSoap directoory in 
qooxdoo-contrib and put, at a minimum, a README file containing a link 
to the soap project. That way, when people are looking for an RPC 
implementation, they'll see it. All other RPC implementations in 
qooxdoo-contrib are RpcSomething, so creating that directory and 
readme will make it much more obvious.
    

I'm not so sure about that. If I got it right, Burak's Soap server needs 
specific JavaScript Soap classes on the client side to talk to.

well, the first ever port of soap client was pretty bad. but with my recent rewriting of the client, it got as standards conformant as i could make it to be (the soap standard is huge, and i'd appreciate more testing). yes in a sense you're right, you need a specific client. but don't forget that soap is a w3c standard and not just some protocol i came up with.

 So, if I 
got that right, it doesn't fit straight in the row of backends that work 
interchangeably with the standard qooxdoo RPC client classes. I think 
the Soap contrib is an *alternative* transport mechanism, and adding a 
RpcSoap contrib would actually mislead people in believing that would 
work with vanilla qooxdoo RPC classes.

  

if ever qooxdoo devs choose to include soap client inside mainstream qooxdoo, this problem vanishes :) (i'd raised the point of including soap client inside mainstream qooxdoo, but it got forgotten, see one of my soap client announcement mails) so what do qooxdoo devs think about including my soap client in mainstream qooxdoo distribution?


burak
------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Gene Amtower]

Burak,

Yep, as I stated a bit ago, I think adding a conformant SOAP client library in Qooxdoo would help with adoption in some specific development situations, even though I don't see it being beneficial in my current projects' architectures.  There are many existing SOAP server configurations on the web, and a SOAP client library that isn't tied to a Qooxdoo SOAP server installation would allow Qooxdoo to talk to many backend servers through the SOAP interface, providing additional value for a new set of developers adopting the Qooxdoo framework.

Hopefully, others see its value too.  I'm sure you'll need to demonstrate that it's ready for mainstream Qooxdoo, just like any other new feature.  Of course, adding a feature that's NOT one of the primary uses of Qooxdoo in the hopes of getting additional converts TO Qooxdoo means you're not going to get much testing and feedback from the current team, eh?

Again, SOAP has a narrow set of circumstances where it's valuable, but it does have value.

You got my vote.

   Gene





On Wed, 2009-06-24 at 22:06 +0300, Burak Arslan wrote:

thron7 wrote:

I would suggest that you create an RpcSoap directoory in 
qooxdoo-contrib and put, at a minimum, a README file containing a link 
to the soap project. That way, when people are looking for an RPC 
implementation, they'll see it. All other RPC implementations in 
qooxdoo-contrib are RpcSomething, so creating that directory and 
readme will make it much more obvious.
    

I'm not so sure about that. If I got it right, Burak's Soap server needs 
specific JavaScript Soap classes on the client side to talk to.

well, the first ever port of soap client was pretty bad. but with my recent rewriting of the client, it got as standards conformant as i could make it to be (the soap standard is huge, and i'd appreciate more testing). yes in a sense you're right, you need a specific client. but don't forget that soap is a w3c standard and not just some protocol i came up with.

 So, if I 
got that right, it doesn't fit straight in the row of backends that work 
interchangeably with the standard qooxdoo RPC client classes. I think 
the Soap contrib is an *alternative* transport mechanism, and adding a 
RpcSoap contrib would actually mislead people in believing that would 
work with vanilla qooxdoo RPC classes.

  

if ever qooxdoo devs choose to include soap client inside mainstream qooxdoo, this problem vanishes :) (i'd raised the point of including soap client inside mainstream qooxdoo, but it got forgotten, see one of my soap client announcement mails) so what do qooxdoo devs think about including my soap client in mainstream qooxdoo distribution?


burak

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[thron7-2]

>
> well, the first ever port of soap client was pretty bad. but with my
> recent rewriting of the client, it got as standards conformant as i
> could make it to be (the soap standard is huge, and i'd appreciate
> more testing). yes in a sense you're right, you need a specific
> client. but don't forget that soap is a w3c standard and not just some
> protocol i came up with.

I didn't want to belittle your Soap implementation, I hope you didn't
have that impression. I just wanted to make that distinction so people
don't confuse things. I think the work done around the Json RPC (if we
may call it like that), both on the client and the server side, is very
valuable and seems to have evolved into a "main road" of communicating
with the server for a qooxdoo app. So we should keep that environment
straight. But that shouldn't depreciate other transport mechanisms, just
set them clearer apart.

>>  So, if I
>> got that right, it doesn't fit straight in the row of backends that work
>> interchangeably with the standard qooxdoo RPC client classes. I think
>> the Soap contrib is an *alternative* transport mechanism, and adding a
>> RpcSoap contrib would actually mislead people in believing that would
>> work with vanilla qooxdoo RPC classes.
>>
>>    
>
> if ever qooxdoo devs choose to include soap client inside mainstream
> qooxdoo, this problem vanishes :) (i'd raised the point of including
> soap client inside mainstream qooxdoo,

I remember that much.

> but it got forgotten, see one of my soap client announcement mails) so
> what do qooxdoo devs think about including my soap client in
> mainstream qooxdoo distribution?

I can only give you my personal 2 cent. There is, AFAIK, currently no
established process by which contrib projects are evaluated for
inclusion in the framework. My best suggestion would be to open an
enhancement bug for this. This will feed the issue into our workflow and
keep it on our radar. Also, others can comment and vote. But that
doesn't automatically mean it will happen any time soon. As we are
heading for the 1.0 release this year, much attention will be given to
API and runtime stability, and there are probably other API changes in
the queue already that will be given higher priority.

Besides that, there are things to consider. I see there might be some
concern about licensing issues with your contrib, which is critical for
qooxdoo. Your client uses third-party code from codeplex.com which is
GPL-ed, and the hand-waving attitude of the original author in a
personal mail to you might not be enough at the end of the day.

Also, there seems a bit of work open on the code level, assimilating
your code to qooxdoo name spaces, documentation and coding styles. E.g.
your code should fit seamlessly into the qx.io name space (e.g. as
qx.io.Soap), together with the proper Apiviewer documentation, headers,
whitespace and whatnot. The contrib's soapdemo name space and the
contained modules don't resemble that very much. This is something you
could work on. Eventually, when it comes to evaluation it should be easy
for the core team to "see" how your modules would fit into the
framework, both from a structural, coding-style and functional point of
view.

HTH. Maybe Andreas can comment better on this.

T.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel