News:

Looking for a good read? Check out the SimpleDesk Team Blog.

Main Menu

Plugin system

Started by Gruffen, May 21, 2010, 08:26:51 PM

Previous topic - Next topic

Gruffen

OK, I'm going to let a secret out now.

One idea we've been discussing over the last day or so is the notion of a plugin system - modules that you can plug into SimpleDesk to implement new functionality.

Exactly how this would work isn't entirely decided yet, but I wanted to open the floor for discussion, with some of the preliminary thoughts we've had on it.

Plugins would normally be installed via the package manager, however they would not normally make any changes to SD code at all. In theory there should be no reason why you couldn't just drop the files into the relevant folder and then just go configure it from our admin page.

Most of the plugin architecture would revolve around interfaces in the code for permissions, preferences, admin menu items and so on. The idea is that the plugin architecture should make it trivial to expand those areas without any actual code edits at all.

The plugin architecture is less geared to little tweaks and layout changes - though of course you could just as easily use a regular mod package for that through the package manager.

The architecture would be able to do its own checks against SD version so if you try and use a package for a mismatched version it won't work. Most of the time I don't expect this to be a huge issue though ;)

For those wondering about it, it would naturally be more a hook style implementation, with specific places to link into the SD code, rather than classes and subclassing (mostly because SMF 2.0 and SD itself aren't OOP structured and implementing things in classes isn't necessarily a great plan)

Exactly what form the code would take is unclear though, so it's not like I can throw out examples of construction at this point, because I simply don't know.


Part of the reason I'm bringing this up now is because I want to get a feel for a few things:
1. Are people likely to want to write mods for SimpleDesk through something like this?

2. I already have stated one candidate for this plugin system - converting report-to-moderator into a helpdesk ticket. What other things would people like to see?

3. I actually realised one "core" feature would possibly be better as a plugin, email notifications, and could be done entirely within the structure I have in mind already.

There's arguments both for and against it being core, though, so would you have any strong feelings either way about that being a plugin? Given the criteria given above, that is.

4. For the purposes of the next question, assume we're going to be doing the plugin core, and a few plugins for it, which will be team-maintained.

Since they're inherently dependent on SD as "mods of mods" as such, they won't be allowed on SMF's mod site under current rules, meaning they'll have to be published here. In that situation, do we want to encourage you guys, the community, to produce plugins, or would you rather we did it primarily?
(And if you guys as a community want to be involved in writing plugins, do we go down into writing a mod site to review/publish them?)



I'm not in a position to confirm the full range of options any of these things have, simply what we think could be really good. If nothing else, it's a proof of concept of doing mods that influence behaviour without actually modifying any new code.

FreeMe

in all honesty i think it could be useful, will be something no other mod has ability to do

tfs

If it makes it a better product, I'm for it.  If it slows down the overall release schedules, I'm not as much for it.  If it makes us less likely to solidly integrate things into the SD core, I'm against it.
A good tree cannot bring forth evil fruit, neither can an evil tree bring forth good fruit.

Gruffen

Better product, yes.

Slows down overall release schedules, sort of.

Breaking it down in to a core and modules makes maintenance generally easier, since you keep the code located in a single place. Had I really been thinking longer term than I was at the outset of 1.0, I'd have made it even more modular than what this would entail, in all likelihood.

It would naturally alter the release cycle in a big way, but not necessarily a "slower" one. Since instead of having a release every x months or whatever, we do a major release, further apart, and publish official plugins in the interim - that's the difference between mods and plugins as far as this is concerned; something like the email notifications system being moved to a plugin changes very little of the core code in reality. All that it actually does is change how things are loaded, and whether they're loaded out of the box, or with a minor download.

So instead of SD 1.2 having a crapton of features, it would have the big-ticket items that can't be readily pluggable, and the smaller pluggable items can be published between 1.1 and 1.2 - so really, users would get features faster, not slower.

I note your concern about 'solid integration', and it's perfectly valid. The real idea of the plugin system at its heart is to ensure that plugins that are plugged in are done so as if they're fused to the core. I would, before I dive into my spiel and explain the logic behind such a move, like to ask what your main concerns are with it.


If nothing else, we could build it and publish things like email notifications as a plugin that it comes with, turned on by default. The end result to the user is almost identical in practice, and it's only very (very) subtle things that would change - instead of calling a function by name directly, it would be part of a list of functions that would be called, for example.

For those familiar with SMF's innards, the mechanism is much like the template layering, the theme announces on install that it wants to use certain layers (normally: html, body), then you have layers introduced elsewhere in the code (SimplePortal, SimpleAds, do this to great effect, and as of 1.1, we use them in a couple of places). This is all done by having a central list of layers to load and manipulating the list on both more and less permanent levels.

I look at the roadmap and some of the items on it seem very much more like things that would be pluggable rather than built into the core, and some of them seem much more core level items, particularly base UI stuff.

I can tell you what I have in mind, actually, for where it came from originally: the SMF calendar. It was added fairly late in the original dev cycle (of 1.0 I believe) but it wasn't originally intended to be core. The idea was that it would be split off into an SMF mod, albeit an officially supported one (not just like ones by the SMF Customization Team, as it stands right now at least) but actually receiving full team support and be extensible separately to SMF core.

To a point that's actually why it's so lacking in what many people consider core features - it got tossed into the sack, and it's never really been overhauled into the 2.0 dev cycle, meaning it seems almost like it's out of place and caught in the headlights, to mix my metaphors.

By splitting things out into a pluggable system, they can be tested and enhanced independently, meaning they can be upgraded without having to wait for a new full release.

I do see where you're coming from, very much so - the immediate concern is like that with SMF mods, when things change in SMF, the mods can break, authors stop maintaining them etc. By making them official extensions of SD, with an architecture that avoids all the icky stuff that goes with mods normally, they are just features you need to pick that you want, rather than features that come with it out of the box.

Maybe email notifications was a bad one to pick, but the fact that what is otherwise a core feature could be turned into a pluggable item with little extra work - right now, all that exists in SVN for notifications is a placeholder for the code, some general level configuration items and some user preferences... all these items would exist just as cleanly in a pluggable environment, and if anything, it's *better* to make it pluggable.

Right now, if I want to add a new admin option, I have to:
* define it in the ACP
* document it as part of the ACP code
* add it to the installer
* add it to the uninstaller/cleanup
* add language strings

By making it pluggable, I'd be able to keep all that in one main place - the plugin's own files, keeping it together, making maintenance of that feature easier, not harder, in the longer term.

[FailSafe]

How would the features be decided then if they are core or a plugin? What I could see end up happening is that people would whine about having to download a feature as a plugin instead of it being core. I'm not saying that doing a plugin system isn't a more logical approach, personally I think it is, but i'm simply saying that other people will complain about the "more work" being made for them.

As for the community, i'm not sure that theres a lot of availability of plugin developers. So in terms of community support i'd say not to expect for much help. I for one, would love to contribute to the project but with my lack of skills I would just be more of a hinderance than a contributor. One problem I can foresee is that the Devs would have to "train" plugin developers instead of taking the time to build SD on their own, unless a new system was in place to go along with plugin development release. The majority of the plugin construction would have to be within the team, which is not so bad I suppose. I don't really see any hit in release time for this for the reasons that you've stated Arantor and for the basic fact that it's not like anything new is being developed. Instead of being built into the core, features are just being built as plugins.

Personally i'm all for this idea. It'll clear the core SD out of bulk, and I trust the Dev Team to build a plugin system that is simple and easy to use.

Gruffen

I guess it comes back to how you define what a core feature should be. The logical definition is that it's something that the 'average user' would expect to find in place already, probably by default.

The trouble is, one person's core feature is another's plugin. I've already cited the SMF calendar which is very much in that camp.

Part of the mentality behind the design is to allow the line to be very much blurred. Unlike SMF mods, which are by nature somewhat unreliable at times because of the whole structure of direct code editing and because there's no real valid basis for expectation of support or maintenance on most SMF mods, I see us as a team providing some plugins for our own system as far less unreliable generally, but having a system that is inherently less unstable for extending the core can't hurt at all.

In reality, it's almost more about the way it's presented rather than what's going on under the hood. If I presented it as if it were a core feature, even though it'd be using the pluggable system, you'd naturally call it core - and without looking at the code, would you know any different? But I get the impression it's almost perceived negatively because I gave it the bad title of plugin.


Maybe email notifications was a bad idea to make it clearly out of the core, even if that's actually the best way to build it. Something I just got reminded was that we've talked about a front page feature, for use in standalone mode (the idea being to avoid something of the necessity of portals in SA mode). It's not going to be a major feature in most cases, so it's actually likely to be better in the core than not, in almost every case.

I guess, ultimately, the real distinction between core and plugin is what can't easily be made a plugin. UI changes can't readily be made into plugins, neither can changing some of the core processes - custom ticket fields isn't something you'd want to extrude out of the core too far, meaning I'd see it being very much a core process.

Applying the same logic to SMF, post moderation strikes me as a core feature because it's much harder to apply consistently if it's not in the core itself.


I've had some feedback in this thread, some more privately through other sources. The feel I'm getting is:

1. People likely to write mods for SimpleDesk (i.e. that aren't the dev team)?
Probably not. But it doesn't stop us building the framework since we'll use that too.

2. What types of plugins?
Well, some smaller features for later versions would fit into this category. Report to moderator, the front page at least.

3. Email notifications being noncore?
I'm getting the impression that this is a bad idea presentationally, even if the code is 100% identical if it were distributed as a plugin package. I think the route here would be to build it as if we distributing it separately, but actually just bundle it with the master packages, similar to how WP does with Akismet. (See, if it's good enough for them... :P)

4. Publishing primarily team maintained stuff, and setting up a 'customize' site?
I'm getting the impression most of the SD userbase won't build their own addons, such that a true cust. site with uploads, reviewing, etc. isn't necessary, and that the majority of plugins should be handled by the team rather than third-party developers.


Is this a fair assessment of the state of play?

[FailSafe]

I'd agree that it is.

I'm sure that your BT/QA team is more than capable of being able to determine which of the features should not be included into the core by default and should be saved from plugin, and from there sort out the list as to what is possible development-wise to have as plugins.

Also, if the title of plugin is going to be perceived negatively then how about giving it a new name like "extension"? Or there is also the slightly corny route of having plugins as "drawers" for the SimpleDesk. :P

As for having a large third-party developmental group to help you, then I think you're right in assuming that it's not going to be that large. The way I see it is that since SD is a niche inside of SMF there is not as large an area for modders to write their own plugins as there is for SMF.

However there is still the point about how easy it's going to be for users to pick up SD development and start running with it, and how large the learning curve with it is. Depending on how significant you want user plugin development to be, it's something to take into account.

Just my 2 cents.

Gruffen

QuoteI'm sure that your BT/QA team is more than capable of being able...

I think they're capable :)

QuoteAlso, if the title of plugin is going to be perceived...
Quote

Extension is still borderline, there's still the "it isn't in the core" stigma. I like drawers a lot, actually, because while it is corny, it's absolutely true - a desk is more than functional without drawers, as something to lean on, etc, and while the drawers may be fundamental parts of the desk's functionality, they're something you insert after the desk is assembled, and you may do things by removing the drawer entirely to work on it.

Also 'module' isn't bad either.

QuoteAs for having a large third-party developmental group to help you...

SMF has only amassed something like 460 mod developers total to date according to the mod site stats, so I really think the field is going to be much smaller - so I'm comfortable not bending over backwards to support 3PD, but at the same time providing the structure in the code should it take off.

QuoteHowever there is still the point about how easy...

The same pre-requisite of being able to code will be there, however you're not working with as much XML generally, nor are you working with trying to edit existing code and the support issues that brings with it. However it should be simpler overall to build and maintain.

Bᵃ

+1 to Drawers

Nice one. :)

B

Conquer Club - Free Global Domination Game
Think the board game Risk on steroids!

Senkusha

So.... for example, slated in 1.1, you've mentioned a mini-wiki tag system where you can link in wiki-style to ...other tickets? (I'm assuming -- I only skimmed the feature list).

An example of a Plug in might be somebody expanding this feature further by allowing a more full blown wiki implentation inside of SimpleDesk (version history, maybe linking outside of SD, and into SMF topics/posts ... honestly though, I can't think of a situation where something like that would be needed -- but hey, you never know, right? ... which could lead a Wiki Main Page or Table of Contents or something...etc.)

Gruffen

While yes you could in theory build a wiki plugin, that not something we'll be actively pursuing as a line of development (which is why both myself and Nas are working with Niko on his wiki mod instead)

The wiki syntax as currently implemented allows you to link one ticket inside another, I do need to make that work inside regular post parsing rather than where it currently is though.