As you might know, probably half of our plugins are for sites which are basically the same. These sites use a script called XFileSharing: [sibsoft.net]

Because the sites and hence the plugins have a lot in common, the usual procedure for adding support for a new XFileSharing site is copy-pasting an existing plugin. Unfortunately code duplication quickly ends up being a maintenance nightmare and is generally frowned upon (not to mention all the useless code stored in the SVN and loaded at runtime).

My idea is to create a common ancestor plugin which every XFileSharing plugin would extend. It would contain a runner class (and possibly a ServiceImpl if we want account support) which would have all the usual methods. However, instead of private methods it should have protected methods so that they can be overridden in subclasses if necessary. The methods should also be split into small pieces so that subclasses can override only what is necessary (for example, the checkNameAndSize method could call checkName and checkSize). Captcha handling and other such things should be generic enough to handle all common types, again to reduce code duplication.

Implementing this should be fairly trivial -- only a few hours of work. However, rewriting and testing all existing XFileSharing plugins is quite a task (though I'm sure it will pay off later). Rewriting the plugins isn't very critical so I don't think we need to hurry with that.

I won't have time to work on this until Sunday, but feel free to start hacking if you want. I think I can find time to check or review code earlier too if necessary.

What do you think?

I use Ant script derived from FRD "new plugin" Ant script to serve this purpose. Yes, most of them share the same code, but some of them have very different code.

I'm sorry if my previous post and this post is not quite elaborative, I just woke up Generally I support ntoskrnl's idea. I'll see what I can do in this matter.

+1

-------------------------------------

I've committed my first attempt to create XFileSharing common plugin.

For testing purpose I've also committed (but haven't released, plugins version are unmodified) following plugins that use XFileSharingCommon plugin :
- asixfiles (2 pages, FourTokensCaptcha, registered user is supported)
- jalurcepat (1 page, 'captchas' image captcha, registered user is not supported)
- ryushare (2 pages, no captcha, registered user is supported)
- cosmobox (2 pages, ReCaptcha, registered user is supported)
- movzap (video site, custom run, no captcha, registered user is supported)

Please check, review and correct the code.

Thank you.

Hmm, seems like I cannot checkout the SVN on this internet connection. There's something between me and the server that blocks certain requests.

Vity, could you please set up https, svn and/or svn+ssh access on the SVN server? Currently it only allows plain http, which is insecure (compared to https and svn+ssh) and slow (compared to svn and svn+ssh). I'm sure the blocker proxy doesn't speak svn, and even more certain that it can't read anything that is encrypted with TLS or SSH.



Edited 2 time(s). Last edit at 05/30/2012 03:47PM by ntoskrnl.

@Ntoskrnl: Sorry, I don't know how to set up these things...

-------------------------------------

Configuration is always annoying... I guess it'll have to wait until Sunday then.

Great work tong2shot

Revision 1 of XFileSharing looks better
the individual plugin code is simpler

I've made minor changes.

Premium account support hasn't been implemented, because I never have premium account. Yeah I'm that cheap..

Here is my idea regarding premium account support :
- PremiumUserFileRunner will extend RegisteredUserFileRunner, but 'extend RegisteredUserFileRunner' doesn't sound
right. Maybe we should find better names for RegisteredUserFileRunner, and others.
- I guess login code for PremiumUserFileRunner is the same. If login code is different then just override it.
- PremiumUserFileRunner will override run() and checkDownloadProblems().