(09:08:13) CDot: I added jscalendar to sharedcode for precisely the reasons you give. (09:08:48) PeterThoeny: why not just leverage the one in edittableplugin? (09:09:01) CDot: Because ActionTracker has no dependency on EditTable (09:09:33) CDot: Action tracker also depends on Attrs (09:09:41) PeterThoeny: so, what do you propose to do for the twikiforms? (09:09:48) CDot: And will (*at some point in the future) depend on DBCache (09:09:59) CDot: The twikiforms? (09:10:10) CDot: Oh, you mean the forms in the plugins web? (09:10:23) PeterThoeny: no, the twikiforms feature of twiki (09:10:31) PeterThoeny: where you attach forms to a topic (09:10:41) CDot: Not sure what you mean..... (09:10:42) PeterThoeny: they currently do not support data form field (09:10:56) CDot: You mean _date_ form field? (09:11:35) CDot: This is what Thomas Weigert was asking for, yes? (09:11:36) PeterThoeny: http://TWiki.org/cgi-bin/view/TWiki/TWikiForms (09:11:46) PeterThoeny: i think so (09:12:17) CDot: I wasn't proposing to do anything with it (09:12:20) PeterThoeny: the date field type can be done either in the core or as a plugin (09:12:29) PeterThoeny: either way, it needs jscalendar (09:12:36) CDot: OIC. Well, we discussed shipping jscalendar with the core (09:13:08) CDot: Personally I accept your counter-arguments to doing that; it doesn't work on all platforms. (09:13:36) CDot: To me, extending form editing capabilities should be done in a plugin (09:13:44) CDot: as not everyone will want it. (09:14:11) CDot: So as long as jscalendar is available to plugins..... it needn't go in the core. (09:14:17) PeterThoeny: that is a good argument (09:14:26) CDot: Trying to acknowledge your goal of keeping the core light and fast (09:14:49) CDot: I agree that SharedCode is not the _right_ way to ship code libraries (09:14:59) CDot: but currently it's the _only_ way (09:15:10) PeterThoeny: and only used by your plugins (09:15:20) CDot: yes (09:16:03) PeterThoeny: so, when upgrading your plugins and the dependencies/packaging changes users will have dead code (09:16:14) CDot: ? (09:17:14) CDot: Do you mean, if a user upgrades AT then SharedCode must be upgraded as well? (09:17:41) PeterThoeny: assuming we find a good way of packaging/documenting contributed code, which requires to repackage SharedCode (different module names; split up into several modules; different pub tree etc), (09:18:00) PeterThoeny: you'd need to change the existing plugins (09:18:08) CDot: I have no problem with that (09:18:34) PeterThoeny: and all users who downloaded and installed that plugin version would install the latest version (09:18:51) CDot: ... and be warned that the dependencies were out of date, yes (09:18:54) PeterThoeny: and have dead SharedCode in the system (09:19:05) CDot: yes (09:19:06) PeterThoeny: and can't be sure if it can be deleted or not (09:19:23) CDot: Correct (09:19:38) CDot: there is no way to test back-dependencies (09:19:55) PeterThoeny: these are exactly the issues I think we should try to avoid :-) (09:19:57) CDot: though that is something checkDependencies could be extended to do (09:20:04) CDot: easily enough (09:20:38) CDot: You can't avoid issues by ignoring them (09:20:49) PeterThoeny: that is not my point (09:21:06) ***CDot listens (09:21:22) PeterThoeny: i was trying to say that we should agree on a way to share contrib code before cranking out code (09:21:40) PeterThoeny: in order to avoid these upgrade issues (09:23:52) PeterThoeny: e.g. recommended module sub-structure / naming, (09:24:36) PeterThoeny: way of documenting, also so that contrib code summaries can be compiled and listed (as the plugins do) (09:25:02) PeterThoeny: a way specifying bin dir, pub dir, (09:25:22) PeterThoeny: recommondation what to bundle together, what to package separately (09:25:22) CDot: the unzip methodology for installs (09:25:36) CDot: That is _much_ harder to do. (09:26:02) CDot: What would your preference be? (09:26:42) PeterThoeny: i see two possible solutions, not sure which one is better (09:27:09) PeterThoeny: (1) use existing plugins mechanism for contrib code (09:27:27) PeterThoeny: contrib code like Attrs would be just another plugin (09:28:25) PeterThoeny: but with a flag indicating that this is a "behind the scene plugin", e.g. not listed in the bullet list of plugins (but still possible to list for admin use) (09:28:50) PeterThoeny: what are the module names in SharedCode? (09:29:22) CDot: TWiki::Plugins::SharedCode::* (09:29:52) CDot: TWiki::Attrs is the only exception, I think (09:31:46) PeterThoeny: (2) something in parallel to plugins, similar functionality (09:32:03) PeterThoeny: TWiki::Contrib is the base (09:33:29) PeterThoeny: then you would create a package called TWiki::Contrib::MathCalcUtils or whatever you have (09:34:26) PeterThoeny: in the Plugins web at twiki.org we'd need to create a 4th category for contrib packages (09:34:52) CDot: yes (09:34:58) PeterThoeny: besides plugins, skins and add-ons (09:35:17) CDot: yes (09:35:50) ***CDot is not sure they are not addons, according to the strict definition (09:35:51) PeterThoeny: not sure which way is better, needs some more neuron work (09:36:04) CDot: the second way is clearly superior (09:36:10) PeterThoeny: for example, if some contrib also needs pub space and bin space (09:36:20) CDot: as they will (09:36:39) CDot: note: contribs are not always perl code (09:36:53) CDot: I shipped jscalendar as pub/jscalendar-0.9.6 (09:37:22) CDot: perhaps it should be pub/Javascript/jscalendar-0.9.6 (09:37:56) CDot: On bin scripts; the discussion about bin subdirs for plugins happened, but never went anywhere (09:38:01) PeterThoeny: no, it should be more consistent (09:38:09) CDot: example? (09:38:29) PeterThoeny: brainstoming on (not sure how well at this time of the nigt) (09:39:04) PeterThoeny: package TWiki::Contrib::JsCalendar (09:39:35) CDot: there is no perl code (09:39:55) CDot: we don't ship javascript in lib (09:39:57) PeterThoeny: and doc page JsCalendar (no good, contrib needs to be in the name) (09:40:09) CDot: why? (09:40:31) PeterThoeny: so that contrib code can be discovered and auto-documented (09:40:45) CDot: That doesn't require a naming of the topic (09:41:04) CDot: search for the form type "CodeLibrary" (09:41:35) PeterThoeny: could work (09:41:48) CDot: It can't be auto-documented in the way Func is documented (09:41:53) PeterThoeny: although the form definition might be missing (09:42:02) CDot: because code libraries will _not_ be installed on twiki.org (09:42:17) CDot: If the for def is missing, it isn't a Contrib module! (09:42:21) CDot: ^for^form (09:43:21) PeterThoeny: no, if you copy a topic with a form to a web, and that web does not have the form, you can't edit the page! (09:43:39) PeterThoeny: anyway, minor detail (09:43:42) CDot: (As we discovered on WRS recenlty!) yes (09:43:52) PeterThoeny: can be done without form (09:44:08) CDot: Yes, could use a Category or other Wikibadge (09:44:10) PeterThoeny: with a simple setting like* Set (09:44:26) PeterThoeny: * Set CONTRIB_DESCRIPTION = ljkahdlkjashdfl (09:44:31) PeterThoeny: or the like (09:44:53) CDot: OIC; you want to have a perl code header module for every contrib? (09:45:21) PeterThoeny: that needs to be investigated (09:45:24) CDot: You do realise what that will do to performance? (09:45:26) PeterThoeny: sounds like useful (09:45:37) PeterThoeny: doc in pod (09:45:51) CDot: Yes, it's done that way if you use Build (09:46:01) PeterThoeny: and extracted by the perl pod plugin (09:46:11) CDot: Why? (09:46:19) CDot: Easier to use Build (09:46:23) CDot: Doc is static (09:47:33) PeterThoeny: the perl module does not need to be loaded unless needed (09:47:49) CDot: WAbsolutely (09:48:14) PeterThoeny: option (1) is also worth looging further into (09:48:41) PeterThoeny: would be a very simple model users already know (09:48:42) CDot: In what respect? I am nervous about the performance of plugins discovery, and don;t want to make it worse (09:49:17) CDot: If every shared code block has to be "discovered" it will run like a dog (09:49:25) PeterThoeny: performance is a good point (09:58:05) CDot: But a fundamental is that check function in Func. Without it, we (I) enter a world of pain. (09:58:07) PeterThoeny: well, (1) and (2) should be looked at in more details, with the questions we listed above (10:01:59) PeterThoeny: could contrib code be considered add-on? (10:02:05) PeterThoeny: with a twist? (10:02:12) CDot: I though about that, and decided no. (10:02:26) CDot: Add-on has a specific definition. (10:02:35) PeterThoeny: for example, the skins have an official way of packaging (10:02:43) PeterThoeny: and we enhanced it with the skin browser (10:03:27) PeterThoeny: but isn't it a little bit blurred, e.g. jscalendar? (10:04:06) CDot: An add-on is a functionality increment (10:04:21) CDot: a contrib is _not_, from a user perspective (10:04:31) PeterThoeny: good argument (10:04:36) CDot: So users need to be exposed to "AddOn" pages (10:04:43) CDot: but _not_ to contrib pages (10:04:49) CDot: (necessairly) (10:04:56) PeterThoeny: as for packaging/naming, it needs to be defined and documented in a clear way (10:05:10) CDot: So I think they need to be packaged slightly differently