Just to remind you, deprecation does not imply removal of the code, only moving the method into the "Deprecated" section of the documentation.

The API is currently used in the following extensions:

1. AccessStatsPlugin
2. ActionTrackerPlugin
3. AlbumOfSnapsPlugin
4. BatchUploadPlugin
5. BlogPlugin
6. ChecklistPlugin
7. ContributorsPlugin
8. DirectedGraphWebMapPlugin
9. EditHiddenTablePlugin
10. EditInTablePlugin
11. EditTablePlugin
12. EditTablerowPlugin
13. FlowchartPlugin
14. HeadlinesPlugin
15. ImageGalleryPlugin
16. InlineEditPlugin
17. JavaPasteAddOn
18. MessageBoardPlugin
19. MultiLangPlugin
20. NamespaceManagerAddOn
21. NatSkinPlugin
22. PingBackPlugin
23. PreferencesPlugin
24. ProjectPlannerPlugin
25. RedDotPlugin
26. RedirectPlugin
27. RedirectRegisterPlugin
28. SeeSkin
29. SetVariableAddOn
30. SignaturePlugin
31. SlideShowPlugin
32. TigerSkinPlugin
33. TopicTranslationsPlugin
34. URLCachePlugin
35. UserHomePageAddOn
36. WebPermissionsPlugin
37. WysiwygPlugin
38. XpTrackerPlugin

(extensions not tracked in svn are not listed.)

-- Contributors: CrawfordCurrie - 28 May 2007

Discussion

You do not put a proposal "ReadyForReleaseMeeting" until people have had a chance to discuss it here in Codev.

Our release meetings take too long when we put up proposals that have not been digested and we usually end up not making any decision.

That is also why the release process says that it is a customer advocate that puts a proposal in ReadyForReleaseMeeting.

Since this is not a proposal that involves code of any kind - and therefore no risk of a new bug - there is no reason why it cannot be decided after the feature freeze and make it to 4.2.0 so there is no reason to rush it to tonights meeting (the 28th).

-- KennethLavrsen - 28 May 2007

Sorry; there's no help in the form, and I'm never sure what the right procedure is. Maybe if you added some nameless labels (inline doc) like we have in the Bugs web that would help....

-- CrawfordCurrie - 28 May 2007

I do not have a strong opinion on this one, but in general I'd prefer not to deprecate popular functions, even if you can do the same with another function. This function is used by 38 extensions in the SVN repository alone (probably more in extensions published on twiki.org only), meaning that all those extensions need to be updated in future releases or risk being labelled as non-compliant at least. The XpTrackerPlugin uses this function 10 times.

Writing getViewUrl(web, topic) is shorter than getScriptUrl(web, topic, 'view'), and also easier to discover in the list of functions.

-- PeterThoeny - 29 May 2007

Agreed; my concern is soley that the API is getting quite large, and very similar functions tend to confuse users. I can't think of any simple rules to offer for when getViewUrl should be used in preference to getScriptUrl, mainly because AFAIK there are no circumstances in which it's preferable.

-- CrawfordCurrie - 30 May 2007

Since the only motive is to avoid a function call that can be avoided by calling another funtion with different parameters I am against deprecating the function. We can avoid issues in the future by keeping the API stable.

-- PeterThoeny - 30 May 2007

Let us vote on this after 4.2.0 release. No urgency.

-- KennethLavrsen - 03 Jun 2007

See the recent benchmark results in InvestigatingTWikiPerformance. The more "dead" code we leave lying around, the slower TWiki gets.

-- CrawfordCurrie - 06 Jun 2007

I find this is a little stretched. This little procedural function call is negligible to the initialization and object binding going on elsewhere in the core.

-- PeterThoeny - 06 Jun 2007

As I said, death of a thousand cuts. Heal one cut, that's another milliscond you never have to worry about again. Func is already one of the largest (and slowest to compile) modules. But the main drive is keeping the API clean and simple, and not allowing it to get overweight. As I said above, I can't think of any simple rules to offer for when getViewUrl should be used in preference to getScriptUrl, mainly because AFAIK there are no circumstances in which it's preferable. So why keep it?

-- CrawfordCurrie - 08 Jun 2007