[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] Preverification support on MTJ
|
Eric,
Sorry for not getting a response back on this for a while. Part of it
is that I've been busy and part was that I was doing a bit of
experimenting.
On Apr 28, 2008, at 11:30 AM, Hildum Eric-XFQ473 wrote:
I have two questions for multiplatform support:
1. Is it just the preverifier that is the issue, or are there other
components we need to worry about as well?
Given projects like MPowerPlayer and microemu, Mac has basic emulation
functionality. These emulators are limited in their JSR support, but
are probably "good enough" for now. The problem does tend to be with
the preverifier.
2. Should we ask Sun if the existing PhoneME preverifier can also be
released as EPL code within MTJ?
You can ask, but my guess is that they will say that it is already
"open source". The problem is that it is GPL.
My thought is we must have Windows, Linux, and Mac support in MTJ,
the real question is the best way to get there (fast).....
I agree. I did some experimentation and found that building the
preverifier from source for the Mac was not terribly difficult. This
might be a reasonable starting point... I can always provide it as a
download for people to avoid EPL licensing issues with the GPL code.
To make user of this, it would be necessary to allow an arbitrary
external preverifier to be associated with mpowerplayer and microemu
projects. This is not supported by the EclipseME code on which MTJ is
based. The best thing we could do would be to allow the user to
choose an external preverifier or the built-in preverifier for *any*
device.
In terms of the built-in preverifier, I had a quick look at ASM 3.0 in
the process of doing something else for work. It appears there are
actually some better API's in there that could be used to "fix up" the
current implementation. Unfortunately, that may not be doable in the
short term.
In summary... I think there are some reasonable options for Mac, but
one of them is going to force the user through more hoops and the
other requires more work on MTJ part.
Craig
