[sip-comm-dev] Installing and updating SIP Communicator with a provisioning server


#1

Let me briefly introduce myself. My name is Marcel Offermans, I'm one 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 update 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 stay 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 different configurations of the software.

As a user of SIP communicator, you get a list of licenses in an update UI and you can check all you want. A management agent, based on Deployment Admin and embedded within SIP communicator, will then take 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 because those are often way too technical for end users. They care about features, which can be easily represented by the licenses mentioned above.

I would like to have your opinions, is this something you would be interested in?

Greetings, Marcel

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

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 the
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 one
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 update
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 stay
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 different
configurations of the software.

As a user of SIP communicator, you get a list of licenses in an update
UI and you can check all you want. A management agent, based on
Deployment Admin and embedded within SIP communicator, will then take
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 because
those are often way too technical for end users. They care about
features, which can be easily represented by the licenses mentioned
above.

I would like to have your opinions, is this something you would be
interested in?

Greetings, Marcel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello Matthew,

I'm assuming you mean as a normal applet, without special permissions, 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 the 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 OBR.

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 the
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 one
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 update
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 stay
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 different
configurations of the software.

As a user of SIP communicator, you get a list of licenses in an update
UI and you can check all you want. A management agent, based on
Deployment Admin and embedded within SIP communicator, will then take
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 because
those are often way too technical for end users. They care about
features, which can be easily represented by the licenses mentioned
above.

I would like to have your opinions, is this something you would be
interested in?

Greetings, Marcel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Marcel,

Let me briefly introduce myself. My name is Marcel Offermans, I'm one 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 update mechanism for SIP communicator. I read the documentation at http://www.sip-communicator.org/index.php/Development/PluginRepositoryAndClientUI

Interacting with an OBR is IMHO a very interesting and useful feature for SIP Communicator, especially because we recently had more and more plugin contributions. I completely share your opinion on the ease of use and management that such feature would bring to SC users and developers.

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 stay up to date with the latest version, configured the way they like.

This is indeed a very nice proposition! We'd be very happy to use such a server. Note that Mathieu Plourde will work on this topic as part of this year's Google Summer of Code, so your proposal came just at the right moment! I guess Mathieu will take care of the client part (SC), and the server you would provide us will certainly greatly help him in his work.

Thank you for your precious help. Maybe Mathieu will have further thoughts on this topic.

Cheers,

···

On 2008/05/20, at 21:47, Marcel Offermans wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Yes, the normal applet connecting back to only its webserver, with the
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 server
(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 permissions,
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 the
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 OBR.

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 the
> 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 one
>> 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
>> update
>> 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 stay
>> 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
>> different
>> configurations of the software.
>>
>> As a user of SIP communicator, you get a list of licenses in an
>> update
>> UI and you can check all you want. A management agent, based on
>> Deployment Admin and embedded within SIP communicator, will then take
>> 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
>> because
>> those are often way too technical for end users. They care about
>> features, which can be easily represented by the licenses mentioned
>> above.
>>
>> I would like to have your opinions, is this something you would be
>> interested in?
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
> --
>
> (C) Matthew Rubenstein
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net
>

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello Matthew,

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) based.

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.

Greetings, Marcel

···

On May 21, 2008, at 1:31 , Matthew Rubenstein wrote:

  Yes, the normal applet connecting back to only its webserver, with the
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 server
(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 permissions,
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 the
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 OBR.

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 the
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 one
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
update
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 stay
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
different
configurations of the software.

As a user of SIP communicator, you get a list of licenses in an
update
UI and you can check all you want. A management agent, based on
Deployment Admin and embedded within SIP communicator, will then take
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
because
those are often way too technical for end users. They care about
features, which can be easily represented by the licenses mentioned
above.

I would like to have your opinions, is this something you would be
interested in?

Greetings, Marcel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-
communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

The general practice is for the applet to save back to its webserver by
HTTP any persistent data, and for the applet to download with all
plugins preinstalled. So installing new plugins sends a message to the
webserver for a new applet bundle that contains everything, including
the new plugins, and the new configs of the plugins list and their
configs is stored on the webserver.

  Though perhaps there are some implementations that allow the applet to
download just a new plugin, not a whole new applet containing the
plugin. And there might be signed applets that can connect to hosts
other than the original webserver from which the applet was downloaded,
which preserve S-C's P2P features (rather than all mediated by that
webserver). If other people implementing this applet version of S-C will
explain their variations on the scenario, we will know more.

···

On Wed, 2008-05-21 at 11:05 +0200, Marcel Offermans wrote:

Hello Matthew,

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)
based.

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.

Greetings, Marcel

On May 21, 2008, at 1:31 , Matthew Rubenstein wrote:

> Yes, the normal applet connecting back to only its webserver, with
> the
> 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
> server
> (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
>> permissions,
>> 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
>> the
>> 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
>> OBR.
>>
>> 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
>>> the
>>> 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
>>>> one
>>>> 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
>>>> update
>>>> 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
>>>> stay
>>>> 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
>>>> different
>>>> configurations of the software.
>>>>
>>>> As a user of SIP communicator, you get a list of licenses in an
>>>> update
>>>> UI and you can check all you want. A management agent, based on
>>>> Deployment Admin and embedded within SIP communicator, will then
>>>> take
>>>> 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
>>>> because
>>>> those are often way too technical for end users. They care about
>>>> features, which can be easily represented by the licenses mentioned
>>>> above.
>>>>
>>>> I would like to have your opinions, is this something you would be
>>>> interested in?
>>>>
>>>> Greetings, Marcel
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>>>
>>> --
>>>
>>> (C) Matthew Rubenstein
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>> communicator.dev.java.net
>>> For additional commands, e-mail: dev-help@sip-
>>> communicator.dev.java.net
>>>
>>
> --
>
> (C) Matthew Rubenstein
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net
>

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hello Matthew,

If you sign the applet you can indeed ask the user for permission to do more (like contact other servers or store local files), but then you're already going towards something like Java Web Start (which is also a nice combination, webstarting the core Felix framework and then installing bundles using some OBR / OSGi based mechanism).

There are definitely all kinds of possibilities in this area, so I'll wait a bit until the people working on the applet version have had time to react and/or clarify their goals.

Greetings, Marcel

···

On May 21, 2008, at 14:22 , Matthew Rubenstein wrote:

  The general practice is for the applet to save back to its webserver by
HTTP any persistent data, and for the applet to download with all
plugins preinstalled. So installing new plugins sends a message to the
webserver for a new applet bundle that contains everything, including
the new plugins, and the new configs of the plugins list and their
configs is stored on the webserver.

  Though perhaps there are some implementations that allow the applet to
download just a new plugin, not a whole new applet containing the
plugin. And there might be signed applets that can connect to hosts
other than the original webserver from which the applet was downloaded,
which preserve S-C's P2P features (rather than all mediated by that
webserver). If other people implementing this applet version of S-C will
explain their variations on the scenario, we will know more.

On Wed, 2008-05-21 at 11:05 +0200, Marcel Offermans wrote:

Hello Matthew,

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)
based.

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.

Greetings, Marcel

On May 21, 2008, at 1:31 , Matthew Rubenstein wrote:

  Yes, the normal applet connecting back to only its webserver, with
the
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
server
(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
permissions,
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
the
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
OBR.

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
the
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
one
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
update
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
stay
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
different
configurations of the software.

As a user of SIP communicator, you get a list of licenses in an
update
UI and you can check all you want. A management agent, based on
Deployment Admin and embedded within SIP communicator, will then
take
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
because
those are often way too technical for end users. They care about
features, which can be easily represented by the licenses mentioned
above.

I would like to have your opinions, is this something you would be
interested in?

Greetings, Marcel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-
communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-
communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net