On 3/22/14 12:27 AM, Kay Schenk wrote: > On Fri, Mar 21, 2014 at 4:05 PM, Andrea Pescetti <pesce...@apache.org>wrote: > >> On 20/03/2014 Kay Schenk wrote: >> >>> Every once in a while a topic arises on this list and gets a response like >>> "that might be a good idea for an extension". >>> >> >> Right, but most of the times it is just a wish. The API available to >> extension developers does not allow to do everything. So it is very >> important to distinguish between responses that take into consideration >> what can really be done with an extension and responses that don't. > > > Of course, this is critical! > > >> >> * Is is a good idea to steer new developers into extension development >>> maybe as an introductory step? >>> >> >> Probably it would be more effective to have more, well-defined and >> verified (in the sense above, i.e., that someone with the needed knowledge >> has verified them) easy tasks. Building an extension still requires skills. > > > As far as "development" goes, creating an extension *might be* easier than > coding changes to source. Of course, extension development is not as easy > as some of our "easy tasks".
yes and no, you can make a lot mistakes with extension but the same is true for core changes. My experience from the past showed that extension are quite good for features that are not interested for all in the same way. External product integration for example where you need a commercial license. The connector is free but make no sense without the other product. This can help to grow the eco system. And my experience showed also that often core changes are necessary to make specific extensions possible. In general I would always prefer new features directly in the core and in ideally implemented in C++. And in the end it is easier to maintain. Our bundled extension concept needs some rework ... Volunteers should start with bug fixing, debugging existing code and nail down a problem on the root cause can be of course a challenge and motivation. You can learn a lot about the existing code and do over time more complicate things. But better starting small and grow over time than starting big, failing and lose motivation after some initial posts ;-) Juergen > > > >> >> >> * and, assuming we can track down some of proposed extensions, where is a >>> good place to record these for future reference? >>> >> >> It seems we have https://wiki.openoffice.org/wiki/Extensions/Ideas ; but >> looking at https://wiki.openoffice.org/w/index.php?title=Extensions/ >> Ideas/Calc&action=history I see no indications that we are using it the >> right way (again: checking that it is possible with the current API to >> implement those ideas). It would be good to ask the API list for a quick >> validation of that page. >> > > Ok, thanks for this info -- I will check it out and confer with the API > list as well. What occurred to me after I sent this would be to just log > them into BZ under the "extension" category, and "enhancements". No need to > create another special area. > > >> Regards, >> Andrea. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
