[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 < [email protected]> 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 | [email protected] | 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 [email protected]. 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.
