celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: [jira] [Commented] (CELIX-215) curl_global_init() not called directly
Date Wed, 11 Feb 2015 08:55:57 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message