RPC server implemented using Python (Cherrypy)

[Burak Arslan-4]

thron7 wrote:

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.

no worries.

 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.

  

well, rpc is a hot topic nowadays, and i say supporting more than one rpc protocol (or at least being prepared for it) would add value to an application framework such as qooxdoo

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.

  

that's one of the reasons i'm insisting on bringing this up. even if you don't want to include my soap contrib in the mainstream qooxdoo  package, you should be ready to do so *before* freezing the api.

eg. remember how it was VerticalBoxLayout and now it is layout.VBox ? the same thing applies here, there has to be:

qx.io.rpc.Json,
qx.io.rpc.Soap,
qx.io.rpc.Xml etc.,

and not

qx.io.Rpc
qx.io.Soap
qx.io.XmlRpc etc.

i guess this point this merits an enhancement bug. i can file a bug report if you think i should.

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.

  

i can say that this code doesn't derive from mateo casati's client anymore, it's rewritten. there are code fragments here and there, but the logic is completely different.

but as you say, at the end of the day, it just might not be enough.

the only suggestion i can make at this point is maybe you tell me what you want to hear from the original author, i (or even you) can just ask him.

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.

  

well, as i did not get any feedback about the current state of the soap api, i can't freeze it, and i won't write documentation for an unfrozen api.

as for the whitespace, the moment this code is reformatted to respect qooxdoo style, it stops being my concern -- i despise qooxdoo coding style. (seriously guys, are you using 16:9 monitors vertically or something? i can see the frikkin "members : {" line, there's no point in announcing it with an ugly 9-line comment block!)

HTH. Maybe Andreas can comment better on this.

  

thanks for your time thomas, appreciated. i now have a better image of your expectations.

best regards,
burak


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

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

[thron7-2]

> that's one of the reasons i'm insisting on bringing this up. even if
> you don't want to include my soap contrib in the mainstream qooxdoo  
> package, you should be ready to do so *before* freezing the api.
>
> eg. remember how it was VerticalBoxLayout and now it is layout.VBox ?
> the same thing applies here, there has to be:
>
> qx.io.rpc.Json,
> qx.io.rpc.Soap,
> qx.io.rpc.Xml etc.,
>
> and not
>
> qx.io.Rpc
> qx.io.Soap
> qx.io.XmlRpc etc.

Wait, this is more far reaching then just adding another API. You want
to re-structure the existing classes.

>
> i guess this point this merits an enhancement bug. i can file a bug
> report if you think i should.

I'm not the right one to judge this. Maybe others like Andreas or Fabian
can comment on this.

> i can say that this code doesn't derive from mateo casati's client
> anymore, it's rewritten. there are code fragments here and there, but
> the logic is completely different.

Then why do you maintain the copyright notices in the code and readme?!

> well, as i did not get any feedback about the current state of the
> soap api, i can't freeze it, and i won't write documentation for an
> unfrozen api.

I think you're wrong here. Documentation is not something nice and extra
which you add as an icing at the end of the development cycle. We don't
follow the waterfall model anyway. Documentation is an intrinsic part of
any piece of software, at any stage of its life cycle. Documentation is
necessary to convey what the software is about and how to use it. You
write a piece of software and the docs at the same time (and the tests,
if you're really into it). If you change the software, you change the docs.

Docs are an important inroad to your API if you want other people to
evaluate it. You complain you don't get feedback, but maybe one reason
is because your contrib is not in good shape. Ever considered this?!

> as for the whitespace, the moment this code is reformatted to respect
> qooxdoo style, it stops being my concern -- i despise qooxdoo coding
> style. (seriously guys, are you using 16:9 monitors vertically or
> something? i can see the frikkin "members : {" line, there's no point
> in announcing it with an ugly 9-line comment block!)

Well, you don't have to like it. But you have to handle it. As I said,
the attractivity of your API for the framework also depends on how easy
it is for others to see how it fits in. If you just throw bits and
pieces around, it's much harder to assess their merrit.

T.

>
>
>
>> HTH. Maybe Andreas can comment better on this.
>>
>>  
>
>
> thanks for your time thomas, appreciated. i now have a better image of
> your expectations.
>
> 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

[Burak Arslan-4]

thron7 wrote:

Wait, this is more far reaching then just adding another API. You want 
to re-structure the existing classes.
  

yes, i don't like the idea of qx.io.remote.Soap.

i guess this point this merits an enhancement bug. i can file a bug 
report if you think i should.
    

I'm not the right one to judge this. Maybe others like Andreas or Fabian 
can comment on this.

  

won't bet on it :/.

i can say that this code doesn't derive from mateo casati's client 
anymore, it's rewritten. there are code fragments here and there, but 
the logic is completely different.
    

Then why do you maintain the copyright notices in the code and readme?!

  

because i'm not sure, i'm no lawyer. as i said there are still code fragments lying around here and there, so i try to be as honest as i can.

well, as i did not get any feedback about the current state of the 
soap api, i can't freeze it, and i won't write documentation for an 
unfrozen api.
    

I think you're wrong here. Documentation is not something nice and extra 
which you add as an icing at the end of the development cycle. We don't 
follow the waterfall model anyway. Documentation is an intrinsic part of 
any piece of software, at any stage of its life cycle. Documentation is 
necessary to convey what the software is about and how to use it. You 
write a piece of software and the docs at the same time (and the tests, 
if you're really into it). If you change the software, you change the docs.

  

this is just one way of doing it. what we normally do is to freeze the api before writing a single line of code. then the analyst(s) write the tests and the documentation, and the coder writes the code. we try to avoid refactors like plague, because they are costs without value-adds. this doesn't mean we don't do them, but it's still an indication of a poor design process.

those being said; i can't find proper documentation on how you guys work, nor about what model you follow. where do the ideas come from? who converts them to tasks and prioritizes them? who assigns them to people? what's the reasoning behind changes? i know none of those -- we just watch the commits happen.

eg. the change about the caching behaviour came out of nowhere. i tried to give feedback but saw that my assumptions were wrong, so what i said turned out to be nonsense. my time wasted -- as well as yours.

python does a better job of dev-community management, imo. see http://www.amk.ca/talks/python-dev/ or python.org/dev.

Docs are an important inroad to your API if you want other people to 
evaluate it. You complain you don't get feedback, but maybe one reason 
is because your contrib is not in good shape. Ever considered this?!

  

again: i can write documentation. doing it once is fine and i agree that it's part of a proper contribution. but if ever you don't like it and want me to change it, i won't bother, sorry. it's not fun, i'm not learning anything anymore.

so: i'm willing to donate my time to improve qooxdoo, only either:

1) you give me voice in the design process so i can be sure the api will stay my way.
2) you give me what interface to implement, and i'll do it.


best regards,
burak



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

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

[thron7-2]

Burak Arslan wrote:

> thron7 wrote:
>> Wait, this is more far reaching then just adding another API. You want
>> to re-structure the existing classes.
>>  
>
> yes, i don't like the idea of qx.io.remote.Soap.
>
>>> i guess this point this merits an enhancement bug. i can file a bug
>>> report if you think i should.
>>>    
>>
>> I'm not the right one to judge this. Maybe others like Andreas or Fabian
>> can comment on this.
>>
>>  
>
> won't bet on it :/.
>
>>> i can say that this code doesn't derive from mateo casati's client
>>> anymore, it's rewritten. there are code fragments here and there, but
>>> the logic is completely different.
>>>    
>>
>> Then why do you maintain the copyright notices in the code and readme?!
>>
>>  
>
> because i'm not sure, i'm no lawyer. as i said there are still code
> fragments lying around here and there, so i try to be as honest as i can.

Fair enough. But then the code fragments can either be re-written and
the copyright notices removed (especially since you say that the logic
is completely different). Or the copyrights have to stay, and then we
have to address that.

>
>>> well, as i did not get any feedback about the current state of the
>>> soap api, i can't freeze it, and i won't write documentation for an
>>> unfrozen api.
>>>    
>>
>> I think you're wrong here. Documentation is not something nice and extra
>> which you add as an icing at the end of the development cycle. We don't
>> follow the waterfall model anyway. Documentation is an intrinsic part of
>> any piece of software, at any stage of its life cycle. Documentation is
>> necessary to convey what the software is about and how to use it. You
>> write a piece of software and the docs at the same time (and the tests,
>> if you're really into it). If you change the software, you change the docs.
>>
>>  
>
> this is just one way of doing it. what we normally do is to freeze the
> api before writing a single line of code. then the analyst(s) write
> the tests and the documentation, and the coder writes the code.

This is pretty much water fall: design upfront - coding follows suit.

> we try to avoid refactors like plague, because they are costs without
> value-adds. this doesn't mean we don't do them, but it's still an
> indication of a poor design process.

I wouldn't say they're without value since you gained insight and
experience on the way leading up to them. Also, I don't consider it a
poor design process, it's just a different approach. In many cases known
to me upfront design was simply too unreliable and turned out to be full
of flaws once the implementation takes shape, but there may be settings
where this is not the case. But there is a whole literature about water
fall vs. iterative development models, which we probably don't want to
iterate over here.

>
> those being said; i can't find proper documentation on how you guys
> work, nor about what model you follow. where do the ideas come from?
> who converts them to tasks and prioritizes them? who assigns them to
> people? what's the reasoning behind changes? i know none of those --
> we just watch the commits happen.

Well, this surprises me, since although our documentation on the issue
is probably a good deal from exhaustive, there is the Commiters Guide
(http://qooxdoo.org/documentation/general/committers_guide), which
covers a lot of ground, the role of the project lead and task-oriented
development using the bug tracker, among other things. I thought you
knew that.

> eg. the change about the caching behaviour came out of nowhere.

http://bugzilla.qooxdoo.org/show_bug.cgi?id=2354

The bug was filed nearly 3 weeks before any user-perceivable change was
commited to trunk. Moreover, this is also a penalty you pay working on
bleeding-edge trunk code :).

> i tried to give feedback but saw that my assumptions were wrong, so
> what i said turned out to be nonsense. my time wasted -- as well as yours.

I cannot remember my time being wasted on that issue. I don't consider
feedback or questions, even if they turn out to be misunderstandings, to
be wasteful. Communication is a vital part of any project, and
communicating means dealing with people's concepts, whatever they are.
Currently, I'm dealing with your concept of a development process, and I
think it's a very important thing to do, whatever the outcome may be.

>
> python does a better job of dev-community management, imo. see
> http://www.amk.ca/talks/python-dev/ or python.org/dev.

Yes, but how big is Python compared to qooxdoo?!

> again: i can write documentation. doing it once is fine and i agree
> that it's part of a proper contribution. but if ever you don't like it
> and want me to change it, i won't bother, sorry. it's not fun, i'm not
> learning anything anymore.

I have the impression that you have very explicit ideas about what you
want to spent your time on. You don't want to do documentation twice;
you don't want to work with code that is formatted in qooxdoo style; you
want to fullfill a spec and never look back. All that is fair enough.
But if you want to deal with us, you probably have to make compromises,
since we do things differently. You wouldn't expect us to jump ship,
just to make it easy for you, or would you?!

>
> so: i'm willing to donate my time to improve qooxdoo, only either:
>
> 1) you give me voice in the design process so i can be sure the api
> will stay my way.

Even if you have a voice in the design process, there is no way of being
certain that anything will stay. And this holds for all of us.

> 2) you give me what interface to implement, and i'll do it.

I'm not sure. We are usually not setting up specs and give them out. A
lot of work and consideration is actually in coming up with designs, not
just implementation.


Thomas

>
>
> 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

[Andreas Ecker-2]

Hi Burak,

lets figure out some of the next steps that are relevant for your
contribution.

> > > i can say that this code doesn't derive from mateo casati's client
> > > anymore, it's rewritten. there are code fragments here and there, but
> > > the logic is completely different.
> >
> > Then why do you maintain the copyright notices in the code and readme?!  
>
> because i'm not sure, i'm no lawyer. as i said there are still code
> fragments lying around here and there, so i try to be as honest as i
> can.

We need to be absolutely sure about the legal situation. Fair enough
that you're not a lawyer. Nobody is here either, so don't worry. But I'd
suggest you carefully re-evaluate what original source code might be
left in the current code base. There's also some confusion about the
licensing terms. Is the 3rd party code under GPL or CC-SA-2.5? The
current 0.4.1 release of your Soap contribution is even covered by a
BSD-style license. Please try to figure it out, even if I understand it
isn't something a developer really wants to do. It simply is a minimum
requirement when developing open source software. If you've got any
legal questions, please contact me off-list, so I might be able to
assist.

Once the license issues are resolved (hope we get that straightened out
soon), it would be great to advance your contribution as expected to
make it really useful for others as well. I think it's a great addition
to have your contribution provide a SOAP communication layer for
qooxdoo. It's also a perfect addition to qooxdoo-contrib. There's a
misinterpretation once in a while about the qooxdoo framework (you
called it "mainstream") vs. the contributions. Let me say that _both_
are essential parts for qooxdoo as a whole.

It certainly is an advantage to have an ecosystem for qooxdoo, that
features an infrastructure for distributed software. While
qooxdoo-contrib provides some pre-defined infrastructure (like project
structure, or tooling) and policies (documentation, release management,
etc.), there's quite some freedom for all developers to collaborate,
maintain and release their projects.

So projects don't have to be stuffed into a monolithic framework on a
code level and be governed by the same set of rules. But it has always
been a top priority to allow to include any contribution easily into
anyone's custom project. Sure there's much room for improvement (e.g.
proper exposure of some of the contributions), but we're working on that
and there have been some major steps forward recently. It's just that
one cannot have it all at once, so simply needs some time and hatching.

Anyway, lets work out the open issues specific to your Soap client so
that it can really become a valuable addition to the qooxdoo ecosystem.
If you've got any specific questions, feel free to contact me directly.

Bye,

Andreas

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



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