<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hmm, so this is easier even. Plugin must have standard interface,
available through stdin/stdout/pipes/sockets. Stdin/stdout/stderr
is more simple and it's easy to debug (as first version, at
least), also can be "mapped" to sockets easy (in inetd-style, for
example). "Driver" can looks like "cmd" module in Python (it's
better than to use command line arguments, due to length
limitation). Even more, it's easy convertable to other
protocols/formats which allows to switch to microservice
architecture without big effort ;) (I did it in D: communication
can be automatically mapped to JSON/XML/Show-Read/etc). It sounds
as interesting task.<br>
</p>
I like Powershell: it extends standard way of Unix scripting
languages communicating with strings (like Tcl, shell) to objects
instead. So binary protocol can be supported too (MessagePack, BSON,
Xdr, etc). It's totally language neutral plugin architecture ;)
"Pipelining" can be done in WSGI style - with middleware which can
help the "plugging" of protocols :)<br>
<br>
Dispatching can be achieved with special directory layout/some
config file (better).<br>
<br>
<div class="moz-cite-prefix">24.07.2018 10:30, Jeremy O'Donoghue
wrotes:<br>
</div>
<blockquote type="cite"
cite="mid:2B389A34-1B45-4E66-885D-01C9980F5BCA@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div><br>
</div>
<div><br>
On 24 Jul 2018, at 15:16, Paul <<a
href="mailto:aquagnu@gmail.com" moz-do-not-send="true">aquagnu@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<p>> that Pandoc supported dynamically loading of extra
plugins on demand.</p>
<p>It means .dll/.so. But also there are applications with
pre-built "plugins" - you can not load them dynamically, but
can turn-on/off dynamically (from a list of pre-installed
plugins). It's useful too.</p>
</div>
</blockquote>
<div>Pandoc plug-ins are separate executables rather than shared
libraries. Haskell data types are serialised by Pandoc then
de-serialised, modified and re-serialised in each plugin.</div>
<div><br>
</div>
<div>The Pandoc approach is more like a data pipeline with Pandoc
itself at both ends.</div>
<div><br>
</div>
<div>Jeremy </div>
<br>
<blockquote type="cite">
<div>
<div class="moz-cite-prefix">24.07.2018 09:07, Marc Busqué
wrotes:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LNX.2.21.1807240759280.1329@localhost">On
Mon, 23 Jul 2018, John Lato wrote: <br>
<br>
<blockquote type="cite">I think you're attempting to
optimize the wrong thing. In a dynamic language like Ruby,
this approach makes sense because download times are a <br>
significant fraction of the user's time, and otherwise the
user experience isn't affected much because the code is
basically interpreted either <br>
way. <br>
Haskell is primarily a compiled language. The total
download size probably won't be significantly larger from
downloading all modules. The cost <br>
of recompiling/dynamically loading plugins will be
expensive (relative to the rest of the user time), and
payed with every execution. Plus it's <br>
additional work for the developer to set up. <br>
</blockquote>
<br>
What you say makes a lot of sense in terms of optimization.
But, what <br>
about extensibility? Take for example the Pandoc package,
which would be <br>
similar in design of what I'm trying to do. Say I want to
add a <br>
converter to some mark-up format not supported by Pandoc,
and that <br>
Pandoc team doesn't agree to merge my work in its repo or
simply I don't <br>
have the time to wait until it happens. In this sense, it
would be nice <br>
that Pandoc supported dynamically loading of extra plugins
on demand. <br>
<br>
Marc Busqué <br>
<a class="moz-txt-link-freetext"
href="http://waiting-for-dev.github.io/about/"
moz-do-not-send="true">http://waiting-for-dev.github.io/about/</a><br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Haskell-Cafe mailing list</span><br>
<span>To (un)subscribe, modify options or view archives go to:</span><br>
<span><a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a></span><br>
<span>Only members subscribed via the mailman list are allowed
to post.</span></div>
</blockquote>
</blockquote>
<br>
</body>
</html>