From dev-return-1323-archive-asf-public=cust-asf.ponee.io@celix.apache.org Tue Jan 8 19:13:24 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id DFA97180652 for ; Tue, 8 Jan 2019 19:13:23 +0100 (CET) Received: (qmail 2690 invoked by uid 500); 8 Jan 2019 18:13:23 -0000 Mailing-List: contact dev-help@celix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@celix.apache.org Delivered-To: mailing list dev@celix.apache.org Received: (qmail 2670 invoked by uid 99); 8 Jan 2019 18:13:22 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jan 2019 18:13:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id E2AB2C0587 for ; Tue, 8 Jan 2019 18:13:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.906 X-Spam-Level: * X-Spam-Status: No, score=1.906 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.143, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id Q_k6sgT1TTeu for ; Tue, 8 Jan 2019 18:13:19 +0000 (UTC) Received: from mail-yw1-f68.google.com (mail-yw1-f68.google.com [209.85.161.68]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 47618610D6 for ; Tue, 8 Jan 2019 18:13:19 +0000 (UTC) Received: by mail-yw1-f68.google.com with SMTP id g194so1907380ywe.7 for ; Tue, 08 Jan 2019 10:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sgNuBExTHIj8/qOzk5CunVlN3uq9rL2cMJP0hxKIq5s=; b=d0itKXe3kkPEhbY0YDT11IB78knBfi/dmhSrSXJmLeD8+F+yne8f+erM51WYFhlte0 vMf/1q7Rz8UqzYURR98+SvttC1dPsCifZbgAxz4X75jliuZq1/us+C0tYs7ihH9SbRsL N5yN+Q53sYp1VLYvnGj7ye0LAshsLK9lYeK/18s8Ru0IYmKJx8W2guH1+syR9Kn3o0bL dFWjV4hgM1/PnmxTsW9UJB0kbM8Q1vxVpkqrbTRhJ4Lf+fXqKDIiMv8/IJeHuSeqomHp oYyMZuD3DXPBEDXPCeYfWrtvN4G0/ZjMryEEFIEuGGfY2yeBcLJjC9MsmNUF8486bcul LqrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sgNuBExTHIj8/qOzk5CunVlN3uq9rL2cMJP0hxKIq5s=; b=VlmRiQ7aVOB21Wy0s+jVezqCMeelDXoGNJnezliNWqFEL5O8CgA4YKsb3k99Den34g uW0PnoQBbWNeibig9My7YTz/+56UFuzXqhGmVUQiYJAR+TdVjSktPmtcUI3uQsaUmYtW JNG7MYRZMEqPMyEa64GgLq5rDFfFna4ncYAeqB7+kWQ/OW7yaKfVbsuSx/acHe3quAUM uUXM5jgbsgh5dOp8VCXDSIW4TgZnZqy1GNXy2yB2nGjA2givPbwwIKz4l61jnOb6FumS uk1uefmgSBnP8Ex7Pe0xs7yFmzOthtWH5cOoFjsfVCSIX5sOW94Rwz3kAvYD0ntZR6BC WVtg== X-Gm-Message-State: AJcUukeWNL+txf0YTXPzfjmO3wRBPjY1+34lSLMQQhY4bbCDnaa7+6Ny 6EhHkb/t2gd5pZys/x61HyalGJ/31osYsLTmCbgbGg== X-Google-Smtp-Source: ALg8bN7KZKFXAMg6Cv4o2LKwbciXg2ybVJBcmkZ0mw0EyW9Stne8tMOS67ZMA51jMSFKpERoVO1I93+Ls30cPWzhAoA= X-Received: by 2002:a81:5142:: with SMTP id f63mr2681093ywb.11.1546971192170; Tue, 08 Jan 2019 10:13:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gerrit Binnenmars Date: Tue, 8 Jan 2019 19:13:01 +0100 Message-ID: Subject: Re: [DISCUSS] C++ Celix Framework To: dev@celix.apache.org Content-Type: multipart/alternative; boundary="00000000000063263d057ef64c55" --00000000000063263d057ef64c55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Pepijn, I am a bit concerned by this move. Introducing C++ in the framework makes Celix no longer a dynamic service framework for C. I understood the support for C++ in the API, so C++ bundles were supported, but this is something different. A lot of effort is put in the code quality and stability of the framework, does this work need to be done once more? My conclusion: I would prefer to keep the framework as is and concentrate on adding functionality. A C++ framework implementation does not bring enough to Celix. If you really want to continue this should not go into Celix but in a new Apache project. I am quite curious what the rest of the community thinks. Gerrit On Mon, Jan 7, 2019 at 11:19 PM Miroslav Berani=C4=8D < miroslav.beranic@mibesis.si> wrote: > Hi Pepijn, > > is there any metric data regarding performance, code size etc - compared = C > and "new" C++? > > Is there any plan to support other languages ( using language bindings ) = ? > > From my side, I would really like to see C version, but I guess C++ is > "must have". > > Kind Regards, > Miroslav > > > V V pon., 7. jan. 2019 ob 22:25 je oseba Pepijn Noltes < > pepijnnoltes@gmail.com> napisala: > > > Hi All, > > > > The last weeks I put some effort in exploring the benefits and > > downsides of changing the primary language of Celix from C to C++ in > > an experimental branch. > > > > As you probably already know Celix start around 2010 with the focus on > > a OSGi implementation in C; following the Java OSGi spec very > > strictly. And IMO that was correct choice at that time and with our > > given experience. > > My current vision is that we should follow the concepts of OSGi and > > where possible the nomenclature, but focus on delivering a (as much as > > possible) easy to use dynamic services framework for C/C++. > > > > IMO this also means that we should think about moving to C++. Because: > > a) With the concepts of C++11 we can create a much easier to use and > > hopefully also easier to develop/maintain framework. > > b) More type safe > > c) RAII; which really helps a lot in dealing with volatile services > > and trying to keep track of which services are still in use. > > b) C++ is simply more relevant and popular, which should help in > > getting more traction for Celix. > > > > To get the discussion rolling and for me to get a feeling what the > > effect of moving to C++ would mean, I created C++ experimental (but > > functionally quite complete) Celix C++ framework [1]. > > And I would like some feedback/discussion if this is an improvement > > for Celix or any remarks on the Celix C++ framework implementation. > > > > There are a few interesting changes in the approach/design of the C++ > > framework: > > 1) There is a separate (static) Registry library [2], which delivers > > the functionality to register/use/track (and TODO listener hooks) > > services. This library, by design, can be used without the rest of the > > framework. I designed the Registry library separate to keep it clean > > of bundles lifecycle stuff. > > - ServiceRegistration/ServiceRegistry uses RAII to make it easier > > in use, specifically for cleanup. > > - The registry also support registering std::function as services, > > this seems logical for C++. > > - The service template argument is used to deduce the service name. > > - The concept of services versions is dropped. I do think versions > > on API is important, but more in a distributed environment. In my > > experience for Celix everything should be build against the same > > service API's. Playing around with backwards compatibility on binary > > level with C++ is just reasonable. > > 2) The framework library [3]. Here the focus in on the BundleContext > > api so that almost everything can be done through the bundle context > > api. > > - It is now also possible to register "static" bundles. These > > bundles are installed on every created Framework object. This make it > > possible to register bundles with use a __attribute__((constructor)) > > decorated function. With support for "static" bundles, bundles can be > > created as shared objects, which "just work" if you link against them. > > See the C++ Shell example [4]. IMO this is a much .. much more natural > > way to handle bundles in a C/C++ environment. > > - Support for zip bundles and dynamically loaded shared object - with > > use a the bundle create, start,stop ..etc symbols is still TODO > > - BundleActivator now work on the constructor/destructor, i.e. also > > following a RAII approach. > > - There is no concept of a ServiceReference (same as in the updated C > > api). > > 3) Resources can be linked against a shared object and in that way > > OSGi extender pattern concept can be used without using zip files as > > bundles. See the C++ Shell implementation as an example (this bundles > > has a version.properties resource) [5]. > > 4) For now glog is used as logging framework. > > 5) libzip is used to handle the zip files. Note that resources linked > > against the shared object bundles are packed as a zip file. > > 6) googletest is used for testing. > > - It is also easier to test bundles, because the test executable > > "just" has to link against the bundle shared objects to make them > > available. See the tests of the C++ Shell bundle [5] > > 7) For now there is no way to export/import (versioned) shared objects > > from other bundles. I personally do no think this is really needed (I > > never use it myself). I also think that this should be solved by the > > language itself (i.e. C++ Modules). > > 8) As far as I can see it is possible to create a (mostly) backwards > > compatibility C API from the C++ framework. As long as we only support > > the updated C API, i.e. the the celix_* headers. > > > > The C++ framework API has no documentation yet, please be aware. I do > > think that it should be clear enough for experience users and the > > developers, but this is still a TODO. > > Currently for C++ there is a Registry [2] library, a Framework library > > [3], a C++ Shell bundle [5], a C++ Shell TUI bundle [6] and a single > > example executable to run everything [4]. > > I also took some effort to ensure that the code coverage result are > > generated and somewhat respectable. > > > > My experience thus far is mostly positive. Fewer lines of code are > > needed (duh), but also (mainly because of RAII) less if else branches > > are needed / error handling is needed. > > I do have some trouble arrange the code, because some part need to be > > in the header (template) or in Impl classes to ensure a more clean > > user API and the rest is in the sources files. > > > > Please feel free to let me know what you think. Note that this is > > still experimental and we will discuss how to move forward later. > > > > [1] feature/cxx branch (for the 807b88 .. commit): > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f > > [2] registry dir: > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f/libs/registry > > [3] > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f/libs/framework_cxx > > [4] > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f/examples/celix-examples/cxx_shell_example > > [5] > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f/bundles/shell/cxx_shell > > [6] > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60= 584f/bundles/shell/cxx_shell_tui > > > > > > Greetings, > > Pepijn > > > > > -- > Miroslav Berani=C4=8D > MIBESIS > +386(0)40/814-843 > miroslav.beranic@mibesis.si > https://www.mibesis.si > --00000000000063263d057ef64c55--