Hi, I'm pretty much ready to move on from OSGi. It's sort of the mass-has-overcome-agility problem. I have contemplated just creating the next generation on my spare time at home, but that's such a tall proposition. There are numerous things that need to be corrected and addressed, not just OSGi, but "the state of the state" of the industry. Then again, I have half a mind to throw in the towel and spend all my waking efforts as a studio musician, so go figure.
A while back, I created an "OSGi builder" - more to the point, the notion of "source bundles", extensible to any language. In it's most basic form, take a standard bundle, remove the dot.class files, and replace with dot.java files. I think you get the idea. What's mind boggling to me is that, while I'm getting enormous push back on this, at the very same time, scala-in-osgi is getting flying-green-lights. Go figure. But, this would work very well for C++/c as well. You could even bring in dot.net/mono stuff if you wanted, but that's a tad bit reaching. It does bring up the notion of spec supporting other frameworks besides Java (and who knows what the future holds with Oracle at the helm). Back to the point - the state of the state is pretty much abysmal because the "framework should be the convention" but frameworks have yet to step of to the place and take care of "the framework gap"; The lack of distributed anything from day 1 has been a plague. Maybe that's why I also embed in other [greater] frameworks (well, there are numerous reasons). Of course, I dread "security" but it's an essential. I'm pretty much done with all the RSA/cert/truststore stuff. There's just got to be a better way. I'm fairly happy with AES2 - that's usually my crux. And, get away from the current run time framework (e.g., JVM). The key thesis of anybody out there should be to revolutionize the state of the state, which is abysmal. The reality is "the framework is the convention"; Frameworks almost never take care of "the gap" and usually only step up the "execution time" plate. The gap is pretty much everything - usually missing and incomplete. Which leads to all these ridiculous concoctions such as Maven. Which, IMO, illegally tried to hijack "the gap"; It's illogical, really. The framework is the convention - reality has a way of not moving, no matter how many mojo's you throw / "spin" at it. So, a la contrivances such as "source bundles" at least take a small bite out of the problem by putting the build back on the shoulders of the framework, where it has belonged from day 1. There should not even be two commands: java and javac -- there should just be java. The key, to this one small aspect of the problem, is that source is natively deployable. You can deploy obfuscated source if you want. My two cents (and rant). What do I care? I'd rather be a rock-n-roll/progressive/jazz/nin guitar player anyway. Cheers... ________________________________________ From: [email protected] [[email protected]] on behalf of Christopher Armstrong [[email protected]] Sent: Sunday, March 13, 2011 7:17 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] re: OSGI thesis Hi Andriy I used the Device Access Specification for an undergraduate thesis. Its subject was integrating HAL (http://www.freedesktop.org/wiki/Software/hal) with this specification for automatic device enumeration. I'd say any part of OSGi is suitable for a thesis. Like any thesis, it depends on what you and your supervisor is interested in. You could also go more high-level and examine topics such as the impact of OSGi on Java modularity on real-life projects, the value of adding OSGi to existing software programmes, etc. There are plenty of other underused Compendium specifications (like Wire Admin) that might be interesting to use in a thesis. Cheers Chris On Sun, 13 Mar 2011 20:01 -0300, "Andriy Drozdyuk" <[email protected]> wrote: > Hello, > I am currently starting my master's program, and I am looking for a > topic. > I was wandering if there is any aspect of OSGI that can be used for > thesis work? > > I've found one thesis that touches on OSGI as part of it's topic: > http://www.polberger.se/components > > I'm mainly looking for any ideas or direction in which I can start > looking. Anything helps - thank you! > > -Andriy Drozdyuk > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
