[publican-list] Open Feedback Publishing System (OFPS)

[David Jorm]

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" <jfearn at redhat.com>
To: sparks at fedoraproject.org
Cc: "Publican discussions" <publican-list at 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 <jfearn at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican