Separate inventory for more clients to use

[jerinphilip]

https://github.com/browsermt/bergamot-translator/issues/320 appears to request an inventory. The natural way to do this, in my thinking, would be to isolate the inventory here without linking to GUI/Display and use the same lib for inventory to spawn a command-line application that does not require a display. The efforts should help refactor a bit of the code here, marking clear separation for a package manager versus the GUI.

While we expect Linux users who https://github.com/XapaJIaMnu/translateLocally#using-in-an-environment-without-a-running-display-server affects to have decent competence, I hope we're in agreement this situation is not ideal. The CLI separation from display should help remove this ugliness.

Such a library would also allow linking from iBus or Microsoft Word extension like applications, write a separate unit that daemonizes and provides a service (again need to run display-less). Native Messaging applications I have used in the past (e.g. VideoDownloadHelper) requires me to download a "companion app" - this companion app could very well be translateLocally (bloated to begin with, trimmed down eventually).

I am not sure how feasible the above is given I don't fully understand the nuances of translateLocally development and source. Please let me know your thoughts in this thread. Happy to extend my support and contribute to efforts towards solving this issue.

[XapaJIaMnu]

So basically you are proposing something like librepo that does the inventory management. Would using QT still be OK? The current invetory code is done here: https://github.com/XapaJIaMnu/translateLocally/blob/master/src/ModelManager.cpp which requires no GUI, although I have integrated it with the settings module so that I can also add external repositories to it. (See pr #86 ). By making the inventory use QT datastructures gives us serialisation for free and tables for displaying qt forms for very little code compared to using a pure c++ (or boost.serialisation). And this is ignoring all the network code that QT gives us for free.

translateLocally can be invoked without a display server in CLI mode, if I provide 2 separate executables (a compile time argument of the disables the GUI so you get the pure CLI mode.). I was trying to find an easy way to do that without two separate executables but I am not sure it's possible with QT.

I personally don't want to have a separate service/daemon + translateLocally as a frontend, because that makes windows and mac integration more difficult. And I don't see what daemonising it would bring. But I could be wrong. Willing to be convinced.

Would a solution where translateLocally can run cleanly in CLI mode as a daemon with native messaging work for you? Then you can attach any sort of 3rd party service (word plugin or ibus?)

EDIT: I see that @jelmervdl has pointed out similar things in browsermt/bergamot-translator#320

[jelmervdl]

Would a solution where translateLocally can run cleanly in CLI mode as a daemon with native messaging work for you? Then you can attach any sort of 3rd party service (word plugin or ibus?)

I would prefer this option. It has to be possible to cleanly disable the GUI entirely in Qt. It might involve a custom main() function that instantiates QApplication or QCoreApplication depending on the parameters passed in (and we couldn't use Qt's argument parser to do that because that needs an instance of either of those to be present already…

[jerinphilip]

Yes. I am proposing something like librepo. Qt is not just ok, but based on cross-platform troubles I understand from exchanges appears to be the most viable option.

What I'm trying to convey is that I fancy an SDK (C++ lib providing client and server framework, consumers extend client) over an API (JSON native messaging). I must admit I have an agenda here on piggybacking on this "SDK" for iBus but am flexible if this suggestion is difficult. There is an overall idea/suggestion of translateLocally pivoting into an SDK/ecosystem for local translation going from the current GUI app tight coupling - but I'm not sure if such a shift aligns with translateLocally vision (cc @kpu).

If I have iBus, Microsoft Word, translateLocally GUI, pdf reader right click translate extension etc - it is easier to have them connect to the same local server reducing the overall load on the system. I speak from a Linux user perspective, so I guess we'll need to find a spot where we can harmonize with windows and mac troubles brought about in this thread.

[XapaJIaMnu]

@jerinphilip why would iBus, Microsoft Word, be unable to connect at the same to translateLocally, which acts both as a server and a GUI? What I am saying is that translateLocally GUI will acquire server functionality via native messaging and apps would be able to connect to it. No need to split client and server.

[jelmervdl]

Can we close this for now as translateLocally has both a cli interface (if you feel like parsing text) and a native messaging interface (which is more stable as it is proper json, but you'll have to do some byte and json parsing)

[XapaJIaMnu]

I think what @jerinphilip wanted here was a server that could have multiple clients, something based on sockets and such... Which could be extended from the native message iface code at a later point?