search

hoehermann / purple-gowhatsapp

Pidgin/libpurple plugin for WhatsApp Web.
GNU General Public License v3.0
276 stars 34 forks source link

Too many go-modules? #184

Closed UnitedMarsupials closed 3 months ago

UnitedMarsupials commented 5 months ago

I just built the plugin on FreeBSD and am happy to report, that it seems to work. Thank you very much for the work.

However... The size of the libwhatsmeow.so comes up to 14879920 bytes -- the libtelegram-tdlib.so next to it (by the ars3niy/tdlib-purple) is only 318200 bytes, 46 times smaller.

The size is, probably, due to using the Go code -- and the Go-world's passion for self-containment. This is hardly a place to discuss, how misguided that passion is -- my question is about the modules required by the gowhatsapp. During the build I notice it downloading the following:

I can see, why some of these are necessary those having to do with QR-codes, for example, the whatsmeow, or even the crypto. But why is the libsignal -- a library for a different messaging protocol -- needed? Same question for the database-clients: sqlite3, Postgres, and MySQL...

Worse! Some of these are present in multiple versions, which just seems bizarre... Could you comment, please?

hoehermann commented 5 months ago

Thank you for the question. I want to answer it to my best of my abilities and knowledge.

dependencies

golang's "put all dependencies in one static binary" feels weird to me, too. Though I have to admit, it makes shipping windows builds easier. As far as I know, I could offer a bunch of dll's – users would need to manage and update the files separately. That would leave lots of room for errors, I am afraid.

I could probably – in theory – offer a way to select features and include them into custom builds as needed. I think this is out of scope for this project. It would only affect additional features like the media analysis or database connections, not the multitude of libraries within the core implementation.

At the end of the day, it looks like we live in modern times where memory (RAM) is no longer limited, read-speed from hard-drives is considered to be infinite and load-times are not a concern. 🤷

Glad to hear it works on FreeBSD. Did it work out of the box? Or did you have to do something in particular? I would like to mention additional steps in the readme.

UnitedMarsupials commented 5 months ago

Let me begin from the end :)

Glad to hear it works on FreeBSD. Did it work out of the box?

No. But I just committed the FreeBSD port, which will make it as easy as make install clean.

it looks like we live in modern times where memory (RAM) is no longer limited, read-speed from hard-drives is considered to be infinite and load-times are not a concern. 🤷

Because you don't seem fully satisfied with this state of affairs, I'll offer a general rant here criticizing it -- to reinforce your dissatisfaction :-) You, Hermann, personally, appear to have started working with computers in, at least, 2008 -- probably, earlier, but let's go with that... That's 15+ years. By Moore's Law -- admittedly a somewhat liberal interpretation of it -- 15 years means about 10 doublings of computer-capacity...

Now, can you say, your computing experience, however you choose to quantify it, is 1024 times better than back then? I cannot. Sure, there are major improvements -- my web-browser stopped crashing about 10 years ago, for example. Watching videos on computer "just works". Free office software is quite capable, and so on. But all of that together can only be said to improve things 10-fold. Maybe, 50-fold. Ok, let's be generous, and say, it became 100 times better.

But not 1000 times... So, what happened to the awesome improvements given to us by the hardware engineers -- the high RAM and processing-core densities, the awesome Internet speeds, the storage-capacities and bandwidth? The tiny phone in my pocket today has better computing capabilities, than the entire park of computers in Kyiv of 1987 put together.

The answer is, sysadmins and software developers took all of it to themselves -- and you admit to it:

golang's "put all dependencies in one static binary" feels weird to me, too. Though I have to admit, it makes shipping windows builds easier

Being the first "downstream" from the hardware, we "ate" most of these improvements -- leaving fairly little to the end users, who are further "downstream" from us.

I could offer a bunch of dll's – users would need to manage and update the files separately

I'd love to see, what this means in practice. Operating systems like BSDs or Linux distributions, where there are functional package-managers, may benefit from that -- even if on Windows you'll, probably, prefer to stick to your current methods.

My FreeBSD port removes the entire require list from the src/go/go.mod.in. This seems to cause go to recreate the list based solely on the imports found across the *.go files. The approach appears to eliminate the phenomenon of multiple versions per package -- except for qrterminal? -- and it is also getting the latest for each package:

I also made SQLITE3, MYSQL, and POSTGRESQL to be options -- a user can choose to use any non-empty subset of them, but by default only the SQLITE3 is enabled. The port will remove mentions of the unselected DB back-ends from the login.go.

The removal, however, didn't result in as much space-saving as I was hoping for. Which makes me think, the bulk of the size of the shared library is just the generic "Go stuff".

Which is quite annoying. For example, I'd like to create a command-line WhatsApp client, that would post birthday-reminders to a private group, that I'm a member of. If I use the same whatsmeow API for that program, it'd be another giant file with the same "Go stuff" duplicated in it...

hoehermann commented 3 months ago

I completely agree with your rant. In my opinion, WhatsApp is a proprietary XMPP client with some protocol extensions. Message encryption has been around since 2004. That was before the iPhone even was released. Sure, there have been some nice improvements, but I still think it is embarrassing that WhatsApp even exists. Unrelated to the system it is running on (phone/desktop), a client should not hog hundreds of megabytes of RAM. That is one reason why this plug-in exists.

I had a realization the other day: I had put a second go.mod file in the root of the repository. I did that to see if github's dependency scanner would pick up the dependencies. It does not. I expected the go compiler to ignore the file. Alas, it does not. I removed the superfluous file from the repository and building failed. I had to make some adjustments. Can you check if the current master still works with the BSD port?

hoehermann commented 3 months ago

Closing due to lack of response. I hope the plug-in continues to work on FreeBSD even after the aforementioned changes.

UnitedMarsupials commented 1 month ago

Can you check if the current master still works with the BSD port?

Sorry for the delayed response. I'm finishing up the upgrade to 1.15.0. My port removes all dependencies from the .mod-files -- the building framework fetches the latest versions of them by itself before invoking your build. So it is a moot point, really...

But I noticed, that some new additional modules are now required, including what seems like text-only ones: mattn/go-isatty, mattn/go-colorable. Are these meant for the TTY version (finch)?

Should I allow people to build a GUI-only version of the module (without those additional modules) -- the way I'm already allowing them to pick database back-ends (SQLite3 being the default)?

hoehermann commented 1 month ago

My port removes all dependencies from the .mod-files

I am not versed in FreeBSD ports. I do not know where to view the diffs. But good to know it works regardless of my shenanigans. :)

mattn/go-isatty, mattn/go-colorable. Are these meant for the TTY version (finch)?

Yes. There also GUI set-ups which do not handle images e.g. when protocol bridges are involved, see https://github.com/hoehermann/purple-gowhatsapp/issues/191.

If you do not want to have the "textual QR code" feature, you probably want to remove the the qrterminal module including this call. Feel free to implement that using go build constraints and create a pull request. Then I can add it to the default branch. :)