How can introducing another EBay implementation because a fellow committer is 
just too far down that road really ok for the rest of the project?  Try 
explaining it to anyone trying to use the system why this was done - 
unfortunately we can't (don't know the original gap or what was solved by this 
new system) so we have basically forked the Ebay component because someone 
didn't want to do the proper analysis about even what they're getting with this 
new system.

It's just unfortunate.  Fellow committer - again thanks for trying to push 
things forward - you do that that after and we all appreciate it, but if you 
weren't in such a hurry sometimes, we'd have more substantive conversation that 
would lead to a better software product for you, your customers and the rest of 
the community.  Instead, we've not only got a new Ebay component, but everyone 
also gets additional analysis to on top of trying to figure out Ebay.

Cheers,
Ruppert

On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote:

> I will try to have a look today, in order to introduce a 3d party in this 
> discussion...
> 
> Jacques
> 
> From: "Scott Gray" <scott.g...@hotwaxmedia.com>
> Haan,
> 
> I'm sorry to hear that, I guess if no one else feels strongly about this then 
> I'll bow out and allow you to continue with your
> duplication of existing code.
> 
> Regards
> Scott
> 
> HotWax Media
> http://www.hotwaxmedia.com
> 
> On 3/02/2010, at 11:52 PM, Hans Bakker wrote:
> 
>> Scoot,
>> 
>> i am sorry. As I mentioned in another email jacopo already saw that we
>> are too far down the road. I cannot change. Anybody with Ebay knowledge
>> would appreciate this contribution and replace the old ebay component
>> directly with the new one.
>> 
>> I am sorry i am very busy here and cannot spend more time on this.
>> 
>> Hans.
>> 
>> p.s. my reaction was on my proposal to have a "work in progress list
>> added" irrelevant anyway.
>> 
>> 
>> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote:
>>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote:
>>> 
>>>> Hi Scott,
>>>> 
>>>> I only wondering why you send this email, can you explain that to me?
>>> 
>>> As I mentioned below, your commits indicated that you are continuing in 
>>> your current direction which is something I disagree
>>> with, I was hoping some agreement could be reached through discussion.  Was 
>>> it in some way unreasonable to send the email?
>>> 
>>>> Anyway, thanks for asking, i still think it is required. It showed with
>>>> the ebay component:
>>>> 
>>>> 1. creators of the original component would have liked to discuss it.
>>> 
>>> Maybe I missed them but what questions have you asked regarding the current 
>>> implementation that someone could respond to?
>>> Regardless, once the code becomes part of the project there is no longer 
>>> any requirement for the original developers to provide
>>> you with code support, and that lack of support doesn't necessarily give 
>>> you a green light to create a duplicate component which
>>> will ultimately cause harm to the community.
>>> 
>>>> 2. a non committer had already developed a component as we just did.
>>> 
>>> Huh? How is that relevant?
>>> 
>>>> so a lot of effort could have been saved here.....
>>>> 
>>>> However if nobody wants it, sure i will give up.
>>>> 
>>>> don't worry about that.
>>> 
>>> It's not about not wanting your eBay contributions, it's about avoiding 
>>> duplication in the project which will leave users
>>> confused and with additional analysis to do and I'm yet to see a good 
>>> reason for this other than that it is easier for you.
>>> 
>>>> 
>>>> Regards,
>>>> Hans
>>>> 
>>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote:
>>>>> Hi Hans,
>>>>> 
>>>>> Based on your recent commits I guess your considering this discussion 
>>>>> over?
>>>>> 
>>>>> Regards
>>>>> Scott
>>>>> 
>>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote:
>>>>> 
>>>>>> 
>>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote:
>>>>>> 
>>>>>>> Jacopo,
>>>>>>> 
>>>>>>> what we need is a wiki page where people can announce activities and
>>>>>>> plans. Not only from committers but also from contributors and perhaps
>>>>>>> even users.
>>>>>>> 
>>>>>>> I have proposed this before.
>>>>>>> 
>>>>>> 
>>>>>> I think we already have something similar:
>>>>>> 
>>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>>>>>> 
>>>>>>> In this case we tried to extend the existing ebay component but found
>>>>>>> out that the xml interface could never support the required functions as
>>>>>>> we needed them.
>>>>>> 
>>>>>> This is not a good reason for stopping your research about supported 
>>>>>> features and building a new component.
>>>>>> The valid options I see are:
>>>>>> 1) adding *new* features to the original component using the different 
>>>>>> technology
>>>>>> 2) and enhancing the existing features, where needed, using the XML 
>>>>>> approach or
>>>>>> 3) reimplement the existing features in the original component with the 
>>>>>> new technology before enhancing them
>>>>>> 
>>>>>> Jacopo
>>>>>> 
>>>>>>> Please also remember that not all required functions
>>>>>>> were known from the start.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote:
>>>>>>>> Hi Hans,
>>>>>>>> 
>>>>>>>> first of all, thank you for contributing this big amount of code.
>>>>>>>> 
>>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote:
>>>>>>>> 
>>>>>>>>> Hi Scott,
>>>>>>>>> 
>>>>>>>>> I am also not sure if we need 2 components. That can only be decided 
>>>>>>>>> by
>>>>>>>>> the users of the original Ebay component isn't it? I do not know the
>>>>>>>>> user requirements of the original ebay component.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Having two components with potentially overlapping features for the 
>>>>>>>> same integration in the official trunk will cause
>>>>>>>> maintenance problems and confusion; I guess we will all agree on this.
>>>>>>>> I am not asking you to redo your job, it is too late, but... can we 
>>>>>>>> agree that from now on, before implementing a new
>>>>>>>> feature in the trunk (or, even worst, before adding a new component) 
>>>>>>>> we have to study and understand what already exists and
>>>>>>>> do our best to enhance the existing stuff?
>>>>>>>> 
>>>>>>>>> Now we moved the new functionality to a separate component it is 
>>>>>>>>> getting
>>>>>>>>> more clear if the old component is still required or not.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> This is a pain, but we will do this, I can't see another solution now, 
>>>>>>>> as soon as you have completed your work: instead of
>>>>>>>> you studying the original ebay component we will have to study your 
>>>>>>>> new work and verify if the new component implements all
>>>>>>>> the features covered by the old one and in the same way; if this will 
>>>>>>>> not be true... I don't know what we will do.
>>>>>>>> 
>>>>>>>> Kind regards,
>>>>>>>> 
>>>>>>>> Jacopo
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Let us first complete the new component and get it fully tested and 
>>>>>>>>> then
>>>>>>>>> restart this discussion.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>> 
>>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote:
>>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at 
>>>>>>>>>> eBay's services and start thinking that this commit is a
>>>>>>>>>> bad idea.
>>>>>>>>>> Please correct me if any of the following is wrong:
>>>>>>>>>> - When you originally brought this up, you described the problem as 
>>>>>>>>>> one of XML vs. API but I think what you actually meant
>>>>>>>>>> is eBay SDK vs. using XML directly?
>>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality 
>>>>>>>>>> but it appears to me that it simply abstracts the use
>>>>>>>>>> of raw SOAP or XML when interacting with the actual API?
>>>>>>>>>> 
>>>>>>>>>> Based on this I'm not sure that we should have separate components 
>>>>>>>>>> but that the XML based component should just be moved
>>>>>>>>>> to using the SDK (assuming there are only advantages and no 
>>>>>>>>>> disadvantages in doing so).  Doing anything else will just
>>>>>>>>>> result in twice as much code to maintain with both components doing 
>>>>>>>>>> the same thing (or worse yet, similar things but with
>>>>>>>>>> huge differences in implementation from the user's perspective).  
>>>>>>>>>> Converting the existing XML integration to use the SDK
>>>>>>>>>> will ensure that we have a single solution in place and that no 
>>>>>>>>>> functionality in the existing component is lost.
>>>>>>>>>> 
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>> 
>>>>>>>>>> HotWax Media
>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>> 
>>>>>>>>>> On 2/02/2010, at 7:16 PM, hans...@apache.org wrote:
>>>>>>>>>> 
>>>>>>>>>>> Author: hansbak
>>>>>>>>>>> Date: Wed Feb  3 03:16:07 2010
>>>>>>>>>>> New Revision: 905876
>>>>>>>>>>> 
>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev
>>>>>>>>>>> Log:
>>>>>>>>>>> move the java api functions from the existing ebay component to the 
>>>>>>>>>>> new ebaystore component: no functional changes
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>>>> 
>>>>>>>> 
>>>>>>> -- 
>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>> 
>>>>>> 
>>>>> 
>>>> -- 
>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>> 
>>> 
>> -- 
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>> 
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to