Idea: Common plugin for XFileSharing

Yeah, this seems to be a bit better after all. The login stuff is the same for all XFileSharing sites so there's no point separating it to different files, as all runners will extend the same class anyway.

tong2shot Wrote:
----------------------------------
> It's not possible to skip waiting time between captcha retry

But it is possible to reduce the wait time by the time it took to enter the the captcha without risk of any 'failed to wait' errors.
updated XFileSharing to implement.



ntoskrnl Wrote:
----------------------------------
> It is also rather difficult to remove the account details once added, as the account dialog doesn't allow empty user names or passwords.

Thought:: Without a FRD update to allowing empty user/pass or a button to clear user/pass details the plugin could become useless if someone incorrectly entered user/pass, XFileSharing will not allow any downloads as it throws BadLoginException("Invalid account login information")
* If this was changed to logger.warning("Invalid account login information"); return false;
the error would at least be recorded in app.log and the user could proceed with a normal download
* or login could be skipped if username was assumed invalid. eg. only one character long, or contained non-alphanumeric chars ??
Neither a perfect solution, but better than a useless plugin



Edited 1 time(s). Last edit at 06/04/2012 01:05AM by birchie.

I managed to set up a proxy and now I can access the SVN from here.


birchie Wrote:
-------------------------------------------------------
> But it is possible to reduce the wait time by the
> time it took to enter the the captcha without risk
> of any 'failed to wait' errors.
> updated XFileSharing to implement.

Nice catch.

Maybe we can improve the waiting time further. Is it true that the user only has to wait one time, no matter what? There are never two pages both with waiting times? If captcha or password has to be entered several times, the user only has to wait the first time? If these are true, we can easily improve the plugin.


> Thought:: Without a FRD update to allowing empty
> user/pass or a button to clear user/pass details
> the plugin could become useless if someone
> incorrectly entered user/pass, XFileSharing will
> not allow any downloads as it throws
> BadLoginException("Invalid account login
> information")
> * If this was changed to logger.warning("Invalid
> account login information"); return false;
> the error would at least be recorded in app.log
> and the user could proceed with a normal download
> * or login could be skipped if username was
> assumed invalid. eg. only one character long, or
> contained non-alphanumeric chars ??
> Neither a perfect solution, but better than a
> useless plugin

That could cause certain issues if users mistype their account details and then wonder (and complain) why it's not working. It's certainly worth considering if we get many complaints about not being able to remove the details though, at least until we fix it in the main program.

I received a RyuShare premium plugin request with account details yesterday, so we can add premium support right away. My suggestion is not to create separate plugins for premium, but to integrate everything into the same runner. This clutters it up a bit, but I think it's still better, as it reduces the work needed for making the actual plugins for the sites. Login and download are likely identical on each site, so there's no reason not to support premium on all of them. What do you think?

Premium support was easier than I thought -- our generic plugin also handles premium almost without modifications.

There are still some issues with file name and size. Sites (at least RyuShare) seem to show a somewhat different page for premium and non-premium users. File name and size handling needs to be completely different. I had a quick look at some XFileSharing sites and it seems that some of them use the same name and size handling. Maybe the common plugin should try a few common regexes?

One XFileSharing common plugin base for Unregistered, Free-Registered and
Premium-Registered users is an excellent achievement


tong2shot had an issue with checkNameAndSize() earlier ???
it should be possible to move this last bit of coding to the common plugin
using a series of either common regexes or the PlugUtils.check**functions

......

My main concern with the XFileSharing login, as it is,
was not a mistyped user/pass, as it can always be corrected, but
If user/pass is entered when the user has no registered account for the site
OR If user's registration for the site expires
The plugin won't work, as user/pass can not be cleared within FRD.

  # No plugin using XFileSharing has been released yet #
Any changes (like those I prev suggested) would be a short term solution to prevent
complaints of the plugin not working. A button within the FRD preferences to delete
the plugin's options xml file is the better long term solution.

I updated file name and size checking. Two name and one size regex are able to handle every site I tried. Now most runner classes are really short.

Two issues that I'm aware of remain:

1) Waiting time. Can we improve it further? Probably needs some testing.

2) maxDownloads. Premium likely allows >=10, but what about free and free account? Probably needs some testing too.

I did some quick testing with wait time. AsixFiles and JalurCepat do not allow skipping the wait time at all, and CosmoBox allows skipping it completely (even on first captcha attempt). The sites use FourTokens, Captchas and ReCaptcha respectively. We have automatic recognition for the former two with 100% accuracy, so in practice multiple attempts are only required for ReCaptcha.

We should probably check if all sites using ReCaptcha allow skipping the wait time.



Edited 1 time(s). Last edit at 06/08/2012 05:37PM by ntoskrnl.

ntoskrnl Wrote:
--------------------------
...
> Two issues that I'm aware of remain:
...
> 2) maxDownloads. Premium likely allows >=10, but
> what about free and free account? Probably needs
> some testing too.


in plugin.xml

Language: XML
<attribute id="maxDownloads" value="10"/>
<attribute id="maxAllowedDownloads" value="1"/>

sets max to 10 (or 50,100...whatever) but defaults to 1 download
unregistered users won't get parallel download errors
and registered users can increase max downloads on the preferences page when entering user/pass

Unfortunately I don't think FRD reads that property from plugin.xml. The PluginMetaData class doesn't contain code for that. Have you tested though? I might have missed something.

If that doesn't work, the only option is probably to set it to 10 and hope that users understand to configure it lower if necessary...

I did test and it worked when i modified an exiting plugin.
Just tested again with a new plugin from scratch.....and it didn't work
...
The existing plugin would have already settings elsewhere and tricked me



Edited 2 time(s). Last edit at 06/17/2012 11:35AM by birchie.