Community
Participate
Working Groups
I was passing by the updatechecker code and have a few comments... - UpdateChecker should not be the service API rather there should be an interface as the service type. The implementation we use should be internal - I wonders about having many update checker threads. Another way to look at this is that there is one update checker dispatcher that happens to use Jobs (whatever) to actually run the checks. It might be a nit but having many threads running all the time may have scaling issues. In practice people are going to poll hourly/daily/... so most of the time the threads are just taking up space. - We will likely have to refine the idea of what kinds of updates are interesting. For example, in one of the main usecases we should only look for updates to things the user installed (e.g., the top level IUs they chose and installed). Otherwise we might be updating pieces of their "apps" without really understanding if that makes sense. - can we combine the updatechecker.app into the updatechecker itself? This eliminates one extra bundle. - is there any value in having multiple checkers on one profile?
- the use of ServiceHelper here is less than optimal. Since checkers are long running, they should no hang onto the services acquired using the helper. Either they should use a tracker or use ServiceHelper every time (no caching)
Thanks for checking this. With respect to services, caching, etc....I don't really have a feel for what the right patterns are at this level. I just followed the example in org.eclipse.equinox.p2.exemplarysetup. My thinking was that the update checker's life cycle was similar to the director, planner, repo managers, etc., and that its access should be similar. Should these be changed also? Threads - originally I wasn't really sure if there was a need to run any of this code independent of Eclipse-isms like jobs, etc. But I don't think that's an issue, so I can change this to jobs. Which updates are interesting - to keep the API simple, I started by checking for all updates to a profile and letting the client sort out which ones they care about. But we could save a good bit of time by letting the client specify which updates to check up front rather than sorting through it all after the fact. The update checker app is really just a simple app for testing the update checker. So I don't see including it in the actual update checker bundle. The code currently doesn't optimize for multiple checks on a profile, and it doesn't prevent it. For now I intend to leave this as is until we have more use cases and know whether to optimize that case.
Closing as no more work is planned.
.
