+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: Directory Watchdog - Background file monitor service to initiate auto update library? (/showthread.php?tid=66348)
- AnalogKid - 2010-01-17 01:02
Seems to me that most of the solutions are working on a 'pull' solution. (No I don't mean POLL)....
The assumption is that XBMC, or some script within will either poll/scan for changes, or become observers of the file system and wait for a notification event from the host OS. Polling sucks, and the notification mechanisms vary from OS to OS.... but with both solutions it's XBMC 'pulling' the data somehow.
So, why not turn the thinking around and have an external solution that pushes the change notification in a uniform manner. That is to say, each OS may have it's own technique, and folks can develop whatever 'monitors' they like... OUTSIDE of XBMC. Their only goal should be to notify XBMC that a change has occurred. This then leaves the XBMC code clean and OS agnostic... whilst the
monitors can be as dumb or sophisticated as you like....
Just need an interface to tell XBMC 'Do a scan', or better still 'Do a scan in this path' etc
This then becomes more of a 'push' solution, and in my mind architecturally neater by a million miles (even though I do wish XBMC could do this itself)
- jmarshall - 2010-01-17 01:16
You'd still want filtering (before sending the info to XBMC?) of the paths that you'd monitor, though one presumes that an external app could potentially ask XBMC for that information if it wanted to.
In any case, some sort of independent utility/service seems the way to go, I agree.
Cheers,
Jonathan
- althekiller - 2010-01-17 01:22
It's a complete waste to blindly update. The EC is the best solution.
- AnalogKid - 2010-01-17 01:25
jmarshall Wrote:You'd still want filtering (before sending the info to XBMC?) of the paths that you'd monitor, though one presumes that an external app could potentially ask XBMC for that information if it wanted to.
In any case, some sort of independent utility/service seems the way to go, I agree.
Cheers,
Jonathan
I agree, but the complexity of that then pretty much lies in the hands of the external utility (nice if it read the sources.xml file but not mandatory). The utility can reside on the same machine, or on a remote server... we don't care, so long as we are prodded at the right time)
A use the term 'we'... of course it means 'you' :-)
- althekiller - 2010-01-17 01:35
Right...like I already said here... http://forum.xbmc.org/showpost.php?p=479312&postcount=21
- AndyE - 2010-01-17 01:44
AnalogKid Wrote:Seems to me that most of the solutions are working on a 'pull' solution. (No I don't mean POLL)....
The assumption is that XBMC, or some script within will either poll/scan for changes, or become observers of the file system and wait for a notification event from the host OS. Polling sucks, and the notification mechanisms vary from OS to OS.... but with both solutions it's XBMC 'pulling' the data somehow.
So, why not turn the thinking around and have an external solution that pushes the change notification in a uniform manner. That is to say, each OS may have it's own technique, and folks can develop whatever 'monitors' they like... OUTSIDE of XBMC. Their only goal should be to notify XBMC that a change has occurred. This then leaves the XBMC code clean and OS agnostic... whilst the
monitors can be as dumb or sophisticated as you like....
Just need an interface to tell XBMC 'Do a scan', or better still 'Do a scan in this path' etc
This then becomes more of a 'push' solution, and in my mind architecturally neater by a million miles (even though I do wish XBMC could do this itself)
Isn't it sort of pointless having architecturally clean code that doesn't actually provide anything?
This solution still means someone has to write the apps that send the inotify and Windows/OSX equivalent notifcations to XBMC. And who is going to write and maintain those?
EDIT:
Just to be clear, my point being if they are considered community apps, community apps with poor quality or performance may reflect badly on XBMC, with the XBMC devs not having any real control over it
- althekiller - 2010-01-17 01:46
AndyE Wrote:And who is going to write and maintain those?
What makes you think we want to?
- AndyE - 2010-01-17 01:55
althekiller Wrote:What makes you think we want to?
That's exactly my point
- jmarshall - 2010-01-17 03:07
If they don't work, we won't distribute them, simple as that.
If a user has to go elsewhere to find something then they already know it's not supported.
- AnalogKid - 2010-01-17 13:44
The point is, the XBMC team don't really want to do this, not unless there was a totally compelling reason and simple cross platform implementation...
So, as a concession, those that REALLY do want this feature would be free to implement a solution that wouldn't compromise XBMC i.e. Develop their own external monitor.
Should anybody develop a superb monitor that miraculously convinces the XBMC team of the error of their ways, then I am sure they would consider incorporating it into the XBMC core. Until then....
Since I'm not gonna be doing any coding for XBMC, I either put up with what I get, or implement workarounds externally... I don't see why that couldn't extend to folder watching (providing there's enough of a hook to notify XBMC of a change, or force a library update)
For me that's a fair solution