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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
