Yes, in general I agree with you. We do use prototype, since at that time it seemed to have a good development community, and support structure. The dependance on a small group is a risk. I did not say we would not make the change, but it is not just about how good the code is, ease of migration is important.
The lack of progress on features, as well as the architectural limitations is an ongoing concern. On Nov 30, 2006, at 6:37 PM, RobG wrote: > > Deco Rior wrote: >> First, of all, good luck. > > Full agreement on that. > > [...] >> On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote: >>> On 11/30/06, Deco Rior <[EMAIL PROTECTED]> wrote: >>>> So... if Peter really wants to make his mark, can he at least >>>> try to >>>> keep the API the same or compatible with Prototype. >>> >>> The API is similar in some places but can't stay the same. I am >>> writing a namespaced library. >> >> Appreciate the NameSpace. That is easy to search and replace. >> >> But don't expect us to require complex regex to make the transfer, >> and if you do then supply the conversion scripts. Most migration >> technologies fail, not because of the feature vs. feature comparison, >> but because the barrier to migrate is too high. > > The only way that would work is to make Fork a namespaced version of > Prototype, and that clearly isn't what Peter is doing. > >>>> After over 12 months of investment, the barrier to migrate with a >>>> major code change to another library would be daunting. >>> >>> Fork probably isn't ready yet for this situation but eventually I >>> think the work would be worth it. >> >> Um...how big an app do you think we have? Any major code change is >> very costly, mostly in QA. We essentially are about 80% through our >> rewrite based on AJAX. A major code change is where we cannot simply >> script the code, and requires us to potentially touch each file. >> >> You should have seen the agony we went through in making the decision >> to get away from WebObjects! > > Then I'll guess that you aren't using Prototype for anything > critical either. > >>>> In any case >>>> it would need to be something with some muscle behind it (by that I >>>> mean, contributers, funding, third-party certification). >>> >>> Perhaps one day. Not many open source software projects start with >>> this much muscle. >> >> And you cannot build a mission critical solution on a startup open- >> source. Try and get SAS 70 certification on libraries with version >> 0.2a! > > Again, Prototype won't help you there either - the Yahoo! or Google > stuff might though. > > [...] >> One dumb question...what is there to stop someone getting a branch of >> prototype source and going off and making a better version? If Sam >> doesn't have time, that is okay...Do we need a Linus? > > Nothing, however you'd first have to be reasonably happy with the > 2,000 or so lines of Prototype as it is now and with the fundamentals, > otherwise you will never be happy with the result. It also doesn't > solve any of the issues you raised above - a forked Prototype may > cause > more heartache than it cures. > > The developers of Prototype have made some contentious architectural > decisions. Users should be aware of those and accept the limitations > that they enforce - lack of namespacing and extension of built-in > objects being two of the better known ones, I'd also add the > evalScripts method to the list (I think the concept is fundamentally > flawed). And yes, I think Peter is wrong to support it. > > Pretty much all of your concerns with Peter's library are equally > shared with Prototype, which seems to have 1.5 support personnel > who do > stuff from time to time when their day job permits. > > Lastly, I don't think this is a Fork versus Prototype thing: one > doesn't have to lose for the other to succeed. Competition is good, > mono-cultures are bad. > > > -- > Rob > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
