| I was referring to this email:
I was starting to think through the EclipseCon presentation yesterday and digging around to see what extension points exist. I see we've added a "Library" extension point to the system. I honestly don't know exactly what is going on there, but it "feels" very similar to the "API" extension point that exists in the core (from EclipseME). There is also the Profiles and Configurations extension point, which are kind of like specializations of the API extension point and drive some of the UI (also from EclipseME). This all seems a bit too much. Although I don't have a specific answer for how to resolve this, it definitely doesn't seem like we need 4 extension points here. It would be nice if we can understand all of the things being driven by these points and collapse these points down? I think we should probably spend some serious time looking at the IDevice and related interfaces. As they stand right now, they are very much JavaME interfaces. It may be worthwhile to look at how we might boil down to the absolute minimum "launching" stuff and separate out some of the JavaME specifics into another interface? Anyway... these are the types of conversations that I would like to see us have before considering things "API complete". Craig Hi craig, This initial proposal only lists the packages, some classes and the extension points. We still need to go into the detail of each class. We didn’t include yet the discussion that we had in the past week about device / sdk register. J gep I will try to find time tonight to look at your proposal and then offer my opinions. Does the proposal address the issues I brought up a week or so ago on the list? On Jan 29, 2009, at 2:04 PM, Paula Gustavo-WGP010 wrote:
I’m also concerned with that. As far as I understand, our requirement is to have an API freeze on M6 and, if we want to be a 1.0, we need to have a “closed” api. But we don’t need to be 1.0 to be on the train. We are proposing that because it seems to be a good timing for MTJ (but we can re-discuss that) On the API review, what we can do if to focus on some parts that are more important and leave the rest of the API as internal (that’s what eclipse suggests). This would reduce the effort to review and have all inputs. On the future we can start to discuss about moving some of the internal apis to be public. On the proposal we already tried to do something like that Do you think this make sense? For clarification, what are the API requirements for Galileo release? I'm very concerned with trying to complete API's in such a short period. I'm also concerned about declaring the API's "complete" without enough time to get lots of input. Do we need to be at "1.0" for the release train? If so, how is 1.0 defined and can we declare some of the questionable API's as provisional until we can get more input? On Jan 29, 2009, at 1:14 PM, Paula Gustavo-WGP010 wrote: Hi MTJ, We did an initial analysis of current MTJ API and presented a proposal of the possible changes that we can do. This proposal is documented on our wiki http://wiki.eclipse.org/DSDP/MTJ/Discussion/Refactoring. This is just a proposal, so feel free to suggest other possible changes. MTJ API freeze is on M6 (Mar/16/2009), so any change that we want to do need to be done until that date. Since there is not a lot of time, I would like to propose a target date of Feb/13 to close this review process. This would give us time to implement the changes after we decide which one should be there. We can have this discussion here on the list. Regards, J gep
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|
