Hi Pepijn, 2015-02-11 9:40 GMT+01:00 Pepijn Noltes <[email protected]>:
> > > > > 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
