Dojo is not associated with Microsoft in any way. Not that I know of. I'm not sure where you are getting that from. http://dojotoolkit.org/foundation/
>From my understanding, Dojo is funded by IBM, Sun and others shown above though, and your point is a good one -- well funded open source libraries are long lasting. (but Microsoft has it's own "Atlas" toolkit... not working collaboratively with open source, they don't 'usually' do that, no) On 11/30/06, Deco Rior <[EMAIL PROTECTED]> wrote: > > > First, of all, good luck. This is a big endeavour, and if you feel > you can be successful we should applaud you for your enthusiasm. A > little arrogance comes we the territory I think (but you did make me > cringe a little). > > > On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote: > > > > > Hi Deco, > > > > 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. > > > > For example, > > > > new Insertion.Bottom(id, html) > > > > becomes > > > > FORK.Mutate.insertBottom(id, html) > > > > > >> 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! > > > > > > >> 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! > > > > > > > >> No matter how good the code is, unless I have some degree of > >> certainty that the next version of IE will not break it we cannot > >> commit. > > > > I too need this code to work with IE 7. > > Just an example...the point is that a library that is not maintained > because of one key developer is a risk. > > In many ways this has made us look at DOJO, since SUN, IBM, and > MICROSOFT are all vested heavily. Say what you want about the code, > but the bottom line is that we can do everything we need to do even > though it is not elegant. It is funny, PHP kinda of falls into the > same category ;-) > > Plus we use lasso which has its advantages also. > > 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? > > > > > > > > Peter > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
