Critical Extensions

Critical extensions are either those which if they break would cause many pages to "break" and as such, these extensions should be considered as important to support (for upgrades, etc). Another way to look at this: if we aren't willing to support these, then we shouldn't encourage people to use these. The known dependencies of these are listed to help in smooth upgrades.

Dewikify: for helping with dewikifying (The mediawiki 'extension' itself only provides the wikionly tags. The dewikify script itself relies on the default format of the monobook skin. If that changes, the script is likely to break.)

Recentchangesfilter: extension that augments the recent changes list with the ability for complex filtering (depends quite heavily on the internal structure of MediaWiki so extension likely to break on all major version upgrades, although it is also quite easy to update the extension to match the MediaWiki version)

Jasonk 22:44, 12 March 2006 (EST): I think this extension may end up being critical in order to manage discussions. It will enable each discussion area to have recent changes listed. It also enables users to better manage recent changes in areas important to them, something which will be increasingly important as the site scales up. This may be possible via the watchlist, which is the only reason I wouldn't designate this immediately as critical, but I certainly wouldn't call it non-critical yet.

Austin 13:27, 13 March 2006 (EST): Good point, I actually hadn't thought about using this as an includable page rather than just for each user using it to filter their own recent changes.

Bill Flanagan 8:27, 11 August 2007 (EST): I'm going to look into the extension. If we can create a map that exists as a wiki page that controls the behavior of the filtering, we can isolate at least some of the problems associated with upgrading. Content can be managed independent of the structure. Development can be done by more than one person: the technical details of modifying the code can be separated from the way the site is categorized. This may be more of a meta-goal than a specific outcome but I'll look into it and find out.

Austin Che 11:13, 11 August 2007 (EDT): I'm not sure what you're suggesting but there's already nothing in the extension that has anything to do with content.

Bill Flanagan 12:00, 11 August 2007 (EST): I'll look into the extension to see how it works.

Austin 23:17, 12 March 2006 (EST): not really, but you also get the ease of entering it and auto-updating if the link changes (given the URL, this seems likely). This may also be implementable using the interwiki linking feature in the same way we link doi's so we would be able to do something like [[part:B0010]]. The benefit of using an extension is that allows for future more complicated expansion. For example, we could perhaps insert the part description or a part sequence or whatever else we wanted.

RS 17:44, 26 May 2006 (EDT): As an example, we may now want to update this extension to point to the "new" registry. (And by we, I mean Austin :) ).

Bill Flanagan 8:36, 11 August 2007 (EDT): I notice this extension's link has "gone missing". Is there another place we can link to it for information? Thanks!

Austin Che 11:13, 11 August 2007 (EDT): Nope...This is one of those extensions that probably is better if it didn't exist, at least in it's current form. Once the registry actually gets an API for getting more information about parts other than just linking to it, then it might actually be more useful.

Bill Flanagan 8:36, 11 August 2007 (EDT): OK. Just researching what's here and seeing how it works. I'll track it over time.

Wibbit: Extension for using Exhibit and also includes a table editor that can be used for non-Exhibits also

Non-critical extensions

Non-critical extensions are defined as those which don't significantly change pages or remove important functionality. Users may use these as they wish and they should be able to easily adapt if we turn them off suddenly.

Bill Flanagan 8:36, 11 August 2007 (EDT): This is a fantastic extension. But I've heard that it puts a big load on the server when 20 or more folks are using it. Have there been any measurements done on the load it's responsible for? Since it uses AJAX (i.e., receiving and sending tons of small messages from every client while in use), even a bigger server may not allow it to scale very well. There may be a way to do the same thing with IM clients such as GoogleTalk. The log of the IM sessions could be scrolled onto the chat page interactively while the chat is executed within GoogleTalk. This is a long-term item but I wanted to make a note of it here. Please reply if you have anecdotal evidence of how useful it is and how it could change to work better.

Austin Che 11:13, 11 August 2007 (EDT): See this thread. Some seem to be able to get it to scale while others can't. It also links to this WebChat2.0 which looks neat but seems to be less browser compatible (doesn't work on my Opera). But I think the idea of using a web chat program that talks with IRC is great.

Bill Flanagan 8:36, 11 August 2007 (EDT): Ilya told me that GoogleTalk is a good candidate rather than IRC. I'll look at the htread you mentioned. I love AJAX. But the performance hit on the server is major. If a single GoogleTalk bot monitoring a chat is updating the server in real time, it still can be a problem if it's going into a Wiki page: every update is a new document. The database gets creamed. But if it's a "special page" being updated, the overhead is a lot less. The bot can then write the entire log from the chat into a "discussion" page as a single write when the chat is over. I have a GoogleTalk bot that I downloaded last week that does some of this. It's another long-term item but one that I think has some possibilities.

Special:Editcount: Show edit stats for users. Can be linked as [[Special:Editcount/user]] and included {{Special:Editcount/user}}

UserDefaultPage: allow users to change their default page in their preferences