From: Chris Riesbeck on 6 Jan 2010 13:26
Lasse Reichstein Nielsen wrote:
> Jorge <jorge(a)jorgechamorro.com> writes:
>> On Jan 5, 1:38 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>>> I've decided to release My Library under some sort of free license.
>>> Haven't thought about free licenses in a long time (decades), so I am
>>> open to ideas.
>> "The Software shall be used for Good, not Evil" ?
> Bad idea. It lacks a definition of both "Good" and "Evil", making the
> license ambiguous, and if it had one, it would probably run afoul of
> the Open Source Definition (6. No Discrimination Against Fields of
but with an "or" instead of "and not" it's OK, right?
From: Jeremy J Starcher on 6 Jan 2010 13:56
On Mon, 04 Jan 2010 16:38:30 -0800, David Mark wrote:
> I've decided to release My Library under some sort of free license.
> Haven't thought about free licenses in a long time (decades), so I am
> open to ideas.
> Anything to prevent the exponential growth of JS futility like this;-
> I don't think that thing even warrants a review and there are dozens
> more like it popping up. Enough is enough. :)
I'd have to agree with many of the others and figure that the MIT/BSD
license would be a good shot. MIT/BSD/LGPL only adds a few more letters
in from what I can tell.
I don't think I'd be too worried about forking, honestly. As I've
watched the various open source projects, major forks seem fairly rare
and only after other effects have failed.
I have no ideas of the legalities concerned, but if you change the My
Library name to something that can be trade marked, you can do the same
stunt that Firefox did. "You can copy our code exactly, but if you
change it you've got to call it something else." Hence Firefox and
That way, we'll have:
The Cowardly Anon's Library
Not Your Library
and the like.
From: Lasse Reichstein Nielsen on 6 Jan 2010 14:19
Chris Riesbeck <Chris.Riesbeck(a)gmail.com> writes:
> Lasse Reichstein Nielsen wrote:
>> Jorge <jorge(a)jorgechamorro.com> writes:
>>> "The Software shall be used for Good, not Evil" ?
>> Bad idea. It lacks a definition of both "Good" and "Evil", making the
>> license ambiguous, and if it had one, it would probably run afoul of
>> the Open Source Definition (6. No Discrimination Against Fields of
> but with an "or" instead of "and not" it's OK, right?
Only if Good and Evil encompasses all uses.
Morally neutral uses must be allowed as well ... if such exists.
I like it :)
Lasse Reichstein Holst Nielsen
From: Garrett Smith on 6 Jan 2010 17:12
David Mark wrote:
> On Jan 6, 6:36 am, Matt Sach <matts...(a)gmail.com> wrote:
>> On Jan 5, 10:57 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>>> As for the "goals":-
>>> * Mobile is more important than Internet Explorer
>>> Apples are more important than oranges? :)
>> I think "lemon" would be a more appropriate citrus fruit to represent
>> IE ;)
Sure, but having goals and writing them down has fundamental value. That
way everybody knows what it is. It is worse to not have goals than to
have bad goals. Bad goals can be changed.
>> I've been
>> trying to push them myself, in order to get them thinking and learning
>> (not necessarily from my tutelage; I'm certainly nowhere near you and
>> others here), but it's very difficult to get folks to learn when they
>> have an "easy" way out that they already know.
> All you have to do is demonstrate how it fails. :) As for help doing
> that, it's coming (is it ever). For anyone who hasn't seen the signs,
> cinsoft.net is going to be the new quirksmode.org (for libraries and
> frameworks, rather than browsers). Oh, and with competent
> explanations. :)
You can try organizing and aggregating:
Those could all be improved by automation. Significantly
Please don't make me click through to every example and don't make
complicated test cases (like an functional/example page that has every
usage of the property/method).
For such a test suite, the relevance of specification is important.
Writing a testrunner will take time, but the investment will pay off
with managing complexity of testing variance across browsers.
YUI Test is not a bad one. You will need to patch it, though, and may
want to change many things about the design of it.
The asynchronous aspect of YUI Test is an important part that many other
test runners or unit test frameworks just totally ignore..
The asynchronous part of YUI Test could be redesigned so that it allows
pause between tests, and so that it uses a Timing abstraction (too much
setTimeout eats up CPU and crashes poor Blackberry). Also it would be
useful to have similar to Selenium `waitForCondition` (so the test can
complete before the allotted expiration time).
Also in YUI Test, it would be nice t ohave smaller methods. Not only
would this help make YUI Test more readable, but when debugging, the
developer should not have to step through a 300 line function just to
get to where YUI Test has dispatched and event. Oh, it is so painful my
fingers hurt just thinking about clicking debugger "step over" that many
YUI can be forked. Submitting but reports to YUI is a waste of time,
IME. Just patch and go.
From: Garrett Smith on 7 Jan 2010 00:20
David Mark wrote:
> On Jan 6, 5:12 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> David Mark wrote:
>>> On Jan 6, 6:36 am, Matt Sach <matts...(a)gmail.com> wrote:
>>>> On Jan 5, 10:57 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>>>>> As for the "goals":-
>>>>> * Mobile is more important than Internet Explorer
> I think not.
>> Those could all be improved by automation. Significantly
>> Please don't make me click through to every example and don't make
>> complicated test cases (like an functional/example page that has every
>> usage of the property/method).
> No clue what that means. :)
By functional test, here, I am referring to here is a static demo page,
like any of the Hixie or Juriy tests.
Another sort of functional test is use-case functionality. Selenium is
useful for that.
Clicking each example is tiresome and doesn't give a comprehensive view
of what works and what fails.
A functional test that tries to test everything about one specific
property is worse because it is not focused on one thing.
Unit tests are the well-suited for testing browser features and dom
features because each aspect can be tested.
insertBefore suite might contain: testReturnsNode, testRefNodeNull,
testHeirarchyRequestErr, testWrongDocumentErr, testNoModificationErr,
A unit test page can do those things and separate out the test cases to
test functions, where each function tests one specific thing, using
maybe 4-8 lines of code for each test function.
>> For such a test suite, the relevance of specification is important.
> Or that.
Specifications should provide guidance for the outcome of assertions and
also can help outline an API.
For example, any of the DOM APIs could be tested, ECMA specs can be
tested. Such tests would be valuable to me. I believe they could
potentially contribute usefull to the w3c APIs. I doubt that anyone in
the w3c would be able to see it. I might have had better luck if I had
shown them actual test cases. That takes a bit of time to set up. You
can see my input to that here:
I'm no sure what the status is; I can't follow up because I was banned
from the list.
>> Writing a testrunner will take time, but the investment will pay off
>> with managing complexity of testing variance across browsers.
> I don't need to write one. I have what I need for now.
That's what Hixie said. I still think he's missing something valuable in
that. He doesn't (or didn't) see value in it. His acid tests, to me, are
not valuable tools that I can refer to to see what works where, etc. His
functional tests require a click through to each one are not even
indexed that well. Having to click through does not provide a
comprehensive view of what fails and what passes because you have to
click through to each one, and in each browser, to see those results.
What is valuable for me, is to see the appendChild method, see where it
fails, and see an example of it.
>> Also it would be
>> useful to have similar to Selenium `waitForCondition` (so the test can
>> complete before the allotted expiration time).
> You are getting way ahead of me.
For example, say you ahve an XHR adapter. The adapter makes a call to
the server, and when the response comes, you need to verify that response.
A test case wants to test the success of a response.
To test that, the test case gets a connection. Opens, sends, and then
*waits* for the response. The `success` callback fires asynchronously;
it cannot be tested until the xhr is complete. The problem is, we don't
know when that will happen.
What YUI Test provides is a `wait` method. `wait` takes two arguments:
callback, and timeout millis. So what you can do is to wait for a while.
The assertions that verify the message of the ajax call are performed in
the `wait` callback.
I would like a `waitForCondition` method, so I could, say:-
xhr.complete == true;
I don't really like that order, but it is consistent with the `wait`
Also, I don't like how most x unit frameworks have expected result
first. TestNG (Java) is switched, which makes sense, but inconsistent.
>> Also in YUI Test, it would be nice t ohave smaller methods. Not only
>> would this help make YUI Test more readable, but when debugging, the
>> developer should not have to step through a 300 line function just to
>> get to where YUI Test has dispatched and event. Oh, it is so painful my
>> fingers hurt just thinking about clicking debugger "step over" that many
>> times. Ouch.
> Whatever YUI is doing with their stuff is irrelevant.
If you try the test runner, you might get a feel for the API and about
testing. You'll find what you don't like and maybe you might find things
that are valuable in it. It is a lot better than JS Unit.
The problems in the design of the YUI Test are solvable; it's not like
he painted himself into a corner.