Torsten Curdt wrote:
Maybe I should just shut up and let Daniel continue with his awesome job ...but (there is always a but)
I hope that you and everyone else speaks up and rise your concerns if you have any. I don't want this to be some one man show. I can do prototyping and write RTs on my own (altough I would prefer to work together with others), but there is a limit for how much I can work and still find it stimulating and don't risking burnout. We need community involvement in this area sooner rather than later if we really want real blocks.
...although I really think it makes sense to move into this direction I would like to express my "Avalon-fear". No documentation, we require the latest version, not our community...
I can understand the "Avalon fear". But there are large differences between Avalon and OSGi. The problem with Avalon wasn't the technology but (after a while) its community dynamics. I'm certain that large organizations like OSGi has it own share of community problems, but for an organization with maybe 40 member organizations http://www.osgi.org/about/member_list.asp?section=1, its qualitatively different, and to much money is involved to let it end as Avalon. Furthermore they have been around for 6 years and their standard is widely used and have 10+ implementations.
I don't like the documentation situation nor requiring the latest version. I just don't see any better options. OTH we are not exactly talking about an early alpha from some obscure organization. It is after all the kernel for Eclipse 3.1 release candidate 4, which IIUC is the last release candidate before the real release. And according to its developers it fullfills OSGi R4 that will be released rather soon, (it was supposed to be released during this spring).
Am I the only one? Daniel, your are the one that spent the more time looking into this stuff. Do we really need the whole framework? Do we want the whole framework or just the classloading part?
The framework consist of the class loading part, bundle management and a service architecture that supports hot deployment. The standard also involve various standard services, typically packaged in separate bundles. For Knopflerfish the whole framework and some basic services is contained in a 200 kB bundle, so it is not that huge. The minimal Eclipse framework bundle contains more and is about 800 kB.
I find the whole framework usefull and have no idea about how one could split it. What services we should use, if any, is another question and something we can discuss one case at a time when we need them.
Maybe we could also just rip out parts that we need? ...might be a legal problem but having full control of the what is so core seems to be so desirable to me.
TBH, we have discussed containers for years, forked Cocoon a couple of times and Pier have even implemented an own kernel, without getting that much closer to real blocks. And today we have fewer active developers with container implementation competence and interest than we had a year or two ago. I don't see that we have the capacity for building our own kernel from scratch. Even if we use an existing kernel, we have a lot of work to adapt our current stuff to it. Both building our own kernel and adapt our current stuff to it seem unrealistic to me.
Just me expressing my (stupid?) concerns reading this thread...
Hopefully the above clearyfied the situation somewhat. /Daniel
