Return-Path: X-Original-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C190E103EC for ; Wed, 12 Jun 2013 21:11:25 +0000 (UTC) Received: (qmail 32035 invoked by uid 500); 12 Jun 2013 21:11:25 -0000 Delivered-To: apmail-incubator-celix-dev-archive@incubator.apache.org Received: (qmail 32014 invoked by uid 500); 12 Jun 2013 21:11:25 -0000 Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: celix-dev@incubator.apache.org Delivered-To: mailing list celix-dev@incubator.apache.org Received: (qmail 32006 invoked by uid 99); 12 Jun 2013 21:11:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jun 2013 21:11:25 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of s.zelzer@dkfz-heidelberg.de designates 193.174.53.139 as permitted sender) Received: from [193.174.53.139] (HELO mailhost4.inet.dkfz-heidelberg.de) (193.174.53.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jun 2013 21:11:20 +0000 Received: from mx1.inet.dkfz-heidelberg.de (mx1.inet.dkfz-heidelberg.de [193.174.53.113]) by mailhost2.inet.dkfz-heidelberg.de (8.13.8/8.13.8) with ESMTP id r5CLAh9j011470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Jun 2013 23:10:43 +0200 X-External-Mail: Yes MX X-Envelope-Sender: s.zelzer@dkfz-heidelberg.de X-Envelope-Recipient: Received: from mx-ext.inet.dkfz-heidelberg.de (mx-ext.inet.dkfz-heidelberg.de [192.54.49.101]) by mx1.inet.dkfz-heidelberg.de (8.13.8/8.13.8) with ESMTP id r5CLAV1q030464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Jun 2013 23:10:43 +0200 Received: from [192.168.11.5] (HSI-KBW-46-223-218-16.hsi.kabel-badenwuerttemberg.de [46.223.218.16]) (authenticated bits=0) by mx-ext.inet.dkfz-heidelberg.de (8.13.8/8.13.8/smtpin) with ESMTP id r5CLAPLA024160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Jun 2013 23:10:26 +0200 Message-ID: <51B8E3C1.7070106@dkfz-heidelberg.de> Date: Wed, 12 Jun 2013 23:10:25 +0200 From: Sascha Zelzer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: celix-dev@incubator.apache.org Subject: Re: [Native-OSGi] Progress update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mx-ext.inet.dkfz-heidelberg.de [192.54.49.101]); Wed, 12 Jun 2013 23:10:29 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mx-ext.inet.dkfz-heidelberg.de X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,LOCAL_AUTH_GREY autolearn=disabled version=3.2.5 Hi, I just wanted to confirm that I think moving forward with the Celix project and extending it to support C++ is an important step. To get started, we should probably discuss the directory layout of the Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec, we could first try make the distinction between interfaces and implementation apparent at the directory level. A first (incomplete) shot of mine trying to cope with these new requirements looks like this: cmake ... framework/ <-- current Celix C implementation framework++/ <-- new Celix C++ stuff |---- wrapped/ <-- C++ implementation using the existing C impl. L---- native/ <-- independent C++ implementation (for experimentation) ... osgi/ |---- framework/ | |---- include/ | | L---- osgi/ | | |---- BundleContext.hxx <-- C++ interface | | L---- bundle_context.h <-- C interface | L---- src/ |---- cm/ | |---- include/ | | L---- osgi/ . | L---- cm/ . | |---- ConfigurationAdmin.hxx . | L---- configuration_admin.h - L---- src/ I tried to just add stuff on top of the existing repository to keep the impact low. With the second-level dirs, we could also add more sub-directories by e.g. having "c" and "cpp" folders below osgi/framework/ , but I thought trying to keep the hierarchy from getting too deep is better. We would still have to figure out how C and C++ implementations of service specifications could be marked as such and distinguished from each other (as long as these implementations are not contained in their own repository). I would be more than happy to contribute the work done in the Native OSGi directory so far (especially the C++ interfaces [1]). Looking forward to the discussions! Thanks, Sascha [1] https://github.com/abroekhuis/NativeOSGi/tree/master/src/api/cpp/include/osgi On 05/22/2013 09:17 AM, Alexander Broekhuis wrote: > Hi all, > > Quite some time ago there was already something mentioned about Native-OSGi > [1]. To recap: Native-OSGi is an effort to create a common specification > for OSGi in C and C++. This effort was started by the CTK Plugin Framework, > nOSGi and Apache Celix and although it has been rather quiet, there has > been a lot of progress. > > This progress is not as much on the technical front, but more on the > procedural front. During our initial talks we were asked if it would be > worthwhile to write the Native-OSGi specification as an OSGi Alliance RFC. > For us this meant a big boost in confidence wrt the specification. So of > course we said yes to this! > > So in the past period we have been working on a RFP which is the first step > towards writing the RFC for Native-OSGi. And now about a week ago this RFP > has been published for the general public to read, discuss and comment on > [2]. > > For this work we would like to use Celix (and the Celix project) as home > for, and as, the reference implementation. While Celix is writtin in C, > Native-OSGi also specifies a C++ implementation, as such we do like to > extend Celix to also support C++, but also like to start some discussion > wrt a implementation in C++. > > So I would like to invite everyone to read and comment to the RFP on [2], > but also would like to hear your comments regarding Celix and Native-OSGi > and as Reference implementation as a reply to this mail. > > Thanks! > > [1]: http://incubator.markmail.org/thread/7rqtyp2so2duapfy > [2]: https://www.osgi.org/bugzilla/show_bug.cgi?id=165 >