Emerald Editor Discussion
September 25, 2017, 12:43:21 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
   Home   Help Search Login Register  
Pages: [1]
Author Topic: The nature of plugins  (Read 3944 times)
0 Members and 1 Guest are viewing this topic.
Gem Cutter
Posts: 106

« on: July 11, 2006, 01:49:48 am »

I think I'd like to add some more clarification to the nature of plugins.  In my mind, anything beyond "what makes it easy to edit text of any kind" should be put into the plugin category.  Syntax files help "make it easy to edit text of any kind", so they can stay, as can features like spaces-to-tabs, search/replace, etc...  Everything else is a plugin.  FTP, CVS and SVN support should be plugins, for example, as they're more specific tools.

So that's the first and more important criteria.  The second criteria would obviously be popularity.  Just because it helps it make it easy to edit text of any kind, does not mean it should automatically be built-in.  i.e. If its not very popular then it should be made a plugin.

Given those two prioritized criteria, I should point out that just because something is relegated to a plugin, does not mean the dev team shouldn't build it.  If the dev team thinks a feature is popular enough, they should take it upon themselves to build an official plugin to do the job.

As for installing plugins, it should be a simple enough task for end-users to find/download/install plugins.  I'm envisioning a system similar to Firefox Extensions or even the SMF Forum Mods.

The last thing is, while I think popularity should be considered secondary, if there are performance losses associated with making a feature a plugin, then perhaps popularity needs to actually be the most important criterion.  That is, if a feature will not be as fast or efficient as a plugin compared to being built-in, and that feature is also very popular, then even if its not directly related to "making any kind of text easier to edit", it makes sense to build-it-in.

Senior Miner
Posts: 95

Maintainer of Obscure and Unused Ports

« Reply #1 on: July 11, 2006, 07:57:00 pm »

This sounds like good and reasonable guildlines.  I had always kind of assumed in discussions of plug-ins that the core dev team would develop and maintain core plug-ins to provide some of the more popular options...

-->>  This Space 4 Rent  <<--
Site Administrator
Master Jeweller
Posts: 618

« Reply #2 on: July 11, 2006, 08:56:50 pm »

There was some debate over this previously, and I think these are reasonable guidelines.

My own view was that the basic editing core, including file handling, syntax handling and search/replace would be core, while most things would be plugins, so that it would allow a pick'n'mix to occur.

More importantly than that, though, it means that it allows the installation to be kept minimal if that's what you want (which would be faster).

"Cleverly disguised as a responsible adult!"
Pages: [1]
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.081 seconds with 18 queries.