something is wrong with the "facebook_integration" module

[Lubomir I. Ivanov]

On 9 November 2015 at 17:24, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> On Nov 9, 2015, at 6:25 AM, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>
>> also, unless i'm mistaken, if a plugin is static linked against the
>> same .a modules that the executable is linked (core, profile,
>> desktop-widges, etc) aren't we are going to distribute the same code
>> twice and the plugin size is going to be quite large?
>
>
> Probably, and maybe this is the reason why it's failing.
> Please, continue to compile without facebook integration, I'll try to fix
> that here by transforming the subsurface_core and subsurface_interface into
> dynamic libraries.
>
>
> I am really really not sure that I want that.
>

the "plugin concept" usually implies exposing an API to allow third
party developers to contribute a feature without interfering with the
main application.
said application in some cases can also be closed source.

in our case the application is open source, so what we can do is
simply define a good interface e.g. (ISocialNetworkIntegration as is)
and base all possible social network code on that.

then, if a developer comes by and says, "alright, i want to add
SocialNetworkX support in Subsurface..", then we can just tell him
"use ISocialNetworkIntegration, place all your work in folder X and
also take a look at how the Facebook code works".

from there it's a question of what is a dynamic library and what is
statically linked, but overall everything can still be statically
linked in the Subsurface binary. conceptually the source tree will
still be separated in modules.

but having what is compiled and distributed as modules also has
benefits, because using shared libraries *implies* good modular
separation.

e.g.:
subsurface
subsurface_core.so
subsurface_desktop.so
subsurface_socialnetwork_facebook.so
subsurface_socialnetwork_x.so
...

lubomir
--