Re[2]: OSGi

[Peter Kriens <Pe...@aqute.se>]

Excuses for the large file. The main mailing list I use has a reply to
the sender and CC to the group which meant I replied to send Leo
Simons the files he asked for.

Hmmm, bad start :-)

Kind regards,

     Peter Kriens


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[4]: OSGi

[Peter Kriens <Pe...@aqute.se>]

I admit that I did not have a thorough look through the Avalon code
and are still a bit overwhelmed with the jargon I encounter. However,
I assume I do the same thing to this group :-)

I will try to have a deeper look into Avalon during the weekend so I
could come up with some kind of idea how to OSGi could fit
in/on Avalon.

PD> I also seem to recal that OSGI also defined a set of "work" interfaces for
PD> services such as HttpServers and like.
We have developed well documented interfaces for the
following areas in R2:

        - Logging
        - Http service (it is trivial to include servlets in the
          bundle)
        - Remote management of Java permissions and Java packages
        - Device Access (loads code on detection of external devices)
        - Configuration Management
        - Preferences database
        - User Admin
        - Metatyping

In R3 (due somewhere early next year) the OSGi alliance probably adds interface
specifications for:

        - Wire Admin (a dynamic component wiring model)
        - Dynamically extending URL stream and content handlers
        - Communications and messaging where bundles provide
          difference schemes.
        - Finding a suitable XML parser
        - Start and shutdown ordering
        - Measurements, Position
        - Jini
        - UPnP

PD> However I think you will find that the legalese and licensing will be the
As said, I am not a lawyer, neither do I want to become one. The way I
understand it, it is possible to implement the spec without any
licensing. Obviously, there may be unknown patents involved in the
spec, but the same can happen to your current work. It is today
impossible to write software without infringing on someone's IPR. For
the OSGi specs, at least the members have not declared any IPR on the
specifications. Anyway, if there is some technical enthusiasm we
should get lawyers involved.

I think it is in the OSGi's interest to get a group as Avalon
involved. I can try hard to make this impossible because I think I
understand why OSS developers are not going pay for this :-)

-- 
Peter Kriens                              Tel. +46 30039800
Finnasandsvägen 22                        Fax. +46 30039805
SE-43933 Onsala                           Mob. +46705950899


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Re[2]: OSGi

[Peter Donald <pe...@apache.org>]

Hi,

Don't worry I don't think it came through to the list because it was too big 
or something. I wouldn't mind seeing a copy of this aswell if you got a URI 
or can send it to me ;)

I have looked at OSGi before. I actually spent a couple of weeks going through 
OSGi, HPs CSF and comparing to Avalon ages ago. I am probably going to have 
another look at OSGi but probably wont have a chance to do it justice for a 
week or so so don't worry if there is no response for a while.

Anyways, from my memory OSGi actually is a slightly different style of 
framework and solves a lot of problems that Avalon has yet to handle (ie we 
have no consistent deployment or library format, nor do we have standards for 
native librarys access). 

It would be great to see Avalon adopt a format that was at least interoperable 
with OSGi. IIRC OSGi had ServiceFactorys for each bundle that would allow 
"foreign" component models like Avalon to be exported from a Bundle.

Avalon currently does not have the infrastructure to gracefully support OSGis 
Bundles. However it is likely that our next generation architecture will be 
able to use OSGi bundles as easily as current Avalon code. It would be an 
interesting exercise to support it. 

I also seem to recal that OSGI also defined a set of "work" interfaces for 
services such as HttpServers and like. Depending on their exact 
characteristerics they could definetly be useful to us (Lack of such 
interface specifications was actually discussed on Phoenix-dev today).

However I think you will find that the legalese and licensing will be the 
major block to adoption. RAND patent licensing effectively cuts off our 
ability to implement something. Inability to aquire TCKs except by forking 
out $ is also a problem with most of us as many of us work on Apache stuff 
out of our own pockets. Inability to participate in specification process 
except by forking out $ is another feature that is likely to discourage 
adoption.

-- 
Cheers,

Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |
*------------------------------------------------* 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>