Consolidating Mods (or, a Plugin Interface)

At least 8 current maintained DC++ mods (BCDC++, StrongDC++, ApexDC++, and all of StrongDC++’s other immediate derivatives) exist which largely modify some cosmetic aspect of DC++ whilst keeping the core unchanged.

Some, but not all, of their functionality could be implemented via a plugin interface which would allow many users of those mods to instead use the official DC++ client. This has advantages in terms of:

  • bug reporting (rather than users in each client having to independently discover bugs, bug reporting could be more centralized)
  • bug fixing (rather than a choice of either each mod author separately patching his client or syncing with DC++ when it might not be appropriate)
  • security responsiveness (an important special case of bug fixing; especially a problem for second or third-tier derivatives which need to either wait for fixes to propagate down the mod dependency graph, remain vulnerable, or specifically re-implement some fix that will automatically appear for them in DC++ regardless)
  • security improvement, if features already extant in DC++ can be reimplemented in a safer scripting language as opposed to C++ (Python/Perl/Lua/etc all avoid entire classes of bugs by default which C++ code can be vulnerable to)
  • ease maintenance of somewhat fringe/marginal features which some people enjoy (for example, now-playing song/music spamming) but which aren’t necessarily appropriate to maintain in the core DC++ application
  • maintaining a DC++ brand image (every mod doesn’t have to be identical, but because each mod can lag, it can force users into unpleasant choices, which can hurt the DC++ brand)
  • user control of clients (some changes can be easy for technically sophisticated end-users to create and distribute, but again are not always appropriate for all users)

One such proposal, which I essentially support, has been implemented by Crise and proposed by him and Toast.

3 Responses to Consolidating Mods (or, a Plugin Interface)

  1. r2d2ex says:

    plugins are fun, but they can’t replace mods. can you imagine plugin, that:

    – allows user post images and gif-animated-video to chat (like greylink does)
    – forces to download first 1% in the begining and then all other file in random order to help avipreview work
    – adds own button in windows7 taskbar popup or to tray menu
    – put hash database, logs and download queue to sql storage to shorten loading time and easy searching on different criterias

    consider economical reasons: some mods (like flylink) makes customized builds for tens of large russian ISPs for money. it’s better for them to provide complete application, than just a plugin

    and at last (the main argument!), ask ApexDC developers: can they discontinue ApexDC and make all it’s functionalty as a plugin to original DC++? i’m sure, they won’t

  2. emtee says:

    As you can see in the post, actually Crise, the developer of ApexDC++ proposed (and created) the plugin system for DC++…

    Also, where did you read that the plugin system meant to replace mods and if DC++ introduces it then any mod should be discontinued? Mods go in their independent way as they did before while DC++ gets a plugin interface so it can be better and more customizable and may easily introduces some of the features mods currently have…

  3. Toast says:

    talk about not reading a single word that the blogpost was showing…

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: