Let me throw in one aspect concerning the new contrib system: It maintained the original idea of shiftig load from *using* a contribution to *maintaining* that contribution. The unbeloved hash sum over a contribution has the sole purpose to allow for *automatic freshness checks*. Downloading a contribution is part of the usual build step when developing, done by the Generator behind the scenes, not a separate step. That's it.
This differs from all other popular systems (including NPM!), which require the user of a contribution to separately take care of downloading/installing it, besides using it in builds (think of 'npm install' vs. 'grunt build'). So you could say that the qooxdoo approach is more comfortable for the contribution users, which seemed like a good idea at one point. But maybe it doesn't have to be that way. Maybe the right balance between authors and users of contributions would be to put a little more load on the users by requiring an explicit download step for the contributions. This would make the contrib infrastructure much simpler, and would give the users of it more control when a particular contrib they are using is being updated on their local system. It would also require them to actively check for updates for any of them. But as this pattern is so common nowadays, maybe nobody would feel offended. The discussion in this thread was largely a contrib authors' discussion, and I haven't seen contrib users raise their voices. Maybe it's about time to shift a little load back to the users and separate downloading contribs into an independent and explicit Generator step. My 2c, T. On Wed, May 28, 2014 at 6:49 PM, John Spackman <[email protected]> wrote: > Hi Petr > > I don’t think it needs to be split – that’s what the generator is for, to > assemble just the bits that are needed by your app. There is a fairly > large core of classes which are always needed, and maybe something could be > done to reduce those dependencies, but any such optimisation would only > affect small applications. > > If anything, it is debatable whether there should be a distinction between > Desktop/Server/Mobile because the generator can put together just what your > app needs. > > Qooxdoo is not particularly light weight; AIUI that’s what the ”website” > version was created to do, not that I’ve used it. However Qooxdoo is suited > to building large apps (one of my apps is 146,000 lines of unminified JS) > and that’s a different use case. > > I don’t think there is an inherent issue with wrapping existing, well > written libraries in a Qooxdoo-compatible class (e.g. a rich text editor, > jqPlot, etc), but there is little motivation in making a contrib of anything > if there isn’t anyone to use it. > > That’s a circular argument of course: shrinking user base == less users want > to contrib == product gets dated == less users want to start using it == etc > etc. > > John > > From: Petr Kobalíček <[email protected]> > Reply-To: qooxdoo Development <[email protected]> > Date: Wednesday, 28 May 2014 14:40 > > To: qooxdoo Development <[email protected]> > Subject: Re: [qooxdoo-devel] New contrib website > > Guys, > > From my perspective - I think that what is becoming a problem as well is its > monolithic architecture. Qooxdoo is not modular, every time I use it I feel > like working 15 years back on some C++ project. JS is a very dynamic > language and I think it should be used that way also in Qooxdoo (split the > core, components, make it modular and just minify). > > Second problem is that a lot of contributions are wrapping third party code > into a "qooxdoo way". This is ridiculous - if there is a good third party > library one should be able to use it even without rewriting the whole API > into qooxdoo style. > > There are another things as well, look at Angular for example how easy > databinding can be. > > My 2 cents;) > Petr > > On Wed, May 28, 2014 at 10:50 AM, panyasan <[email protected]> wrote: >> >> This is an interesting and important discussion! >> >> Because of the points you raised, I think the contrib infrastructure is so >> critically important. I know that since qooxdoo has a corporate sponsor, >> the >> dev team is not totally free to chose its priorities, but the value of a >> library depends on its ecosystem, and the growth of the ecosystem depends >> on >> how easy it is to contribute (see npm). >> >> >> >> >> -- >> View this message in context: >> http://qooxdoo.678.n2.nabble.com/New-contrib-website-tp7585740p7585750.html >> Sent from the qooxdoo mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Time is money. Stop wasting it! Get your web API in 5 minutes. >> www.restlet.com/download >> http://p.sf.net/sfu/restlet >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet_______________________________________________ > qooxdoo-devel mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
