Let us first finish the new component....sometime this coming week.... then we will have a look what to do next....
regards, Hans On Sat, 2010-02-06 at 07:44 -0700, Tim Ruppert wrote: > Hans, could you please comment on this ASAP? I see that additional commits > keep going into this new component which doesn't seem like it's getting us > closer to reconciling the differences between them and getting back to one > common component that everyone can build on. > > Cheers, > Ruppert > > On Feb 5, 2010, at 7:28 AM, Tim Ruppert wrote: > > > Responding to this message - per Jacopo and David's request. Hopefully > > this gets us back to discussing how we can go about fixing the ambiguity > > that has been introduced and will push us to a consolidated front on these > > features: > > > > --- > > > > My recommendation - even at this point - is that we start to have a > > discussion about all of the things this new component does, and the people > > who are using the old one can put all of their feature coverage on the > > table - then we can discuss how to bring them together. This may be one > > ebay component which utilizes both XML for some things and the SDK for > > others - but without knowing the feature coverage - we're screwed. > > > > In this case - it matters very little to anyone what the technology choice > > ends up being - it's all about: > > > > 1. Making it easier for everyone who downloads OFBiz to know what to do > > with eBay > > -- These multi channels sales are more and more important each day in this > > economy. > > 2. Consolidating so that next time the SDK adds something that the XML does > > not, we can make good decisions about how to achieve the new features. > > > > Let's have this conversation - Hans, if you can provide a quick outline of > > what is being supported by all the functions that are newly implemented - > > this should be easy since the development was just done. Then maybe Marco, > > Ashish and Jacopo - people who helped build the current ebay component - > > can put the features out on the table for comparison as well. Once we have > > that, we can easily do the necessary gap analysis and discussion about what > > technologies support what, etc, etc. > > > > it could be that XML supports everything that we want and this new SDK > > becomes something that we might want to remove - or that this new > > implementation is the way to go and remove the old one - or even some > > hybrid of the two - but we won't know until we understand first what we > > need it to do, then what it can do currently, and come together on how to > > do it. > > > > Cheers, > > Ruppert > > > > On Feb 4, 2010, at 10:58 PM, Sam Hamilton wrote: > > > >> Couple of things > >> > >> 1. calling one ebay and one ebaystore is confusing when browsing the > >> source tree - perhaps once we know what the difference is between them > >> call them that? If its correct - call one eBay-XML and the other > >> eBay-API for example. > >> > >> 2. eBay has a huge amount of developer documentation once we know what > >> the difference is how about putting a README file in the folder of each > >> pointing to the eBay docs showing what each component is capable of > >> achieving? http://developer.ebay.com/ > >> > >> 3. If the ebaystore module does everything that the ebay module > >> currently does then why is getting rid of ebay module a bad thing? > >> > >> Sam > >> > >> > >> On 05/02/2010 12:42, Tim Ruppert wrote: > >>> 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 > >>>>> > >>>> > >>>> > >>> > >> > > > -- Antwebsystems.com: Quality OFBiz services for competitive rates
