[gpodder-devel] Woodchuck patches: Interface to register...
- From: neal at walfield.org (Neal H. Walfield)
- Date: Mon, 01 Aug 2011 17:24:30 +0200
At Mon, 1 Aug 2011 11:39:24 +0200,
Thomas Perl wrote:
> * 2f2c52d13a0a77aec873b5be2717dda6fab2a064 (Interface to register...)
>
> If you enable the HookManager unconditionally, we should probably
> remove the "if gpodder.user_hooks is not None" conditions throughout
> the code. In this case, we have to make sure that all frontends use
> the "Core" class, but that's probably a good idea anyway (especially
> since the core class does not depend on many things, and just provides
> the DB and configuration)
This is reasonable.
> Some other thing: Why do you need the register_hooks() method?
> Wouldn't a hook script in the hooks folder provide the registration
> automatically with the current setup?
Your observation that any file in the $GPODDERHOME/Hooks directory
will be loaded automatically is correct. My motivation for enabling
this by default and adding a registration method is two fold:
including Woodchuck in the gPodder distribution; and, providing a
feedback channel so that the frontend can refresh the display when,
e.g., Woodchuck modifies the database.
First, I envision that the woodchuck module will be included in the
default gPodder installation. The current version of the patch
detects if a Woodchuck server is running and if not disables the
Woodchuck functionality, i.e., the Woodchuck module imposes a soft
dependency.
Second, Woodchuck interacts with model.py. For instance, it triggers
channel updates and downloads episodes. Currently, the only way that
model.py can notify the frontend of changes is the set of hooks. I'm
planning on modifying the frontend so that when Woodchuck updates a
channel, the frontend can refresh the channel. Currently, the user
has to change channels to see any updates.
Thoughts?
Thanks,
Neal
Other related posts:
- » [gpodder-devel] Woodchuck patches: Interface to register... - Neal H. Walfield
