create new tag
, view all tags

Complies with API policy

As of 4.0, there are Plugins Api Policies which are intended to ensure that plugins will continue to work in future versions with little or no change. There were no policies for previous versions and, at this point, for anything other than plugins.

Note Just because a plugin does not comply does not imply that it doesn't work. Plugins that are marked as tested with 4.0 do work, at least for whoever marked it that way. It does mean, however, that there may be problems in future versions of TWiki. It also means that there may well be problems with mod_perl, since a number of plugins do not use a directive that is highly recommended in general but especially relevant to mod_perl. See Codev.UseStrict for more.

-- MeredithLesly - 06 Jul 2006

Quality focus is good. I am wondering however if adding a CompliesWithPolicy is the right thing to do:

Also, what is the criteria for a "yes"? Does this just apply to Dakar Plugins? What about Cairo Plugins that comply with the Cairo policy and have not yet been updated to Dakar? Or Plugins that have been designed to run properly on Cairo and Dakar, comply with Cairo policy, but not with Dakar due to dual mode?

-- PeterThoeny - 06 Jul 2006

Plugins are supposedly a large value of TWiki and yet there are problems with many of them. (Not to mention that it's rather specious to claim over 200 plugins when many of those are pre-Cairo, but that's what's called PR, I suppose.)

I'm hoping that the "quality focus" mantra is real and not just something that's designed to make potential users feel good. That means, for example, the rather large effort that CDot (primarily) and I put into creating a Plugins API policy document. That also means trying to have ways of users to determine whether to use a plugin. Have you looked at the large number of plugins that don't use the use strict; directive? All of those plugins can be considered iffy until fixed.

You've already derided the PluginsConformanceReport, so I'm not sure why you're bringing that as an alternative. And, as I said in the first paragraph of this document, there is a policy document as of 4.0, so a pre-Dakar plugin should be marked as "not applicable".

If the code a plugin runs under Dakar does not comply with Dakar API policy, it doesn't comply. Period. Any other code it may contain may be cruft or not, but it's also irrelevant to Dakar compliance. IMO threading conditional code throughout a plugin (or anything else) makes for a maintenance nightmare (and is poor programming) and there's no way to judge the quality of the plugin code at all, so I wouldn't mark any of those as complying. If, OTOH, if there are two different modules, one for Cairo and one for Dakar, and the Dakar one complies, then that's fine.

The developers will have to maintain it as best they can, just as they maintain everything else the best we can. If you want to use that criteria, then we may as well take out "tested against...", because that's inaccurate and often meaningless. If I try to use a plugin and see that it doesn't comply, then it will be marked that way.

If you're concerned about the length of the form:

  • Put in a twisty
  • hide the TopicClassification, as it's redundant
  • put a twisty on Plugin Info.
  • Remove InstalledOnTWikiOrg. That's easily found elsewhere and I don't have a clue why someone should care anyway.

The only reason people even see the damn form is because they have to scroll all the way to the bottom to download it anyway. Why not put a download link up top, if you're concerned about being friendly to users. I'm quite sure that most people either don't read anything on the page -- extension pages are some of the worst in terms of being friendly to users or their eyes are glazing over once they've gotten through the often excessively long Plugin Info section.

-- MeredithLesly - 06 Jul 2006

I share Peter's concerns on this; after all, we have enough difficulty maintaining the existing fields. Also, the plugin topics themselves are nicely non-judgemental. We have appraisals for judgements. What might be a better idea would be to add a field to the appraisal. it might also help to raise the profile of appraisals (which are, IMHO, under-used).

Note that if a plugin is Cairo-compatible, it is also by definition Dakar-compatible.

-- CrawfordCurrie - 07 Jul 2006

It may be Dakar-compatible, but that doesn't mean that it complies with the API policies. I got seriously tired of politely asking in every plugin dev topic where the plugin doesn't use use strict; to ask them to do so. I'd be more likely to check a checkbox than to go through the humongous list.

And, um, say what? There are tons of Cairo plugins that don't work with Dakar.

-- MeredithLesly - 07 Jul 2006

Having talked with CDot on IRC, what he meant to say is that if a plugin doesn't reach into the core and limits itself to TWiki::Func, it'll work on Dakar. Which of course is the point of having an API: things don't break if developers don't break the API.

The plethora of plugins that don't do this, however, are not Cairo- or Dakar- compliant. In the Cairo days many plugins had to reach into the core because there wasn't a robust enough API, so there's a good excuse for what many of them did. Having that code intermingled with Dakar code, however, is a really bad idea.

-- MeredithLesly - 07 Jul 2006

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2006-07-07 - MeredithLesly
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.