[haiku-development] Re: Tracker Add-on Host
- From: Hrishi Hiraskar <hrishihiraskar@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 25 Mar 2019 12:26:00 +0530
What would it do exactly? It sounds like not much more than a
BApplication, in fact. I would just have complex enough add-ons spawn their
own app if that's appropriate.
TrackGit uses BApplication method. The call to add-on spawns the
Application, if it's already not running. Then the Application takes care
of tasks to be performed. If there is some error, the Application will be
crashed, this is helpful in debugging. Plus, this is helpful in managing
multiple simultaneous calls to add-on.
If I'm not wrong, if there was a server, spawning and managing of add-on
will be taken care of and add-on developer will have to write less code,
but there's not much to write in order to handle this and add-on can take
care of this.
This server could also expose the add-ons through a command-line
interface, turning all add-ons into command-line tools even if they
were not originally coded for that (I know some are also applications
as well as add-ons.)
I feel that, since these add-ons are for Tracker, they should be used from
Tracker itself, as they provide additional functionality to Tracker. Maybe,
I'm not aware of a use case where add-on can have a command line tool.
Regards
Hrishikesh
On Mon, Mar 25, 2019 at 11:59 AM Adrien Destugues <pulkomandy@xxxxxxxxx>
wrote:
Le 25 mars 2019 02:26:35 GMT+01:00, Ryan Leavengood <leavengood@xxxxxxxxx>
a écrit :
Badly coded Tracker add-ons can crash Tracker. Tracker can be blamed
for add-ons crashing, such as in this forum post:
https://discuss.haiku-os.org/t/tracker-crashing-in-hrev52989/8364
I suggest a new server, tracker_addon_host (or maybe
tracker_addon_server) which hosts these add-ons, the same way the
media_addon_server does for media_server.
This server could also expose the add-ons through a command-line
interface, turning all add-ons into command-line tools even if they
were not originally coded for that (I know some are also applications
as well as add-ons.)
The benefits are obviously Tracker can't crash from add-on bugs, and
maybe there is a way for Tracker to inspect the stack trace when the
tracker_addon_host crashes and blacklist the offending add-on.
The drawbacks are of course another server running and more memory
usage, though I doubt it would be too bad. Maybe running the add-ons
over IPC will be slightly slower, but I think the Tracker add-on
protocol is fairly simple, and BMessage passing between apps is well
optimized.
I mention it here to get other opinions on the idea.
This would probably be a fairly fun project. Obviously I am interested
in it, though would not get around to it for a while.
What would it do exactly? It sounds like not much more than a
BApplication, in fact. I would just have complex enough add-ons spawn their
own app if that's appropriate.
And let's just fix that crash, no matter where it comes from. Given the
plans for TrackGit (icon overlays comes to mind) there will be a need for
deeper customization of Tracker, which makes sandboxing difficult at least
for some parts of the code.
I would just write some guidelines for people writing Tracker add-ons to
keep the add-on part to a minimum and spawn another app as needed. In a lot
of cases the app would be started only when the user interacts with the
add-on, so no need for a permanently running server.
Also, if an addon crashes your addon host, you still get a crash dialog,
and users will still blame the os. So I'm not sure it even solves the
initial problem. With launch daemon, Tracker is restarted on a crash
anyway, so it's not that bad?
Other related posts:
