As Pascal mentioned SAT would be just one element available from the Equinox project. Felix has ipojo, jmood, mosgi, ... and other things that are add-on elements people can use in developing their bundles. SAT is no different. If (and I mean "if") SAT is adopted by parts of the Eclipse project it would have the beneficial effect of driving the bundle code to be more POJO-ish and thus pave the way for DS, Spring, <whatever> adoption once the story becomes clearer.
As for laziness, yes, this may turn out to be an issue. But until someone does some investigation it will be unclear how much of an issue. BTW, at the Equinox summit we had quite a bit of discussion around this and it turns out that most of the same laziness issues arise in the Spring/OSGi work as well. So any investigations should be mutually beneficial. Jeff Peter Kriens <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/01/2007 05:18 AM Please respond to Equinox development mailing list <[email protected]> To Patrick Dempsey <[EMAIL PROTECTED]> cc Equinox development mailing list <[email protected]> Subject Re: [equinox-dev] Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox I am not sure how to bring this without get yelled at, or at least become disliked even more :-( However, I think the inclusion of SAT in Equinox requires some strategic considerations. More is not always better. I hesitate to bring this up because I like what the BandXI people (and before OTI) have created, and I thought there tutorial on EclipseCon was really nice. SAT clearly fulfills a need, hearing the many satisfied customers. However, I think it should be reviewed how SAT fits in the overall programming model for Eclipse. Including it in Equinox will say to the world that this is the way to program for Equinox, or at least will confuse the world between SAT and DS. This library has been around for a very long time and that maturity is a key advantage. However, it also means that it is not lazy, an item that Equinox people always have expressed to the extreme. It introduces yet another service programming model over declarative services (and the upcoming component model based on Spring). I think it should also use some of the techniques like Service Tracker instead of raw service listeners, which can be optimized per platform. I am -not- saying SAT should -not- be included, I am trying to say that Equinox should have a more thorough review of what SAT is, and see if this is the strategic direction they want to take. Including a library like SAT is not context free. Sorry to be a pain in the ... Kind regards, Peter Kriens PD> Currently the Service Activator Toolkit (SAT) in the Open PD> Healthcare Framework (OHF) technology project that is of great PD> value to people programming OSGi Applications. SAT is a Java PD> component that simplifies the building of OSGi service-oriented PD> bundles. It is approximately 8,000 lines of Java code. By PD> decreasing the complexity of OSGi bundle development, this toolkit PD> provides increased acceptance of OSGi in the device community. In PD> addition to making the use of OSGi services easier, it supports PD> the creation of well behaved bundles, reducing development time, PD> reducing training costs, and promotes consistent bundle behavior. PD> It seems that this technology is somewhat misplaced and it would PD> better serve the community if it was part of the Equinox project. PD> I propose moving SAT from OHF to Equinox. As this code is very PD> stable, robust and has been previously used in commercial PD> products, I would ask that it be reviewed for eligibility for PD> moving in the graduated Equinox bundles area, rather than the Equinox Incubator. PD> For reference SAT is in cvs at PD> :pserver:dev.eclipse.org:/cvsroot/technology PD> org.eclipse.ohf/plugins/org.eclipse.soda.sat PD> There is also lots of good information (documentations, bug reporting, downloads) at PD> http://eclipse-sat.blogspot.com/ PD> Patrick PD> -- Peter Kriens Tel +33467542167 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599 _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
