search

erengy / taiga

A lightweight anime tracker for Windows
https://taiga.moe
GNU General Public License v3.0
2.1k stars 224 forks source link

Add-ons for extended functionality #129

Open zet4 opened 9 years ago

zet4 commented 9 years ago

Just how complicated would it be to add third party addition support? For example say I have a script in python that can grab episode files from an online service, how hard would it be for Taiga to add API for it's functions?

such-doge commented 9 years ago

What does your script do that necessitates controlling Taiga? Taiga already monitors folders for new episodes as they appear.

zet4 commented 9 years ago

Rather then control I'd say give new stream for taiga to use So basically taiga would control the extension , not the other way. But I guess I can talk with community I am in about just using the script manually to download, but its basically python script that searches and extracts anime episodes from a fairly popular in my community service. The difference here is that the service also has older series torrents of which may long be dead and thus lost for taiga user base. I understand that adding some kind of extension system would be time consuming but surely fun :D

On Jul 8, 2015, doge notifications@github.com wrote:

What does your script do that necessitates controlling Taiga? Taiga already monitors folders for new episodes as they appear.

Reply to this email directly or view it on GitHub: https://github.com/erengy/taiga/issues/129#issuecomment-119709446

-- Sent with K-@ Mail - the evolution of emailing.

rr- commented 9 years ago
  1. How should integrating your script with Taiga work?
  2. Why not create a (torrenting) service rather than a script so that people can configure Taiga to use your service just like they already do with other services?
  3. Either way, people are going to do things manually, be it downloading Python, or configuring Taiga. What's the real benefit of such integration?
such-doge commented 9 years ago

It sounds like Issue #95 may be of interest here, if it turns out to be an option to control arbitrary programs.

erengy commented 9 years ago

I agree that Taiga should be able to communicate with arbitrary external applications, one way or the other.

The idea I have is to rewrite the current API. I'm planning to look into standard protocols such as JSON-RPC, so that it remains compatible after Taiga becomes a multi-platform application (the current one depends on Windows messages).

However, there's another thing to take care of first, which is to implement a new event and notification system I previously mentioned in #94:

I do have some plans to make Taiga trigger various events, and have other parts of the application register for and respond to those events (e.g. announcements, notifications, API).

This can be one of the main features of v1.3 or v1.4, depending on how things go. The plan is to take care of #95 along the way, which may satisfy the need in this issue as well.

zet4 commented 9 years ago

I will just leave http://zeromq.org/ this here, it seems like a cross-platform, cross-language solution to cross-communication issue, ZMQ is implemented in most of the common languages, python included, say you would open a socket for public third party use and just listen to incoming messages on it, there you would have it solved :) Also probably could just send the messages in some JSON standard.

rr- commented 9 years ago

JSON-RPC? ZeroMQ? Seriously? What's wrong with starting user scripts/processes/hooks? Or even LUA...

Diablofan commented 9 years ago

json-rpc seems okay except that we'd be adding a freaking http server to this. I don't agree with this option at all.

ZeroMQ looks interesting, but it seems like a limited dbus really.

Honestly, I'm going to agree with @rr-, what is wrong with calling user scripts/processes/hooks? I don't agree with the Lua bit though since it seems a bit large to add in, and I'd personally like to see Taiga kept small.

Hell if the goal is to go multi-platform, you may just want to hold off on this and just implement dbus when we get to working on 2.0. That would allow anyone in any language to implement what they want and act on it when you send a message through it. You'll probably be needing it anyway on Linux.

vendethiel commented 9 years ago

Scheme scripting is the future :P

erengy commented 9 years ago

I don't know much about these stuff, which is why I said "I'm planning to look into them". It's just that I'd rather not continue building an API on top of Windows messages, and communicating over sockets sounds like a good idea to my semi-educated mind. Suggestions are welcome.

I think I kinda wandered off to IPC, while the subject here is more about extending the functionality of Taiga. Do you think embedding an interpreted scripting language would be a good idea? One additional advantage I can think of is that we could then replace the current format strings with actual scripts.

rr- commented 9 years ago

IMO embedding interpreted scripting language is pretty cool. That's why I suggested LUA, since AFAIK it has fewest dependencies (compared to Python, Perl and Ruby) and its code is surprisingly short (number of files is comparable to zeromq). LUA is also what mpv chose.

zet4 commented 9 years ago

Well since the whole extension part isn't coming anytime soon, I would like to propose a different suggestion (not sure if I should make it a seperate ticket or keep it to this one, hate to spam). Can we add support for direct download? Because you see I could quite easily turn my script into a small web service that would provide restful or whatever format necessary for the data. But Taiga seems to ONLY work with torrents, so if not an addon system then maybe a simple downloader?

erengy commented 9 years ago

Can we add support for direct download?

I could make it so that when Taiga encounters a direct-download link, it executes an external application other than the BitTorrent client. But if you meant embedding a download manager into Taiga, my answer would be no. This should not be Taiga's responsibility. It makes much more sense to let another program handle the task; adding this feature to Taiga would bring nothing but complexity. Another prime example of this is to have a built-in media player, which was also suggested a couple of times.

Ideally, I'd like to strip Taiga down to its core functionalities, and make everything else a module of sorts (addon, component, extension, plugin, or whatever you want to call it). Even then, some features are better left to other programs. Thus, improving the ability to communicate with external applications should be the goal for Taiga here.

PS: There is no such thing as a "simple downloader" when multiple files with large size are concerned.

zet4 commented 9 years ago

Agreed, there is FOSS downloader "uGet" (http://ugetdm.com/) you could do same as with torrent, give it a file selection dialog and a format string with all the necessities. Also detect that it's direct-download how? Content-type != torrent or?

On Sun, Jul 12, 2015 at 2:48 AM, Eren Okka notifications@github.com wrote:

Can we add support for direct download?

I could make it so that when Taiga encounters a direct-download link, it executes an external application other than the BitTorrent client. But if you meant embedding a download manager into Taiga, my answer would be no. This should not be Taiga's responsibility. It makes much more sense to let another program handle the task; adding this feature to Taiga would bring nothing but complexity. Another prime example of this is to have a built-in media player, which was also suggested a couple of times.

Ideally, I'd like to strip Taiga down to its core functionalities, and make everything else a module of sorts (addon, component, extension, plugin, or whatever you want to call it). Even then, some features are better left to other programs. Thus, improving the ability to communicate with external applications should be the goal for Taiga here.

PS: There is no such thing as a "simple downloader" when multiple files with large size are concerned.

— Reply to this email directly or view it on GitHub https://github.com/erengy/taiga/issues/129#issuecomment-120673012.

NoPlagiarism commented 9 months ago

Including the idea of rewriting Taiga to QT and maybe becoming cross-platform, this issue seems more reliable