Missing plugin interface about frostwire-jlibtorrent

[gubatron]

cc: @aldenml

[aldenml]

I removed the support for now and to explain:

The plugins torrent_plugin and peer_plugin are added by default and the only reason having the plugin interface exposed is if you want to create a plugin from java to plug in libtorrent. But that is impossible in the current form, because there is no such thing like inheriting a class in java and then passing it to the native world.

In the future and if necessary, we could create the mechanisms to create plugins from java.

No plans for now.

[gubatron]

@aldenml does the issue of not being able to use it in the current form happen because of how that method interface takes a function as a parameter?

I see that every other method which receives a boost::function as a parameter is also gone.

$ grep "(boost::function" *.cpp
alert_manager.cpp:  void alert_manager::set_dispatch_function(boost::function<void(std::auto_ptr<alert>)> const& fun)
alert_manager.cpp:  void dispatch_alert(boost::function<void(alert const&)> dispatcher
connection_queue.cpp:   void connection_queue::enqueue(boost::function<void(int)> const& on_connect
session.cpp:    void session::add_extension(boost::function<boost::shared_ptr<torrent_plugin>(torrent*, void*)> ext)
session.cpp:    void session::set_alert_dispatch(boost::function<void(std::auto_ptr<alert>)> const& fun)
session_impl.cpp:   void session_impl::set_alert_dispatch(boost::function<void(std::auto_ptr<alert>)> const& fun)
torrent.cpp:    void torrent::add_extension(boost::function<boost::shared_ptr<torrent_plugin>(torrent*, void*)> const& ext

all of those you won't find on the swig interfaces.

[aldenml]

No, passing a boost::function parameters is another issue. This one is related to the impossibility of inherit from plugin in (swig)-java and pass the object to the native side.

[gubatron]

@bedeho was thinking of how to help you during lunch.

For now I believe it's really hard to do this on the frostwire-jlibtorrent side as there are limitations on how to deal with boost::function on the Java side.

I think your path of action should be the following: since you're doing something so level which is basically create an extension to libtorrent (and not just use it as a client, which is mainly the purpose of frostwire-jlibtorrent), you ought to do the extension in C++, and then continue the rest of the work in java using the library.

Take a look at libtorrent.i, around line 730, and once you have your extension ready, you should do something along these lines:

    void add_lt_trackers_extension() {
        $self->add_extension(&libtorrent::create_lt_trackers_plugin);
    }

    void add_smart_ban_extension() {
         $self->add_extension(&libtorrent::create_smart_ban_plugin);
    }

   void add_bedeho_extension() {
        $self->add_extension(&bedeho::create_my_extension_plugin);
   }

and then use the java add_bedeho_extension() function to activate it when you're starting the jlibtorrent session.

I took a brief look at what's implied with opening up the add_extension function to Session, and it becomes a huge mess on the java side because of all the stuff that comes from boost, which doesn't map very well from C++ to Java due to genericity.

please correct me if I'm wrong @aldenml

[bedeho]

Thank you gubatron, yes, I also concluded that I have to make the extension itself in C++.

Before reading this, I had resigned to doing the libtorrent client in C++ as well, and then try to make some light weight bindings for bitcoinj instead, but I will give this approach a try as well.
The challenge would be to communicate with the extension itself from the Java jlibtorrent client. It is easy for the extension to send messages to the client, by simply extending the alert class as the document suggests, but the other way, that is how the client can control the extension, is then more difficult. Perhaps your swig code can create some bindings for this as well.

I think your main conclusion is right either way, jlibtorrent is best for building a traditional client, not extensions - which is actually quite reasonable, given that libtorrent has most
BEPs one could want directly implemented.

[gubatron]

you are spot on, you can extend the alert classes (I think @aldenml did some remarkably creative work there with reflection on the java side and preprocessor on the C++/Swig side you should take a look at if you go with that route, see CAST_ALERT_METHOD), or just add new swig entry points and extend the api for your fork.

I'd try to stay away from coding the whole thing in C++, as you can imagine I'm a bit biased towards working mostly on the java side ;)

[bedeho]

Thanks, I prefer Java as well!