[Haskell-cafe] Design of an extensible system

[Paul]

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.

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 :)

Dispatching can be achieved with special directory layout/some config 
file (better).

24.07.2018 10:30, Jeremy O'Donoghue wrotes:
>
>
> On 24 Jul 2018, at 15:16, Paul <aquagnu at gmail.com 
> <mailto:aquagnu at gmail.com>> wrote:
>
>> > that Pandoc supported dynamically loading of extra plugins on demand.
>>
>> 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.
>>
> 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.
>
> The Pandoc approach is more like a data pipeline with Pandoc itself at 
> both ends.
>
> Jeremy
>
>> 24.07.2018 09:07, Marc Busqué wrotes:
>>> On Mon, 23 Jul 2018, John Lato wrote:
>>>
>>>> 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
>>>> significant fraction of the user's time, and otherwise the user 
>>>> experience isn't affected much because the code is basically 
>>>> interpreted either
>>>> way.
>>>> Haskell is primarily a compiled language. The total download size 
>>>> probably won't be significantly larger from downloading all 
>>>> modules. The cost
>>>> of recompiling/dynamically loading plugins will be expensive 
>>>> (relative to the rest of the user time), and payed with every 
>>>> execution. Plus it's
>>>> additional work for the developer to set up.
>>>
>>> What you say makes a lot of sense in terms of optimization. But, what
>>> about extensibility? Take for example the Pandoc package, which 
>>> would be
>>> similar in design of what I'm trying to do. Say I want to add a
>>> converter to some mark-up format not supported by Pandoc, and that
>>> Pandoc team doesn't agree to merge my work in its repo or simply I 
>>> don't
>>> have the time to wait until it happens. In this sense, it would be nice
>>> that Pandoc supported dynamically loading of extra plugins on demand.
>>>
>>> Marc Busqué
>>> http://waiting-for-dev.github.io/about/
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180724/1d4a99f2/attachment.html>