Martin!
First, thanks for a better balanced response.
Second, this happened:
1. we contributed with code, a function necessary for BIG applications with
characteristics we and others might have = a solution to the problem
2. we are attacked in a very infantile way by T, as he had previously done by
forwarding internal mail to the list
Normal behaviour is:
1. thank you, as one of you did on the bug list
2. second evaluate the contribution
3. come up with facts, discussion and questions, no imaginations, attacks and
theoretical ideasirregularities like T was doing
4. why not ask the community about new additions?
5. then decide if you want to take it in or just keep it as available code
Frankly, we do not care if it is taken into the qooxdoo code or not. It is not
our goal by sharing our solutions.
The best point here is, that you will understand what problems developers out
there have and you will get ideas, new ideas.
This point T has totally forgotten and shadowed by arrogance instead of
patience and calm.
If you don't learn what we developers do out there you will never become better
than you are yourself!
>You wrote "checked in" and as this is a term usually used for repositories,
>that was a simple clarification.
Checked in or not... It is a game of words. You know very well what was meant.
Clarifications can be done in many ways.... This one was not a good one.
>I assume this is not the core team's opinion.
>How do you know the core teams opinion?
BIG difference between assume and know! It was a rhetorical question and that
means that, we hope this was not the opinion of the core team. We didn't say
that we know anything!!!
>We would appreciate a more professional attitude! Thanks!
>As we would too. ;)
We contributed and get attacked.... that is all!!!
>Yes, T! It is a tremendous loss off information and that is what is wanted!
>One example:
>If you have a json array of 250 rows with each 3 key-value pairs, you save the
>space (in our case 66%)
>T, the keys are repeated 3 x 250 times without sense!
>Thats working fine in your example and thats what you needed in your
>application. On a technical point, I totally agree with you for your use case.
>So your arguments hit exactly the point.
>But thats not the only thing relevant for putting it into the framework. There
>has to be a general use case for using it and there has to be no other
>solution possible. I do believe that both are not valid in this case. Why?
>1. We build big applications here too and none ever asked for such a feature.
>Additionally, I agree with t, that the JSON could have been set up that way in
>the first place if the files are in your control.
>2. Thats a single precompilation step which can be done by a command line tool.
But, Martin, we have never claimed to put it into the framework! Read the
correspondence again!
1. You say so. We have never seen. Show us those apps! How big are they etc....
That would be useful for new users to know.
2. image-combine and many other functions are also "a single precompilation
step" and can also be done by a command line tool...and you have no control of
the developers images!!!! Different? No, it is not!
Your arguments are weak both technically as well as structurally in this case.
>Give us test results instead, supporting your "theories" and imagination, with
>the above given facts.
>Are we in charge to give you results? I don't think so.
>T, your rethorics is full of holes and is inconsequent.
>And you call that professional attitude?
>Are databases compressed in any way to save space? yes, they are and the
>reasons are obvious
>Do we compile code to execute applications? yes, we do and the reasons are
>obvious
>Does qooxdoo use compression? yes, it does and it is obvious why
>I can not read compressed and changed qooxdoo javascript! The biggest loss of
>information and distortion of javascript semantics are generated by the
>generator.
>Javascript was not intended to be compressed, but qooxdoo is. We know the
>reasons.
>Again, technically correct but thats not the point. So I won't argue with you
>about the technical details on that enhancement. I do not doubt your arguments
>here. But maybe you should not doubt that we know the framework best and want
>it to be as good as possible for all users.
You are stuck in stone!
Martin, why don't you instead say: THanks for the contribution and we will look
at it and see if it might be a function we would like to implement or not.
That is all...we contribute with NO demands at all... we don't care if you use
it or not....we just would like to make it easier to someone else who might get
the
same problem as we did, and that is all.
Drop this discussion now and focus on tech, which T didn't!
Now the community knows there is a solution on a possible problem of theirs.
They are free to use it if they wish so.
Regards,
Stefan
Regards,
Martin
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
