celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: [jira] [Commented] (CELIX-215) curl_global_init() not called directly
Date Wed, 11 Feb 2015 09:15:37 GMT
On Wed, Feb 11, 2015 at 9:55 AM, Alexander Broekhuis
<a.broekhuis@gmail.com> wrote:
> Hi Pepijn,
> 2015-02-11 9:40 GMT+01:00 Pepijn Noltes <pepijnnoltes@gmail.com>:
>> >
>> > I strongly disagree with this. The launcher is just a small source file.
>> It
>> > is easy enough to duplicate or add an option. I don't see how that makes
>> > anything complex.
>> >
>> > But even if we don't want an option/multiple launchers, I (against my
>> > better judgement wrt OSGi concepts..) prefer to add it to the current
>> > launcher, this at least leaves the framework clean. If someone creates a
>> > custom launcher, they don't have to rely on curl, on the other hand, if
>> > they want to use it, they have to add it (easy enough..).
>> To clarify I would prefer a curl bundle to disclose the curl
>> functionality as this is IMO the OSGi way.
>> You can hide implementation details (init/deinit) in the bundle
>> activator and disclose functionality based on an abstracted services.
>> But because curl_global_init has to be called before any threads are
>> started, this is not an option.
> Agreed. I'm still looking at alternatives for future use that are either
> "global stateless" or able to be used via one bundle.
>> Well then I prefer a manner where we leak as less as possible
>> implementation details. IMO this can be achieved by default doing
>> curl_global_init / deinit in the Celix Framework.
>> Adding options, we enforces people to think about curl init/deinit.
>> Although a small inconvenience, if this is avoidable I would prefer
>> that.
>> I agree that if we do this, it should be done in the launcher.
> Then I misunderstood you, for me the framework is the framework library.
> The launcher is a separate executable, which strictly speaking could be
> seen as not part of the framework.
> But then we agree :). So I'll add something to the current launcher. I'll
> start without an option, though eventually we might need to reconsider that.
> A possible (nicer) solution would be to let CMake figure it out. Ie, if
> curl is included in any of the build steps, set a flag that is used in some
> "define"s in the code enabling/disabling Curl init/destroy.


> --
> Met vriendelijke groet,
> Alexander Broekhuis

View raw message