Hi
craig,
I
understand and share your
concern. when I looked at what is still there, in terms of public api,
it is
still a little confusing. So my feeling is that there is still room for
some
cleaning (move more classes/interfaces to be internal and do some
refactoring).
The main issues that I see are:
-
the symbolset api seems
to be duplicated: there are two packages with similar classes /
interfaces. We want
see if we can leave just one of them
-
clarify the concepts of
library and api classes (core.sdk.deivce.midp.library): there are
several
classes / interfaces that are public but it is not clear how to use them
-
there are a lot of interfaces
that are public on the mtj.core that can be moved to be internal
I’m
trying to leave
as public only what make sense to be public and that we can commit to
maintain
on the future.
If
we fix those 3 issues,
I think that we are going to be ok with our public apis.
Extract
isdk from
idevice, is something that we discussed a lot here on the list. This is
more an
improvement than a fix. We can postpone it to a future release, but I
just thought
that it is a good time to do it J.
in
terms of extension
points, out current list is:
-
core.externallibrary
-
core.deviceimporter
-
ui.midlettemplates
-
ui.jadeditorpages
-
ui.jadattributes
-
ui.deviceeditor
The
plan is to keep all
of that as they are now. I was also wondering about adding two more
that we
already have some discussions about them on the list:
-
core.sdkinstall: import
an sdk automatically when MTJ is started (this come from that
suggestion sent
by danail. We already have a bug opened for that). this extension point
is
associated to the isdk interface
-
core.buildhook: hook
into mtj build before and/or after the preverifier builder (this
requirements
comes from some discussion we had with RIM. I’m not sure if we can just
use the project nature / builder for that we don’t add any api). I will
send a separated email about that.
J
gep
Sorry... this email got lost
in my inbox.
My primary concern with *any* API changes at this time is that there is
really
no time to get feedback on those changes. The argument in favor of
making
the changes now is that it is easier than making them later. With that
said, if we really do lock these things in as API, we will need to
support
them.
What is your feeling at this point in terms of things that we are
actually
marking as API versus things that are provisional for 1.0?
Craig
Paula Gustavo-WGP010 wrote:
hi craig,
sorry for the late response. it is carnaval here in brazil :)
the change that we want to do now is to create the isdk interface. we didn't have time to do that in the last round :(. besides that there are also changes that we identify, but i'm not sure if we sohuld do it or not.
the idea is to remove imidpdevice and leave only the abstractmidpdevice class. the main motivation is that, if anyone is going to implement a midp device, he can just extend the abstractmidpdevice class and the interface is not necessary. but im not totaly convinced this is a good thing to do. do you think that this make sense?
:)
gep
________________________________
dp-mtj-dev-bounces@xxxxxxxxxxx em nome de Craig Setera
Enviada: qui 19/2/2009 21:32
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev] new round of mtj api review
Looks pretty good. Do we really want to bite off the IDevice/ISDK interface refactoring? Is that already done? Those seem like API classes that we should get in early in the *next* release so that we can get some burn in and feedback. I have concerns with us putting a lot of API changes in this late in the cycle when there isn't time to validate that those changes are what we want. (with the exception of making things private until we have time to vet them)
Paula Gustavo-WGP010 wrote:
Hi MTJ,
We did a new round of mtj api review and open a list with a several improvements. This list is available on mtj 1.0 plan
http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.mtj <http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.mtj>
under theme / priorities "MTJ API Documentation and Unit Tests". The focus was on the mtj.core plugin.
Please feel free to comment on those bugs and / or add new bugs. We plan to address those improvements on the following builds
:-)
gep
________________________________
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
