Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOvkMoaenk3660D29gBE=NK4bALaF76cimd7m-BktDnY0GW0kQ@mail.gmail.com>
References: 
 <CA+T-u8fPAVS+2MqQouECyh60OuuhAqGVpGzRydFTXM0UWqW9QQ@mail.gmail.com>
	<CAOvkMoaenk3660D29gBE=NK4bALaF76cimd7m-BktDnY0GW0kQ@mail.gmail.com>
Date: Thu, 12 Jul 2012 09:37:59 +0200
Message-ID: 
 <CA+T-u8dzx4eJsu_nqF4nL70GB=B_Hc-_QnTKkZ8bTQ2WnfR-4w@mail.gmail.com>
Subject: Re: Native OSGi
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d04447383f7b2ff04c49d0a29

--f46d04447383f7b2ff04c49d0a29
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have been very bussy, so sorry for the late reply, but thanks for your
interest!

>
> But I have a question ? Why making the native implementation only directed
> to C and C++ and not making these specs for *native* implementation as in
> terms of native in languages other than Java in which on OSGi compliant can
> be implemented not intended to run over the JVM ?
>

We've discussed this as well, the original Universal-OSGi RFP targeted
several other languages as well.
But from our point of view we like to keep the focus fairly limited (for
the time being).

The mentioned projects all use C/C++ so this is where the most knowledge
lies, adding different languages only broadens the scope and makes it more
difficult to get some work done. We need more people onboard (with
knowledge of that specific language), which makes it more difficult to
discuss items etc etc.

Also, we need a specification which explicitly details how several problems
are solved in a certain language. Especially the dynamic loading of bundles
and bundling itself needs attention. For other languages this is solved
differently as for C/C++ (even though C and C++ are different languages,
the dynamic aspects are solved in the same manner).

So I personally think it makes more sense to create a separate
specification for other languages (language groups) detailing the specific
aspects of that language. Some overall document detailing the generic
aspects of OSGi would make sense in such case.

But for now, this is not our goal, I think we will have enough of a
challenge with the current path we selected/set out.


-- 
Met vriendelijke groet,

Alexander Broekhuis

--f46d04447383f7b2ff04c49d0a29--