VDSM has hooks which are subscribed to by putting a script in a directory. For example, if you want something to run when the before_vm_start hook is triggered, you put something executable in /usr/libexec/vdsm/before_vm_start/. Everything in the directory gets run, in alphabetical order. This makes for a simple hooks mechanism at the command line, without developing library/APIesque capabilities.
----- Original Message ----- From: "Jeff Fearn" <jfe...@redhat.com> To: spa...@fedoraproject.org Cc: "Publican discussions" <publican-list@redhat.com> Sent: Monday, October 25, 2010 12:38:41 PM GMT +10:00 Brisbane Subject: Re: [publican-list] Open Feedback Publishing System (OFPS) On Fri, 2010-10-22 at 07:28 -0400, Eric "Sparks" Christensen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/21/2010 02:03 AM, Jeffrey Fearn wrote: > > Eric "Sparks" Christensen wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Jared pointed out a neat "feature" O'Reilly is trying out called Open > >> Feedback Publishing System (OFPS)[1]. This allows readers to leave > >> comments on a particular paragraph of a document. > >> > >> Contrary to its name, OFPS is NOT open source. There are other projects > >> that are open source that do the same thing. The one I saw listed was > >> called Wooki[2]. > >> > >> I'm wondering if something similar could be implemented within Publican > >> to be used, at a minimum, in our draft documentation. It might make it > >> easier for people to let us know of problems without filing a bug. > >> Because it would take less time to leave feedback we might find that we > >> receive more than we currently do through BZ. > >> > >> [1] http://labs.oreilly.com/ofps.html > >> [2] http://wookicentral.com > > > > One of the founding constraints to Publican design is that there is no > > server side scripting. I don't see how you could do this without doing > > server side scripting and processing of some kind. It would require a > > major change in direction for Publican to become a web service instead > > of a static content provider. > > > > Cheers, Jeff. > > > > Jeff, > > Yeah if Publican could maybe not implement the solution but provide the > hooks for such a solution I think this could work without having > Publican become a larger monster. Having the hooks available would mean > we wouldn't be locked into a particular solution, which is good. I guess we'd need someone to define what a hook is and list what hooks they'd need. It's a command line app, I'd expect people to just use the command line, not try and use it like a library; like we do with FOP. Cheers, Jeff. -- Jeff Fearn <jfe...@redhat.com> Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing _______________________________________________ publican-list mailing list publican-list@redhat.com https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican _______________________________________________ publican-list mailing list publican-list@redhat.com https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican
