haiku/headers/private/storage/AddOnMonitorHandler.h

133 lines
3.9 KiB
C
Raw Normal View History

/*
* Copyright 2004-2013, Haiku, Inc. All rights reserved.
* Distributed under the terms of the MIT License.
*/
#ifndef _ADD_ON_MONITOR_HANDLER_H
#define _ADD_ON_MONITOR_HANDLER_H
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
#include <list>
#include "NodeMonitorHandler.h"
namespace BPrivate {
namespace Storage {
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
struct add_on_entry_info {
char name[B_FILE_NAME_LENGTH];
node_ref nref;
node_ref dir_nref;
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
node_ref addon_nref;
};
class AddOnMonitorHandler : public NodeMonitorHandler {
public:
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
AddOnMonitorHandler(const char* name = NULL);
virtual ~AddOnMonitorHandler();
virtual void MessageReceived(BMessage* message);
// Supply the add-on directories here, in the order you want them checked.
// Add-ons in directories added earlier will shadow add-ons in directories
// added later, if they share the same file name. If an add-on is removed
// from or renamed in a directory and it has previously shadowed another
// add-on, the previously shadowed add-on shall become enabled
// (AddOnEnabled()). If an add-on appears in a directory, or is renamed,
// it can cause another add-on to become disabled, if it has the same name.
// Note that directories are not watched recursively, and all entries
// are reported as add-ons regardless of their node type (files,
// directories, symlinks).
// If sync is true all pending add-on entries are handled immediately.
// Including entries from other directories.
virtual status_t AddDirectory(const node_ref* nref,
bool sync = false);
status_t AddAddOnDirectories(const char* leafPath = "");
protected:
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
// hooks for sub-class
virtual void AddOnCreated(
const add_on_entry_info* entryInfo);
virtual void AddOnEnabled(
const add_on_entry_info* entryInfo);
virtual void AddOnDisabled(
const add_on_entry_info* entryInfo);
// name field will be invalid!
virtual void AddOnRemoved(
const add_on_entry_info* entryInfo);
// name field will be invalid!
protected:
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
virtual void EntryCreated(const char* name, ino_t directory,
dev_t device, ino_t node);
virtual void EntryRemoved(const char *name, ino_t directory,
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
dev_t device, ino_t node);
virtual void EntryMoved(const char *name,
const char *fromName, ino_t fromDirectory,
ino_t toDirectory, dev_t device,
ino_t node, dev_t nodeDevice);
virtual void StatChanged(ino_t node, dev_t device,
int32 statFields);
private:
void _HandlePendingEntries();
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
void _EntryCreated(add_on_entry_info& info);
typedef NodeMonitorHandler inherited;
typedef std::list<add_on_entry_info> EntryList;
struct add_on_directory_info {
node_ref nref;
EntryList entries;
};
typedef std::list<add_on_directory_info> DirectoryList;
bool _FindEntry(const node_ref& entry,
const EntryList& list,
EntryList::iterator& it) const;
bool _FindEntry(const char* name,
const EntryList& list,
EntryList::iterator& it) const;
bool _HasEntry(const node_ref& entry,
EntryList& list) const;
bool _HasEntry(const char* name,
EntryList& list) const;
bool _FindDirectory(ino_t directory, dev_t device,
DirectoryList::iterator& it) const;
bool _FindDirectory(
const node_ref& directoryNodeRef,
DirectoryList::iterator& it) const;
bool _FindDirectory(ino_t directory, dev_t device,
DirectoryList::iterator& it,
const DirectoryList::const_iterator& end)
const;
bool _FindDirectory(
const node_ref& directoryNodeRef,
DirectoryList::iterator& it,
const DirectoryList::const_iterator& end)
const;
void _AddNewEntry(EntryList& list,
add_on_entry_info& info);
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
private:
DirectoryList fDirectories;
EntryList fPendingEntries;
};
}; // namespace Storage
}; // namespace BPrivate
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
using namespace BPrivate::Storage;
* Refactored a lot of repetitive code and made everything more readible. * Once I understood better how everthing is supposed to work, I've fixed some bugs. * The most important problem was that AddDirectory() placed the wrong entry (resolved symlinks) into the entry list it keeps for each directory. This resulted in the mechanisms not working at all when an add-on was a symlink. * There was a hidden TODO, which would mean that moving an add-on from one watched directory into another, like from home/config/add-ons/... into common/add-ons/... would drop the client application (media_server, input_server, ...) into the debugger. * The fFormerEntries list did not seem to serve any purpose. Basically it would not disable add-ons removed from a watched directory unless it changed it's name at the same time. I've removed it completely, since it didn't seem to be an optimization (entry cache) either. * Each actual add-on file is now node-monitored for stat changes. So if you have a link in the add-on folder, and the linked to add-on changes, it triggers a reload of the add-on now. This will make it much more pleasant to develop add-ons and have them affective immediately. I tested with a fresh image, but there are no immediate regressions I am aware of. I could imagine that messing with certain add-ons can have a bad effect now, like removing the keyboard input_server add-on may trigger the keyboard to stop working immediately without an input_server restart, but Tracker should warn before it happens. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2010-08-19 23:52:19 +04:00
#endif // _ADD_ON_MONITOR_HANDLER_H