Re: 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,

Re: Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox

Moving SAT to Equinox does not mean adoption across the SDK.
The motivation for moving it into Equinox is simple: make SAT available at
the place where people would look for it.

As for looking at the bigger picture of component programming, we have been
trying to do it for a long time (see eclipse 3.2 and 3.3 plans). Today we
are actively doing it and SAT represents just one exploration path but it
is not our final answer as many problems are left unanswered.

The overall goal of the exploration is to come up with a set of libraries /
patterns / helpers / ... in time for the development of Eclipse 4.0 and we
are eager to have discussions about the pros and cons of each approach use
the p2 codebase as a test bed.

So please keep the feedback coming.

Regards,

PaScaL

|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Peter Kriens <Peter.Kriens@...>                                                                                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

Re: Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox

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 <Peter.Kriens-+2weGw+6nfulVyrhU4qvOw@public.gmane.org> Sent by: equinox-dev-bounces <at> eclipse.org 10/01/2007 05:18 AM Please respond to Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To Patrick Dempsey <pd-Ek8mLR18WjLQT0dZR+AlfA@public.gmane.org> cc Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> 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
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[prov] touchpoint contribution

Hi,

Following up on today's discussion around the touchpoint and their actions,
I wrote up a wiki page summaryzing what Simon is currently implementing:
http://wiki.eclipse.org/Equinox_p2_touchpoint
It goes without saying that any questions / discussions / suggestions are
welcome,

Thx

PaScaL

[p2] Wiki page reorg

Re: Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox

On Oct 1, 2007, at 5:18 AM, Peter Kriens wrote:

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

Thank you for the kind words regarding our tutorial at last year's  
EclipseCon!

Yes, SAT does fulfill a need and we would certainly miss it if it  
went away.  Of course, what we like most about it is that it enables  
us to focus our development on POJO's - so we can statically test  
withe ease.  While we really focus on the embedded side, we also like  
the idea that we can reuse our core component models on the server  
side with an Spring-based OSGi enabler.  By loosely coupling our  
application code with the dependency injection model and maintaining  
clear lines of delineation, all future paths remain open to us.

Beyond those reasons, I think it does boil down to the comments from  
Jeff and Pascal - that (1) SAT should be moved to where people would  
most likely expect to find it and (2) it is not an endorsement by  
Equinox to make SAT available as a component..it is merely an  
option.  If something better comes along for us, we will expect SAT  
to evolve or we will move to the better solution.  However, SAT has  
proven robust and mature enough for us to successfully deliver some  
very complex applications using some very simple development  
principles that do not invade our application code - in this sense,  
less is more..and is better for us.

Best regards,

--
John Cunningham

Band XI International, LLC
150 Beacon Hill Drive, West Hartford, CT 06117-1006

email: jc@...	web: www.bandxi.com
phone:	860.233.1526	alt: 860.434.9322
mobile:	860.869.1526	fax: 860.233.1529

Equinox projects tagged for 3.4 I-build

[p2] UI priorities for M3

Re: [p2] UI priorities for M3

Re: [p2] UI priorities for M3

I glanced through it and there are some interesting ideas. I will provide
feedback through the appropriate channels.

                                                                                                                        
  From:       Thomas Watson <tjwatson@...>                                                                       

  To:         Equinox development mailing list <equinox-dev@...>                                                

  Date:       10/02/2007 03:42 PM                                                                                       

  Subject:    Re: [equinox-dev] [p2] UI priorities for M3                                                               

There is a proposal for a new Bundle-License manifest header that will be
considered for the next release of the OSGi specification. We will need to
monitor this RFC #125 to ensure that it meets our needs for presentation of
licenses in p2. This is not an immediate concern for p2 but we need to make
sure the proposal is something we can use in the future.

Tom

(Embedded image moved to file: pic03929.gif)Inactive hide details for Susan
M Franklin---10/02/2007 01:57:50 PM---Hi, everyone.Susan M
Franklin---10/02/2007 01:57:50 PM---Hi, everyone.

 (Embedded image moved (Embedded image moved to file: pic04846.gif)        
 to file:              Susan M Franklin/Beaverton/IBM <at> IBMUS                
 pic31713.gif)                                                             
 From:                                                                     

 (Embedded image moved (Embedded image moved to file: pic08031.gif)        
 to file:              equinox-dev@...                             
 pic22422.gif)                                                             
 To:                                                                       

 (Embedded image moved (Embedded image moved to file: pic02449.gif)        
 to file:              10/02/2007 01:57 PM                                 
 pic02506.gif)                                                             
 Date:                                                                     

 (Embedded image moved (Embedded image moved to file: pic30219.gif)        
 to file:              [equinox-dev] [p2] UI priorities for M3             
 pic10353.gif)                                                             
 Subject:                                                                  

Hi, everyone.
One of the goals for M3 is to try to define the conent/scope of our 3.4
deliverable. So I'm trying to balance our desire to resolve unknowns with
getting current workflows more polished. I'm interested in the community's
feedback on the current M3 UI plan, which currently includes

- improving the install/uninstall/update workflow by providing more info
(size, time, invalid states, etc.)
- polling for software updates and notifying the user
- improved support for browsing repos (IU categories and filtering)
- more info in admin artifact repo views

(You can see the expanded detail at
http://wiki.eclipse.org/Equinox_p2_User_Interface#Milestone_plan).

This is a rather aggressive plan but still does not address some other big
UI items, most notably
- UI for rollback
- presentation of licenses

So if you have opinions on the pressing issues and priorities in the UI,
please let me know via this list, or annotating bugs you care about,
etc....

thanks,
susan_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev