[I am forking from the thread announcing Puppet Server 0.2.0, for which
this was OT.]
Sorry for the delayed response on this - hard to keep up with email at
times :)
On Fri, Oct 10, 2014 at 4:55 PM, Felix Frank <
Felix.Frank@alumni.tu-berlin.de> wrote:
> On 10/03/2014 03:50 PM, jcbollinger wrote:
>
>
> I feel compelled to point out that if the "faster language"
happens to be
> C++, then you will *need* a plug-in interface in some different language
> (presumably Ruby, but straight C would be more typical). C++ APIs are
> sensitive to compiler and compile options used, and they provide
> essentially no compile-time encapsulation of API classes' private
members,
> so it would not be wise to suppose that you will ever be able to directly
> support unwrapped, third-party, C++ plugins. Especially with the current
> fast pace of Puppet development.
>
> Absolutely correct. C++11 is an *implementation* choice, but not an
*interface* choice, for the reasons you've given.
For cfacter (at least initially) the tldr on plugin support is two-fold:
* for custom facts, we dynamically load the ruby library (if not already
loaded) and implement the facter API used by custom facts
* implement external facts
The non-tldr version is at
https://github.com/puppetlabs/cfacter/blob/master/Extensibility.md and also
discusses some future ideas for getting external facts on a par with custom
facts (e.g. providing built-in facts as a json blob on stdin).
We definitely could implement a C interface for adding facts as well. There
were one or two questions about that at PuppetConf. I'd be curious to know
how much demand there is for that approach.
Thinking about the extension points for the agent, notably providers, we
may be able to follow a similar-ish model there of:
* dynamically load ruby and implement the provider api (tricky b/c the api
needs improved definition/hardening)
* introduce a concept of external providers
* maybe add a C API here as well?
Feedback or ideas in this space would be great!
>
> I somehow just realized yesterday that CFacter is a thing already. So I
> guess we're already somewhere down this road.
>
> Just cloned the repo - doesn't seem to build on Debian sid with Ruby
> 2.1.0. Will likely take some fiddling.
>
Of the debians, I haven't tried sid, though we are building it on wheezy
(packages coming in the next week or two, so stay tuned).
FYI the build doesn't depend on ruby-devel packages (the MRI embedding
relies on the relevant bits of the Ruby C API being stable, which it
generally has been).
If you have build issues on sid (or anywhere for that matter), just ping on
irc/email/etc; I'm sure people can sort it out. And these are early days
for this tech stack, so it would be nice to surface oddities or friction
points early.
Best,
Kylo
--
Kylo Ginsberg | kylo@puppetlabs.com | irc: kylo | twitter: @kylog
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CALsUZFGi6-6YT2UO9ETGX_70-L8YfA%3D%2Bad4mFEaS140N58mfJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.