In this scenario, can the end user still "install new plugins" inside
the applet or do you pre-configure an applet to some fixed
configuration. I am correct when I assume you cannot save any data to
the local file system in this applet, right? Do you already know how
to setup Felix to allow this? I see two issues in this area: 1) the
bundle cache, and 2) the bundle data area.
At the moment we do not have finished documentation about these
deployment scenarios. However, the whole system is built out of OSGi
bundles (eat your own dogfood) and all communication is HTTP (REST)
Another interesting question is, when we talk about provisioning
applets, do we want to provision the data up to the web server or up
to the individual client running the applet in the browser. Both are
possible in theory, what you choose depends largely on the
requirements you have.
On May 21, 2008, at 1:31 , Matthew Rubenstein wrote:
> Yes, the normal applet connecting back to only its webserver, with
> Felix framework bundled inside the applet. AFAIK, that is the scenario
> that various people are working on making work with S-C, who have
> mentioned that on this list. It's good to know that the provisioning
> server can run on either that webserver's host, or on a separate
> (like if the webserver is really just a firewall). Is there
> documentation that describes how to deploy your deployment server in
> those two variants of the basic scenario?
> On Wed, 2008-05-21 at 00:39 +0200, Marcel Offermans wrote:
>> Hello Matthew,
>> I'm assuming you mean as a normal applet, without special
>> so this applet can only connect to its host, and the host is not the
>> provisioning server itself? I'm wondering, in that case are you
>> embedding the whole Apache Felix framework within the applet, since
>> normally the framework would then create a local cache directory and
>> I'm pretty sure applets are not allowed to do that?
>> The provisioning server itself can work with one or more so called
>> relay servers. If you install one of those on that webserver, then
>> applet can contact the relay server to get its bundles. Effectively,
>> the relay server acts as a sort of cache for the actual server and
>> In case you run the webserver on the same machine as the provisioning
>> server itself, the whole situation becomes a bit simpler of course...
>> Greetings, Marcel
>> On May 20, 2008, at 23:49 , Matthew Rubenstein wrote:
>>> It seems like a useful featureset. Can the deployment server still
>>> offer those features if S-C is served from a webserver as an applet
>>> delivered in a webpage, not as an application that's installed on
>>> requesting client host?
>>> On Tue, 2008-05-20 at 21:47 +0200, Marcel Offermans wrote:
>>>> Let me briefly introduce myself. My name is Marcel Offermans, I'm
>>>> of the committers and PMC members of Apache Felix and I work for a
>>>> company called luminis. I am interested in helping out with the
>>>> mechanism for SIP communicator. I read the documentation at http://www.sip-communicator.org/index.php/Development/PluginRepositoryAndClientUI
>>>> Within luminis we have developed a provisioning server that
>>>> builds on
>>>> OSGi standards like Deployment Admin and the OBR. We would like to
>>>> offer our help to this community and offer a hosted provisioning
>>>> server environment for SIP communicator users so they can always
>>>> up to date with the latest version, configured the way they like.
>>>> As a developer of SIP communicator, you can put all the bundles you
>>>> have in an OBR. With a special client you can then associate the
>>>> bundles in an OBR with groups and associate groups with licenses.
>>>> These licences can then be combined in various way to create
>>>> configurations of the software.
>>>> As a user of SIP communicator, you get a list of licenses in an
>>>> UI and you can check all you want. A management agent, based on
>>>> Deployment Admin and embedded within SIP communicator, will then
>>>> care of actually installing and updating all bundles that are
>>>> associated with the components you've selected.
>>>> In our opinion, this is better than directly selecting bundles
>>>> those are often way too technical for end users. They care about
>>>> features, which can be easily represented by the licenses mentioned
>>>> I would like to have your opinions, is this something you would be
>>>> interested in?
>>>> Greetings, Marcel
>>>> To unsubscribe, e-mail: firstname.lastname@example.org
>>>> For additional commands, e-mail: email@example.com
>>> (C) Matthew Rubenstein
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>> For additional commands, e-mail: dev-help@sip-
> (C) Matthew Rubenstein
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: dev-help@sip-