Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.77 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Wed, 14 Nov 2012 17:16:09 -0800
Subject: Re: Proposal for contributing code from GraniteDS
Thread-Topic: Proposal for contributing code from GraniteDS
Thread-Index: Ac3Cu4Vc4OGXNjx+RqS9vUKmweLyQQAE0W6T
Message-ID: <CCC98259.4882D%aharui@adobe.com>
In-Reply-To: 
 <CAHo_kB45+fjzSP7wvjPO7gBZLx8a7TeYFR8jnYTApZb2LKQobQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.13.0.120411
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 11/14/12 2:57 PM, "Franck Wolff" <franck.wolff@graniteds.org> wrote:

> Alex,
>=20
> My answers below:
>=20
> 2012/11/14 Alex Harui <aharui@adobe.com>
>=20
>> OK, I skimmed through the files.  Code-wise, it looks very nice, so than=
k
>> you for being willing to donate this work.
>>=20
>> One thing that was bugging me as I was looking at the code is this: Did =
you
>> look at the Java code for the Java equivalents when writing your code, a=
re
>> any portions of your code "substantial copies" of the Java sources, and =
if
>> so, does Java's source license allow you to leverage their code, and if =
so,
>> without attribution?  I would think there are BigDecimal equivalents in
>> other platforms as well so this must all be "ok", but I think we need to=
 be
>> sure.
>>=20
>=20
> Good point. All classes from the org.granite.math package were written fr=
om
> scratch, but part of the BigDecimal code is inspired (not copied though)
> from the Java implementation. What do you suggest in order to make sure
> that there is no legal issue?
If you've never seen their code, I think we are good.
>=20
>=20
>> Some other questions:
>> 1) Terminology/Names: I saw a reference to "Bean" in one of the files.
>>  That
>> is also a Java concept, but is that term trademarked?  I think "JavaBean=
"
>> is, but I think it would be hard to trademark just "Bean".
>>=20
>=20
> I don't think Bean is a trademark and we can change that term if necessar=
y.
OK, I think we are ok here as well.
>=20
>=20
>> 2) Packaging:  All the packages are currently org.granite.*.  Do you hav=
e a
>> large body of users who will complain loudly if you change the package
>> name?
>>=20
>=20
> I don't think so: changing package names is just a research / replace
> operation...
OK, we'll I'm open to suggestions for package names and the swc name.  I
think it shouldn't have granite in it because it is your company's name. So
    org.apache.flex.math
    org.apache.flex.reflect
    org.apache.flex.validation
And for the swc, other than the Container dependency and ObjectUtil
dependency, I didn't see a lot of other Flex dependencies so I think all of
these classes can go in one new swc?  I don't see a reason to put it under
"experimental".  I considered names like "asjava.swc" since these are all
based on java features?

>=20
>=20
>> 3) I noticed FormValidator had a reference to mx.core.Container.  That t=
ies
>> you to the "mx" project in SVN.  Does it work with Spark Form?
>>=20
>=20
> Yes, it works with Flex 4 and Spark Form. The explicit use and import of
> mx.core.Container could be changed to something based on reflection if
> necessary.
This is not important for the donation, but Container and ObjectUtil bring
in a huge set of dependencies which will not be good for smaller apps.
>=20
>=20


--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui