Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=mqnppQycyg683pAHm68ClrSPOqt3ymeYlmE/XqMFlZye642W/zIemyDVcU5XnBfiKN/X72xxNrVjW/1Q0zZ2gfKpz3UtSbOhbMEW5UnD7J755CJzlGmZV/JjD6KqEH8lm6rKWdU8ryQ/AlGbqbp5yhwqfwz7BubQ2bb1gHGaEFk=;
References: <1339649080.8905.YahooMailNeo@web171504.mail.ir2.yahoo.com>
 <0FFE0021-2A6F-440E-8D3E-37B8CB16FC0D@sabot-durand.net>
Message-ID: <1339654516.26745.YahooMailNeo@web171502.mail.ir2.yahoo.com>
Date: Thu, 14 Jun 2012 07:15:16 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: [VOTE] Converter framework
To: "deltaspike-dev@incubator.apache.org"
 <deltaspike-dev@incubator.apache.org>
In-Reply-To: <0FFE0021-2A6F-440E-8D3E-37B8CB16FC0D@sabot-durand.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=0A=0AYes, perfectly fine to explore the Converter stuff in a feature branc=
h and also perfectly fine to even do this in master IF we found a GOOD use =
case for it!=0A=0AI'm not a priori against adding new features, even if the=
y are a bit more heavyweight. But I really see no reason for adding complex=
 stuff which has no use case so far.=0A=0AThis also doesn't mean that this =
work was done badly and unimportant. It just means that - after a thorough =
review - we found an even better solution. Nontheless, Gerhards input was r=
eally important, as it provided a base ground for an in depth discussion an=
d review. Sometimes we need to test different ideas and ways and only when =
implementing it you will see if it gets complicated or if it turns out nice=
ly.=0A=0ALieGrue,=0Astrub=0A=0A=0APS: I'd be more than happy if our EE expe=
rts review the ConfigurableDataSource in depth _and_ if we get some input a=
bout a possible JTA module (see the discussion with Jason a few days back).=
=0A=0A=0A=0A>________________________________=0A> From: Antoine Sabot-Duran=
d <antoine@sabot-durand.net>=0A>To: deltaspike-dev@incubator.apache.org; Ma=
rk Struberg <struberg@yahoo.de> =0A>Sent: Thursday, June 14, 2012 8:03 AM=
=0A>Subject: Re: [VOTE] Converter framework=0A> =0A>=0A>+1 now but keep it =
for later.=0A>=0A>=0A>Antoine SABOT-DURAND=0A>-----------------------------=
----------=0A>http://agorava.og=0A>@antoine_sd=0A>=0A>=0A>=0A>Le 14 juin 20=
12 =E0 06:44, Mark Struberg a =E9crit :=0A>=0A>a.) What is this for? -> no =
one knows=0A>>b.) Do we need it in DeltaSpike? -> not yet.=0A>>c.) Do we ne=
ed it for JSF? -> No, JSF has it's own Converter logic=0A>>d.) Do we need i=
t somewhere else? -> No, not afaik=0A>>=0A>>So let's drop the Converter stu=
ff which is currently of no use and really complicated to get right?=0A>>Ju=
st remember that this was more or less a 1:1 copy of the Spring logic which=
 has not so easily extendible producer methods.=0A>>=0A>>[+1] Drop it, our =
code will get complicated enough anyway=0A>>=0A>>[+0] Meh, don't care=0A>>=
=0A>>[-1]=A0 keep it because it is very important (+ give use case and reas=
ons)=0A>>=0A>>LieGrue,=0A>>strub=0A>>=0A>=0A>=0A>