[darcs-users] A Plugin Architecture for Darcs

[Nimrod A. Abing]

On 10/31/06, Jason Dagit <dagit at codersbase.com> wrote:
> On 10/30/06, Nimrod A. Abing <nimrod.abing at gmail.com> wrote:
> > Hello everyone,
> >
> > I've been looking to extend darcs for quite some time now but because
> > I have a difficult time wrapping my head around Haskell, I am unable
> > to do so. I could go and learn Haskell, matter of fact I have been
> > doing so on and off for over a year now. But it's hard to think in
> > functional terms when you have been hard-wired for so long to think in
> > imperative terms.
>
> The rewiring is healthy for your brain :)

Not if it causes it to implode first :) But I'm getting there...

> Would prehooks be inadequate too?  Every major software team I've been
> a member of had complicated pre and post commit hooks (always using
> cvs or svn) and sometimes it's funny to me that darcs is as
> successfull as it is without good support for such things.  Although,
> darcs test is quite similar to what our pre-commit scripts did in the
> past.

The thing is, pre and post hooks only suffice when you want to
manipulate things outside of darcs. But when you want to manipulate
its innards, like the patches themselves, hooks can still be usable,
but lacking. Plus it's unsafe to trust the inner workings to external
scripts invoked by hooks. If there was a plugin system with some form
of access control, it would be easier and safer. If your plugin does
something that would corrupt the repository or the patches, the plugin
system would prevent you from doing that. Of course, it should be
possible to say "yes, I understand it may screw things up so go ahead
and do it anyway."

> My overall comment is that I would like to see a libdarcs which
> provides the core darcs functionality as a library with C bindings (so
> that most languages which support FFI can interface with it).  I think
> I suggested this a long time ago but sadly never did anything about
> it.  Right now (for me at leas) it's a bit hard to separate darcs the
> tool + UI from darcs core + tool + UI.  I believe this libfoo approach
> is the one taken by svn and has been quite successful for them with
> regard to new extentions and tool integration.

Yes, I believe taking out the core engine and putting it in a separate
library would be a step in the right direction. It would allow tool
writiers to be able to create other tools that layer on top of darcs.
But having a scriptable plugin interface would be good also.

Does Haskell support a portable way of loading dynamic modules?
Because another approach would be to specify an interface and then
allow for dynamic module loading. Or probably just use glib functions
for this?

http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html
-- 
_nimrod_a_abing_

[?] http://abing.gotdns.com