On 3/24/14 5:49 PM, Kay Schenk wrote: > On Mon, Mar 24, 2014 at 12:24 AM, Jürgen Schmidt <jogischm...@gmail.com>wrote: > >> 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. >> > > This makes sense and generally what I would think of when I think about > "extensions". > > >> >> And my experience showed also that often core changes are necessary to >> make specific extensions possible. >> > > > hmmm...not something I would have thought. OK.
it's not a big thing it's simply the fact that often API's are missing or do not exactly what you need. That was the normal way to improve or extend the API over time. Demand driven development if you want ;-) > > >> 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 >> > > Rest of your comments duly noted. don't get it wrong it is really much more motivating to do smaller things with success than starting with something bigger and get lost in the complex code base. The project is too big and many code is old and not in best shape (to say it careful). But debugging the certain problem and find the root cause is satisfying and can be fun of course ;-) 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 >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
