Hi Craig,
I did
some sugestions on IDevice, concerning it be so “JavaME”
and suggested extract these characteristics to more specialized interfaces that
extended a common IDevice. I did the same idea with some other interfaces.
About the library E.P
it follows a different idea from the API E.P.
Currently the API E.P
is used to describe the JSRs available in a device. The library is used to
declare a 3rd party library that not comes with an SDK such as an API
for database access or the Lightweight UI Toolkit (LWUIT).
Diego
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Thursday, January 29, 2009
5:21 PM
To: Mobile Tools for The Java
Platform mailing list
Subject: Re: RES: RES:
[dsdp-mtj-dev] MTJ API Proposal
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
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.
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
|