Idea: Common plugin for XFileSharing

I made some changes too. I made captcha handling more object oriented, which cleans up the runner class a lot. Plugins can still add their own captcha handling by overriding the getCaptchaTypes method.

Another bigger change is that I moved the first "method_free" handling into the while loop so that it automatically decides whether to make 1 or 2 "method_free" requests. There are some waiting time related logical issues (it seems to wait twice at the moment, and probably others, maybe with captcha and password too). You know the XFileSharing sites better, so can you take a look at it?

Before I can proceed further, we need to decide whether free account support is worth having. It adds a lot of complexity to the plugins, and as far as I've understood, there are absolutely no benefits for the user (is this correct?). It is also rather difficult to remove the account details once added, as the account dialog doesn't allow empty user names or passwords. As for premium plugins, I'm not sure if it'd be a good thing to add new separate premium plugins for each XFileSharing site. Maybe we should forget about any account support until it's better in the main program. What do you think?

- At current state, it's possible to enter infinite loop in run().
- For some sites that I've used, there are benefits for being registered user. For example : bigger download quota (ex : 200MB a day vs 3 GB for 3 days), bigger file size download limit ( 200MB vs 500MB ), reduced waiting time, don't have to type (Re)captcha, no download limit (counter on how many times the file has been downloaded).
- Some sites don't show captcha if you're registered user. At current state, it is mandatory to input captcha, and possible to input twice, it should be maximum once (or none, for some sites you don't have to input captcha as registered user).
- Yes, at current state it's possible to input password twice, it should be once.
- Most sites don't detect waiting time between captcha retry. I haven't yet found site that detects waiting time between captcha entry, but from XFileSharing free source code that I read, it is possible that server throws "Skipped countdown" error message. At current state it is executed twice, and possible to executed four times.
- As for premium plugins, I don't know . But it would be great if it is considered, to anticipate users request for premium plugin. I don't mean we should provide premium plugin for every XFileSharing plugins. But to consider to create common class for XFileSharing premium plugin.



Edited 3 time(s). Last edit at 06/03/2012 12:08PM by tong2shot.

Fair enough, we will keep account support.

We can change the while loop to a for loop so that it throws a PluginImplementationException if it detects an infinite loop (for example after looping 5 times). We can also skip waiting time if counter != 0. If we ever find a site that doesn't allow skipping waiting time, we can add the waitTimeCaptchaRetry method back.

Captcha and password are currently detected automatically and the user is prompted every time they are detected on the page. This should match the behavior users will experience when downloading with a browser. Is this ok?

Could you check and fix the duplicate waiting times and other things so that everything is done in the correct place and the correct number of times?

Oh one more thing, at first attempt, I tried to create abstract class for XFileSharingRunner, it run fine at TestApp console, but failed when I tested in FRD GUI. So I created concrete class instead and throws exception in checkNameAndSize() if it's not overrided.

It's probably related to XFileSharingServiceImpl -- if that is abstract and is referenced in plugin.xml, it will throw an exception when the plugin is loaded in the main program. I changed plugin.xml to point to LibraryPlugin. Can you check if it works now?

I haven't replaced while loop with for loop. But commented last stepWaitTime. The problem with current loop state is : if site decides to change code, thus the plugin won't work, users will be shown captcha repeatedly (4 or 5 times as you suggest in for loop), even if they input the correct one.

Besides ryushare, all sites run just fine. In ryushare it caught (just for example) :

Language: HTML
<a href="http://ryushare.com/1fec555563b7/blablbababaFilename.rar">blablbababaFilename.rar - 3.7 MB</a>

and considered it as download link, actually it's not. All sites (minus movzap) run fine because instead output blablbababaFilename.rar they output blablbababaFilename.rar.html inside "a href", notice ".html" at tail.



Edited 3 time(s). Last edit at 06/03/2012 01:55PM by tong2shot.

tong2shot Wrote:
-------------------------------------------------------
> The problem with
> current loop state is : if site decides to change
> code, thus the plugin won't work, users will be
> shown captcha repeatedly (4 or 5 times as you
> suggest in for loop), even if they input the
> correct one.

Yeah, it is indeed a bit problematic. But this same thing happens with other plugins we currently have. There's not much we can do, though we can try to make everything generic so that it will break less often.


> Besides ryushare, all sites run just fine. In
> ryushare it caught (just for example) :
>
> blablbababaFilename.rar - 3.7 MB
>
> and considered it as download link, actually it's
> not. All sites (minus movzap) run fine because
> instead output blablbababaFilename.rar they output
> blablbababaFilename.rar.html inside "a href",
> notice ".html" at tail.

I updated the XFileSharing plugin and RyuShare should work again. I'm a bit afraid the download link regexp might not work for for files with strange names that must be URLEncoded, but that can be fine tuned. I also added a loop counter.

edit: Sorry, I saw your changes only now. Seems that we both implemented the loop counter at the same time.



Edited 1 time(s). Last edit at 06/03/2012 03:31PM by ntoskrnl.

Ok, I've added loop counter. It's not possible to skip waiting time between captcha retry as it depends on number of pages. The very same reason for password entry. But that's okay, that's the same behaviour as if we download the file via browser.

The ryushare error still remain, I suggest to add getDownloadLinkPageRegex method back.



Edited 1 time(s). Last edit at 06/03/2012 03:31PM by tong2shot.

We post at the same time I'll see the code.

Please look at NovaFile, the server output : "This direct link will be active for your IP" instead.