Home » Archived » DSDP - Mobile Tools for Java (MTJ) » Device Fragmentation Use Cases
| Device Fragmentation Use Cases [message #5269] |
Thu, 17 November 2005 13:26  |
Eclipse User |
|
|
|
Originally posted by: csetera.spss.com
I haven't seen any mention of the use cases I described for managing
device fragmentation. Has anyone had a chance to look at these from my
earlier post? If not, do I need to post them again? I recognize they
probably are not going to be 1st priority use cases, but it seems to me
that that functionality should probably rank above many of the current
3rd and 4th priority use cases on the wiki.
Thanks,
Craig
Lead EclipseME Developer
|
|
|
| Re: Device Fragmentation Use Cases [message #6727 is a reply to message #5269] |
Thu, 17 November 2005 18:24  |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
Hi Craig & all,
Device Management
=================
I think making the individual devices the 'basis' of a defined project
is a good idea. I think lots of work would have to go into creating
pre-defined (templated) device definitions for the developers. A
tutorial on creating these definitions would be very useful for the
developers. A core set of device libraries should be made available and
these libraries should be pre-defined in the various templated device
profiles.
Perhaps, in some cases, it would be sufficient to have groups of devices
sort of bundled together under a more generalized 'umbrella' of
definitions/libraries, with the option of increasing device-specific
granularity via further definition/configuration. Of course, a tutorial
on how to do this (including examples) would be very useful for the
developers.
Code Management
===============
I agree with what you've written here, Craig. The 3 bullet-point summary
sums it all up. It would be nice if some kind of pre-defined templates
for code management purposes were also available for the developers so
they could see what has to be done/defined/configured in order to
implement the device-based code management.
Resource Management
===================
Agree completely. Again, templates and examples.
I think resource management and code management could be made so similar
that the only real difference would be folder names (src vs. res??).
Configuration Management
=======================
Yes, I think that a layered approach, where each layer has successively
deeper and deeper perspectives on project-based particulars (ultimately
totally based on the particular device differences themselves) would be
necessary. The developers would probably prefer to use a "top-down"
approach in defining their projects at first, but perhaps a "bottom-up"
approach would be preferrable as the environment is mastered.
The pre-defined development (tutorial) of 'small', 'medium' and 'large'
project definitions and configurations would be very useful to the
developers.
Perhaps different pre-defined environments could be split into two major
partitions, starting at the 'upper' layers with device differences
including things like operating system, functionality similarities and
device capabilities, eventually working down to the 'lower' layers where
very device-specific differences can be defined, etc. ??
Build Support
=============
Very much so, backend J2EE-based server applications should be
integratable with the mobile applications. Ant build scripts would seem
the logical choice here. Individual configuration definition flexibility
is definitely needed here.
Could Maven be used anywhere in here??
I will comment on the User Scenarios in a separate message.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #6742 is a reply to message #5269] |
Thu, 17 November 2005 22:14 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
Device/Code/Resource/Configuration Management
=============================================
Additionally, I think MTJ should work kind of like Maven
(http://maven.apache.org).
One should download and install a 'skeleton' of the development
environment...enough to do some things, but requiring more pieces via
web services to do anything of any real substance.
For example, a 'project' XML-based file could be generated (or manually
created, if one would want to do that) automatically by the initial
'skeleton' MTJ that one downloads, installs and configures. Once the
configuration part is done by the developer, he goes to generate the
project. A 'central' server (farm?) is checked for what the developer
needs for the particular project, as defined by the initial
configuration it reads (the aforementioned 'project' XML-based file).
MTJ downloads what it needs. The definitions of what is needed are
specified in the XML file.
Libraries required for groups of device types (or individual device
types in some cases) may be offered by various companies and
organizations, so the library providers should be configurable. If the
developer isn't really concerned with which provider is used, more
'generic' libraries can be downloaded by default.
I think the bulk of the intelligence for this "downloading of what is
needed for a particular project" should be generated by the MTJ
skeleton. As little intelligence as possible should be on the server-side.
Comments?
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #6749 is a reply to message #5269] |
Thu, 17 November 2005 22:55 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
User Scenarios
=======================================
Add Devices
===========
Craig...is the goal of this "Add Devices" user scenario to bring the
physical devices themselves (physically) into the arena of the MTJ
development environment?
If the devices are NOT to be brought into the arena of the MTJ
development environment, my thoughts on this are:
1/ User opens Device Management section of workbench preferences
2/ User chooses to add new devices
3/ Make MTJ such that the developer has the choice of updating MTJ's
knowledge of possible devices. If he/she doesn't think this list of
devices needs updating (i.e. he or she knows that the info for the
selected devices is current), this step can be skipped. Otherwise, MTJ
contacts a 'central' server and updates itself. This 'updating' of MTJ's
current 'general knowledge' about things like current supported devices,
etc. should be possible from the main menu, as well.
4/ MTJ populates device list
5/ User chooses target devices for the current project
6/ Target device information is generated in 'project' XML-based file.
If the physical devices themselves are to be brought into the MTJ
development environment arena, my thoughts on this are the same as Craig's.
Create Mobile Project
=====================
My thoughts on this are:
The "Add Devices" scenario is one of the first steps in this "Create
Mobile Project" scenario.
Let's say, one first adds devices to the project. Based on the target
devices added to the project, pre-defined device information is embedded
into the 'project' XML-based file that MTJ generates.
A bunch of generic project information is also embedded into the
XML-based 'project' file, some of which is in every 'project' XML-based
file. Based on all the project info that ends up in the XML-based
'project' file, a 'central' server is contacted and necessary libraries
(and whatever else is needed) for the project are downloaded to MTJ, as
described in the post previous to this one.
Remove Devices
==============
Agree with Craig's scenario.
I think that if devices were only allowed to be removed from particular
projects, then there'd be no need to worry about what happens to
projects associated with the removed device. If no devices in a
particular project are left, then the user is prompted to approve the
deletion of the entire project, i.e. when the project is attempted to be
closed and there are no devices associated with it.
The way most of the remaining scenarios could work are dependent on
whether this MTJ <-> 'central' server concept I wrote of earlier is
adopted/feasible or not.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #6756 is a reply to message #6742] |
Fri, 18 November 2005 00:31 |
| Eclipse User |
|
|
|
Originally posted by: seterajunk.charter.net
>
>
> Device/Code/Resource/Configuration Management
> =============================================
> Additionally, I think MTJ should work kind of like Maven
> (http://maven.apache.org).
>
> One should download and install a 'skeleton' of the development
> environment...enough to do some things, but requiring more pieces via
> web services to do anything of any real substance.
>
I guess I'm not quite sure about how Maven fits. I haven't spent any
real time looking at Maven. I do know that Eclipse has its plugin model
that can/should be used for some of this. I also believe that the WTP
project has proposed some sort of a repository from which specific
functionality can be downloaded "on the fly". In some ways this seems
like it should be something the Eclipse Update Manager handles to me.
|
|
|
| Re: Device Fragmentation Use Cases [message #6762 is a reply to message #6749] |
Fri, 18 November 2005 00:34 |
| Eclipse User |
|
|
|
Originally posted by: seterajunk.charter.net
>
>
> User Scenarios
> =======================================
> Add Devices
> ===========
> Craig...is the goal of this "Add Devices" user scenario to bring the
> physical devices themselves (physically) into the arena of the MTJ
> development environment?
>
Not really. I guess I'm just saying that MTJ should operate at a device
level. All of the wireless toolkits define a set of devices that they
can emulate. Those devices have a set of associated libraries, security
domains and the like. Adding a device should import all of this
information and make it available for use in creating and manipulating a
project.
One example of this is that the SonyEricsson toolkit actually has UEI
devices that allow for on-device-debugging. By reusing their
functionality, MTJ should be able to do on-device-debugging of these
emulators automatically.
|
|
|
| Re: Device Fragmentation Use Cases [message #6769 is a reply to message #5269] |
Fri, 18 November 2005 12:38 |
| Eclipse User |
|
|
|
Originally posted by: arto.laurila.nomail.nokia.com
Hi!
Yes, I also have read your earlier post and had some discussions around
other persons.
As thinking the mobile device fragmentation in generally, there are several
things that affect to the development:
- The mobile devices different physical characteristics (e.g.
display resolution, -size, buttons)
- Processing power and memory
- Differences in the OS, API and JVM implementations
Also there are variations in the API area:
- Different Symbian OS versions and other mobile OS versions
- J2ME profiles and configurations in CLDC and CDC area (CLDC
1.0/1.1 and MIDP 1.0/2.0, J2ME OSGi, etc)
- Bluetooth, 3D, Multimedia, Web Services optional API's
- Proprietary APIs from device manufacturers and operators
In addition to this, there are more
- Requirements from operators and mobile markets
- Localization, internationalization, branding, billing, etc.
- New devices and APIs are published frequently.
=> End result for this is that e.g. two months mobile project may require
double time for porting work
To start to solve this, I see two main problem areas:
- The different configurations and assets they require
(Varying devices X different assets X operator reqs = ~amount of
configurations)
- The porting work to these different configurations
The reference build is tested / modified against different
configurations
As the current fragmentation solutions focus in source code pre-processing,
which certainly can solve some cases,
but lacks the extendibility to the all aspects in the problem area. I
haven't got anything against the pre-processing,
but I'd like to say that it is not the only solution, but one of them.
To try to answer that what could MTJ help in this area, probably there are
some issues in the configuration area that
we could try to solve (or make easier).
One solution is to enable such device management that it supports following
metadata:
- Devices different physical characteristics
- J2ME profiles and configurations CLDC and CDC area
- Bluetooth, 3D, Multimedia, Web Services optional API's
- Proprietary APIs from device manufacturers and operators
- Localizations, internationalization
Also interesting would be to add support to:
- Branding (mainly UI related issues)
- Adding an integrated mobile Java testing tool , which can be
extended to different assets in this area
The device management could enable grouping devices with some configuration
criteria based on this metadata
and that grouping could be used e.g. in the packaging/building process.
And we could use the metadata with the Ant, preprocessing, packaging,
building, branding, localization, etc.
As starting point, the preprocessing is fine but we have also to see the big
picture.
Br. Art
"Craig Setera" <csetera@spss.com> wrote in message
news:dli0fo$n2a$1@news.eclipse.org...
>I haven't seen any mention of the use cases I described for managing device
>fragmentation. Has anyone had a chance to look at these from my earlier
>post? If not, do I need to post them again? I recognize they probably are
>not going to be 1st priority use cases, but it seems to me that that
>functionality should probably rank above many of the current 3rd and 4th
>priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
|
|
|
| Re: Device Fragmentation Use Cases [message #6776 is a reply to message #6769] |
Fri, 18 November 2005 13:14 |
| Eclipse User |
|
|
|
Originally posted by: csetera.spss.com
Arto Laurila wrote:
> Hi!
>
> Yes, I also have read your earlier post and had some discussions around
> other persons.
>
> As thinking the mobile device fragmentation in generally, there are several
> things that affect to the development:
> - The mobile devices different physical characteristics (e.g.
> display resolution, -size, buttons)
> - Processing power and memory
> - Differences in the OS, API and JVM implementations
>
> Also there are variations in the API area:
> - Different Symbian OS versions and other mobile OS versions
> - J2ME profiles and configurations in CLDC and CDC area (CLDC
> 1.0/1.1 and MIDP 1.0/2.0, J2ME OSGi, etc)
> - Bluetooth, 3D, Multimedia, Web Services optional API's
> - Proprietary APIs from device manufacturers and operators
>
> In addition to this, there are more
> - Requirements from operators and mobile markets
> - Localization, internationalization, branding, billing, etc.
> - New devices and APIs are published frequently.
>
> => End result for this is that e.g. two months mobile project may require
> double time for porting work
>
> To start to solve this, I see two main problem areas:
> - The different configurations and assets they require
> (Varying devices X different assets X operator reqs = ~amount of
> configurations)
>
> - The porting work to these different configurations
> The reference build is tested / modified against different
> configurations
>
> As the current fragmentation solutions focus in source code pre-processing,
> which certainly can solve some cases,
> but lacks the extendibility to the all aspects in the problem area. I
> haven't got anything against the pre-processing,
> but I'd like to say that it is not the only solution, but one of them.
>
> To try to answer that what could MTJ help in this area, probably there are
> some issues in the configuration area that
> we could try to solve (or make easier).
>
> One solution is to enable such device management that it supports following
> metadata:
> - Devices different physical characteristics
> - J2ME profiles and configurations CLDC and CDC area
> - Bluetooth, 3D, Multimedia, Web Services optional API's
> - Proprietary APIs from device manufacturers and operators
> - Localizations, internationalization
>
> Also interesting would be to add support to:
> - Branding (mainly UI related issues)
> - Adding an integrated mobile Java testing tool , which can be
> extended to different assets in this area
>
> The device management could enable grouping devices with some configuration
> criteria based on this metadata
> and that grouping could be used e.g. in the packaging/building process.
> And we could use the metadata with the Ant, preprocessing, packaging,
> building, branding, localization, etc.
>
> As starting point, the preprocessing is fine but we have also to see the big
> picture.
>
I agree with this sentiment. Preprocessing is just one part in the
larger picture. As you say, configuration management was also a strong
theme in my original document.
|
|
|
| Re: Device Fragmentation Use Cases [message #6783 is a reply to message #6776] |
Fri, 18 November 2005 16:00 |
| Eclipse User |
|
|
|
Originally posted by: thomas.bailey.sonyericsson.com
I like the meta group thinking - creation of virtual groups of devices
with similar characteristics then, taking preprocessing as first step,
association of "ifdefs" to group names perhaps.
|
|
|
| Re: Device Fragmentation Use Cases [message #6790 is a reply to message #6756] |
Fri, 18 November 2005 19:20 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> Device/Code/Resource/Configuration Management
>> =============================================
>> Additionally, I think MTJ should work kind of like Maven
>> (http://maven.apache.org).
>>
>> One should download and install a 'skeleton' of the development
>> environment...enough to do some things, but requiring more pieces via
>> web services to do anything of any real substance.
>>
>
> I guess I'm not quite sure about how Maven fits. I haven't spent any
> real time looking at Maven. I do know that Eclipse has its plugin model
> that can/should be used for some of this. I also believe that the WTP
> project has proposed some sort of a repository from which specific
> functionality can be downloaded "on the fly". In some ways this seems
> like it should be something the Eclipse Update Manager handles to me.
Hi Craig,
Yes, the Eclipse Update Manager functionality could very well handle
this kind of updating, but I think if the updating was handled there, it
would currently have to be all 'manual' updating, right?
What do you think of this "on the fly" kind of "MTJ <-> web service"
communication that I mentioned, where MTJ is initially downloaded by the
developers as a 'skeleton' and, depending on the project that is
configured (i.e. a 'central' server reads an XML file that gets
generated when the developer configures his/her project), MTJ gets
libraries/security domains/etc downloaded to it on an as-needed basis??
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #6796 is a reply to message #6762] |
Fri, 18 November 2005 19:41 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> User Scenarios
>> =======================================
>> Add Devices
>> ===========
>> Craig...is the goal of this "Add Devices" user scenario to bring the
>> physical devices themselves (physically) into the arena of the MTJ
>> development environment?
>>
>
> Not really. I guess I'm just saying that MTJ should operate at a device
> level. All of the wireless toolkits define a set of devices that they
> can emulate. Those devices have a set of associated libraries, security
> domains and the like. Adding a device should import all of this
> information and make it available for use in creating and manipulating a
> project.
>
> One example of this is that the SonyEricsson toolkit actually has UEI
> devices that allow for on-device-debugging. By reusing their
> functionality, MTJ should be able to do on-device-debugging of these
> emulators automatically.
Hi Craig,
Ok, then what is this in the "Add Devices" scenario about devices being
"discovered" on a hard drive? Is something searching the hard drive for
a 'real' device or is it searching for something else like directories
with certain identifying characteristics or ???
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #6811 is a reply to message #6783] |
Sat, 19 November 2005 22:40 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Thomas Bailey wrote:
> I like the meta group thinking - creation of virtual groups of devices
> with similar characteristics then, taking preprocessing as first step,
> association of "ifdefs" to group names perhaps.
Yes, agree.
As also Craig wrote earlier, it would be useful to have a model, that
enables us to serve the device management, deployment, emulators,
building, etc.
We could model the devices as an object (object tree) that would be
populated with the actual device / emulator properties. And there could
be virtual groups of devices that we could use against e.g.
pre-processing, deployment, etc.
This kind of metadata management could serve the mobile developers quite
well to manage against the device fragmentation.
|
|
|
| Re: Device Fragmentation Use Cases [message #6818 is a reply to message #6790] |
Sun, 20 November 2005 19:20 |
| Eclipse User |
|
|
|
Originally posted by: seterajunk.charter.net
>
> Yes, the Eclipse Update Manager functionality could very well handle
> this kind of updating, but I think if the updating was handled there, it
> would currently have to be all 'manual' updating, right?
>
The Update Manager has an API that can be used to do anything
programmatically that can be done through the user interface.
> What do you think of this "on the fly" kind of "MTJ <-> web service"
> communication that I mentioned, where MTJ is initially downloaded by the
> developers as a 'skeleton' and, depending on the project that is
> configured (i.e. a 'central' server reads an XML file that gets
> generated when the developer configures his/her project), MTJ gets
> libraries/security domains/etc downloaded to it on an as-needed basis??
>
> :Steven
I think something like this would be useful, as long as it isn't the
only option. For instance, I would hate to be on a plane somewhere and
not have the stuff I needed because I couldn't download it ahead of
time. This is where I think that using the standard Update Manager
functionality in a slightly different way can work in favor of both options.
If I think of this in terms of downloading the necessary functionality
for a particular device platform, I would guess that is something that
the individual companies would want to host and control. Perhaps some
central registry using the update manager "mirrors" support so that the
functionality can be hosted at Nokia, SonyEricsson, etc. but the user
can go to one central location to access those sites.
Craig
|
|
|
| Re: Device Fragmentation Use Cases [message #6825 is a reply to message #6796] |
Sun, 20 November 2005 19:33 |
| Eclipse User |
|
|
|
Originally posted by: seterajunk.charter.net
>
>
> Hi Craig,
>
> Ok, then what is this in the "Add Devices" scenario about devices being
> "discovered" on a hard drive? Is something searching the hard drive for
> a 'real' device or is it searching for something else like directories
> with certain identifying characteristics or ???
>
> :Steven
In my experience with EclipseME, every single toolkit from the different
vendors all act slightly differently. I'm assuming that there is going
to be the need for vendor specific extensions for handling different
toolkits. It really doesn't matter whether or not these are emulators,
on-device debug proxies or something completely different. As long as
they are debuggable using JPDA, MTJ should be able to interface with them.
The current approach with most of the tools I've seen is to add things
one device at a time. For instance, the user must select the
appropriate "emulator.exe" and that single device is added. This is
ugly, slow and painful for no particularly good reason.
In my mind a better approach is one that works something like the following:
- User chooses c:\toolkits drive as the location to import from
- User chooses a recursive search or not
- If a recursive search is not requested, the current directory is
provided to each import extension to see if that extension
is the "owner". If so, the extension claims that directory
and does the right thing. For a UEI emulator extension, the
emulator.exe would be consulted for the information. Other
extensions would do things based on their own rules, such as
Siemens/BenQ consulting the registry.
- If a recursive search is requested, the above steps are performed
for the user selected directory and all subdirectories. In
this case, the system may discover many different types of
toolkits and emulators all based on the registered extensions.
The user is then prompted with the discovered toolkit emulators
and allowed to choose the emulators to actually import.
The key things to take away from this in my mind are:
- The user should not have to specify each emulator one by one. Most
users are going to have a large number of emulators installed
to deal with many platforms.
- The ability to recognize and configure emulators need to be
extensible because the different toolkits have different rules.
EclipseME has a start of some of this, but currently doesn't go
as far as I would like it to go. This is on the list for
future development on EclipseME.
Hope this clarifies things.
Craig
|
|
|
| Re: Device Fragmentation Use Cases [message #8644 is a reply to message #6825] |
Mon, 21 November 2005 16:35 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> Hi Craig,
>>
>> Ok, then what is this in the "Add Devices" scenario about devices
>> being "discovered" on a hard drive? Is something searching the hard
>> drive for a 'real' device or is it searching for something else like
>> directories with certain identifying characteristics or ???
>>
>> :Steven
>
>
> In my experience with EclipseME, every single toolkit from the different
> vendors all act slightly differently. I'm assuming that there is going
> to be the need for vendor specific extensions for handling different
> toolkits. It really doesn't matter whether or not these are emulators,
> on-device debug proxies or something completely different. As long as
> they are debuggable using JPDA, MTJ should be able to interface with them.
>
> The current approach with most of the tools I've seen is to add things
> one device at a time. For instance, the user must select the
> appropriate "emulator.exe" and that single device is added. This is
> ugly, slow and painful for no particularly good reason.
>
> In my mind a better approach is one that works something like the
> following:
> - User chooses c:\toolkits drive as the location to import from
> - User chooses a recursive search or not
> - If a recursive search is not requested, the current directory is
> provided to each import extension to see if that extension
> is the "owner". If so, the extension claims that directory
> and does the right thing. For a UEI emulator extension, the
> emulator.exe would be consulted for the information. Other
> extensions would do things based on their own rules, such as
> Siemens/BenQ consulting the registry.
> - If a recursive search is requested, the above steps are performed
> for the user selected directory and all subdirectories. In
> this case, the system may discover many different types of
> toolkits and emulators all based on the registered extensions.
> The user is then prompted with the discovered toolkit emulators
> and allowed to choose the emulators to actually import.
>
> The key things to take away from this in my mind are:
> - The user should not have to specify each emulator one by one. Most
> users are going to have a large number of emulators installed
> to deal with many platforms.
> - The ability to recognize and configure emulators need to be
> extensible because the different toolkits have different rules.
> EclipseME has a start of some of this, but currently doesn't go
> as far as I would like it to go. This is on the list for
> future development on EclipseME.
>
> Hope this clarifies things.
> Craig
Hi Craig,
Yes, the clarification is highly appreciated. Thank you!
And I agree with you on this.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #8655 is a reply to message #6818] |
Mon, 21 November 2005 16:57 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>> Yes, the Eclipse Update Manager functionality could very well handle
>> this kind of updating, but I think if the updating was handled there,
>> it would currently have to be all 'manual' updating, right?
>>
> The Update Manager has an API that can be used to do anything
> programmatically that can be done through the user interface.
>
>> What do you think of this "on the fly" kind of "MTJ <-> web service"
>> communication that I mentioned, where MTJ is initially downloaded by
>> the developers as a 'skeleton' and, depending on the project that is
>> configured (i.e. a 'central' server reads an XML file that gets
>> generated when the developer configures his/her project), MTJ gets
>> libraries/security domains/etc downloaded to it on an as-needed basis??
>>
>> :Steven
>
>
> I think something like this would be useful, as long as it isn't the
> only option. For instance, I would hate to be on a plane somewhere and
> not have the stuff I needed because I couldn't download it ahead of
> time. This is where I think that using the standard Update Manager
> functionality in a slightly different way can work in favor of both
> options.
>
> If I think of this in terms of downloading the necessary functionality
> for a particular device platform, I would guess that is something that
> the individual companies would want to host and control. Perhaps some
> central registry using the update manager "mirrors" support so that the
> functionality can be hosted at Nokia, SonyEricsson, etc. but the user
> can go to one central location to access those sites.
>
> Craig
Hi Craig,
Once again, thanks for your very helpful input.
I agree, optionality (<- is there such a word?) would be necessary.
I see that Eclipse Update Manager can be used, which is good.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562173 is a reply to message #5269] |
Thu, 17 November 2005 18:24 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
Hi Craig & all,
Device Management
=================
I think making the individual devices the 'basis' of a defined project
is a good idea. I think lots of work would have to go into creating
pre-defined (templated) device definitions for the developers. A
tutorial on creating these definitions would be very useful for the
developers. A core set of device libraries should be made available and
these libraries should be pre-defined in the various templated device
profiles.
Perhaps, in some cases, it would be sufficient to have groups of devices
sort of bundled together under a more generalized 'umbrella' of
definitions/libraries, with the option of increasing device-specific
granularity via further definition/configuration. Of course, a tutorial
on how to do this (including examples) would be very useful for the
developers.
Code Management
===============
I agree with what you've written here, Craig. The 3 bullet-point summary
sums it all up. It would be nice if some kind of pre-defined templates
for code management purposes were also available for the developers so
they could see what has to be done/defined/configured in order to
implement the device-based code management.
Resource Management
===================
Agree completely. Again, templates and examples.
I think resource management and code management could be made so similar
that the only real difference would be folder names (src vs. res??).
Configuration Management
=======================
Yes, I think that a layered approach, where each layer has successively
deeper and deeper perspectives on project-based particulars (ultimately
totally based on the particular device differences themselves) would be
necessary. The developers would probably prefer to use a "top-down"
approach in defining their projects at first, but perhaps a "bottom-up"
approach would be preferrable as the environment is mastered.
The pre-defined development (tutorial) of 'small', 'medium' and 'large'
project definitions and configurations would be very useful to the
developers.
Perhaps different pre-defined environments could be split into two major
partitions, starting at the 'upper' layers with device differences
including things like operating system, functionality similarities and
device capabilities, eventually working down to the 'lower' layers where
very device-specific differences can be defined, etc. ??
Build Support
=============
Very much so, backend J2EE-based server applications should be
integratable with the mobile applications. Ant build scripts would seem
the logical choice here. Individual configuration definition flexibility
is definitely needed here.
Could Maven be used anywhere in here??
I will comment on the User Scenarios in a separate message.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562227 is a reply to message #5269] |
Thu, 17 November 2005 22:14 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
Device/Code/Resource/Configuration Management
=============================================
Additionally, I think MTJ should work kind of like Maven
(http://maven.apache.org).
One should download and install a 'skeleton' of the development
environment...enough to do some things, but requiring more pieces via
web services to do anything of any real substance.
For example, a 'project' XML-based file could be generated (or manually
created, if one would want to do that) automatically by the initial
'skeleton' MTJ that one downloads, installs and configures. Once the
configuration part is done by the developer, he goes to generate the
project. A 'central' server (farm?) is checked for what the developer
needs for the particular project, as defined by the initial
configuration it reads (the aforementioned 'project' XML-based file).
MTJ downloads what it needs. The definitions of what is needed are
specified in the XML file.
Libraries required for groups of device types (or individual device
types in some cases) may be offered by various companies and
organizations, so the library providers should be configurable. If the
developer isn't really concerned with which provider is used, more
'generic' libraries can be downloaded by default.
I think the bulk of the intelligence for this "downloading of what is
needed for a particular project" should be generated by the MTJ
skeleton. As little intelligence as possible should be on the server-side.
Comments?
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562250 is a reply to message #5269] |
Thu, 17 November 2005 22:55 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
> I haven't seen any mention of the use cases I described for managing
> device fragmentation. Has anyone had a chance to look at these from my
> earlier post? If not, do I need to post them again? I recognize they
> probably are not going to be 1st priority use cases, but it seems to me
> that that functionality should probably rank above many of the current
> 3rd and 4th priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
User Scenarios
=======================================
Add Devices
===========
Craig...is the goal of this "Add Devices" user scenario to bring the
physical devices themselves (physically) into the arena of the MTJ
development environment?
If the devices are NOT to be brought into the arena of the MTJ
development environment, my thoughts on this are:
1/ User opens Device Management section of workbench preferences
2/ User chooses to add new devices
3/ Make MTJ such that the developer has the choice of updating MTJ's
knowledge of possible devices. If he/she doesn't think this list of
devices needs updating (i.e. he or she knows that the info for the
selected devices is current), this step can be skipped. Otherwise, MTJ
contacts a 'central' server and updates itself. This 'updating' of MTJ's
current 'general knowledge' about things like current supported devices,
etc. should be possible from the main menu, as well.
4/ MTJ populates device list
5/ User chooses target devices for the current project
6/ Target device information is generated in 'project' XML-based file.
If the physical devices themselves are to be brought into the MTJ
development environment arena, my thoughts on this are the same as Craig's.
Create Mobile Project
=====================
My thoughts on this are:
The "Add Devices" scenario is one of the first steps in this "Create
Mobile Project" scenario.
Let's say, one first adds devices to the project. Based on the target
devices added to the project, pre-defined device information is embedded
into the 'project' XML-based file that MTJ generates.
A bunch of generic project information is also embedded into the
XML-based 'project' file, some of which is in every 'project' XML-based
file. Based on all the project info that ends up in the XML-based
'project' file, a 'central' server is contacted and necessary libraries
(and whatever else is needed) for the project are downloaded to MTJ, as
described in the post previous to this one.
Remove Devices
==============
Agree with Craig's scenario.
I think that if devices were only allowed to be removed from particular
projects, then there'd be no need to worry about what happens to
projects associated with the removed device. If no devices in a
particular project are left, then the user is prompted to approve the
deletion of the entire project, i.e. when the project is attempted to be
closed and there are no devices associated with it.
The way most of the remaining scenarios could work are dependent on
whether this MTJ <-> 'central' server concept I wrote of earlier is
adopted/feasible or not.
:Steven
|
|
| | |
| Re: Device Fragmentation Use Cases [message #562332 is a reply to message #5269] |
Fri, 18 November 2005 12:38 |
 Arto Laurila
Messages: 32
Registered: July 2009 |
Member |
|
|
Hi!
Yes, I also have read your earlier post and had some discussions around
other persons.
As thinking the mobile device fragmentation in generally, there are several
things that affect to the development:
- The mobile devices different physical characteristics (e.g.
display resolution, -size, buttons)
- Processing power and memory
- Differences in the OS, API and JVM implementations
Also there are variations in the API area:
- Different Symbian OS versions and other mobile OS versions
- J2ME profiles and configurations in CLDC and CDC area (CLDC
1.0/1.1 and MIDP 1.0/2.0, J2ME OSGi, etc)
- Bluetooth, 3D, Multimedia, Web Services optional API's
- Proprietary APIs from device manufacturers and operators
In addition to this, there are more
- Requirements from operators and mobile markets
- Localization, internationalization, branding, billing, etc.
- New devices and APIs are published frequently.
=> End result for this is that e.g. two months mobile project may require
double time for porting work
To start to solve this, I see two main problem areas:
- The different configurations and assets they require
(Varying devices X different assets X operator reqs = ~amount of
configurations)
- The porting work to these different configurations
The reference build is tested / modified against different
configurations
As the current fragmentation solutions focus in source code pre-processing,
which certainly can solve some cases,
but lacks the extendibility to the all aspects in the problem area. I
haven't got anything against the pre-processing,
but I'd like to say that it is not the only solution, but one of them.
To try to answer that what could MTJ help in this area, probably there are
some issues in the configuration area that
we could try to solve (or make easier).
One solution is to enable such device management that it supports following
metadata:
- Devices different physical characteristics
- J2ME profiles and configurations CLDC and CDC area
- Bluetooth, 3D, Multimedia, Web Services optional API's
- Proprietary APIs from device manufacturers and operators
- Localizations, internationalization
Also interesting would be to add support to:
- Branding (mainly UI related issues)
- Adding an integrated mobile Java testing tool , which can be
extended to different assets in this area
The device management could enable grouping devices with some configuration
criteria based on this metadata
and that grouping could be used e.g. in the packaging/building process.
And we could use the metadata with the Ant, preprocessing, packaging,
building, branding, localization, etc.
As starting point, the preprocessing is fine but we have also to see the big
picture.
Br. Art
"Craig Setera" <csetera@spss.com> wrote in message
news:dli0fo$n2a$1@news.eclipse.org...
>I haven't seen any mention of the use cases I described for managing device
>fragmentation. Has anyone had a chance to look at these from my earlier
>post? If not, do I need to post them again? I recognize they probably are
>not going to be 1st priority use cases, but it seems to me that that
>functionality should probably rank above many of the current 3rd and 4th
>priority use cases on the wiki.
>
> Thanks,
> Craig
>
> Lead EclipseME Developer
|
|
|
| Re: Device Fragmentation Use Cases [message #562356 is a reply to message #6769] |
Fri, 18 November 2005 13:14 |
Craig Setera
Messages: 54
Registered: July 2009 |
Member |
|
|
Arto Laurila wrote:
> Hi!
>
> Yes, I also have read your earlier post and had some discussions around
> other persons.
>
> As thinking the mobile device fragmentation in generally, there are several
> things that affect to the development:
> - The mobile devices different physical characteristics (e.g.
> display resolution, -size, buttons)
> - Processing power and memory
> - Differences in the OS, API and JVM implementations
>
> Also there are variations in the API area:
> - Different Symbian OS versions and other mobile OS versions
> - J2ME profiles and configurations in CLDC and CDC area (CLDC
> 1.0/1.1 and MIDP 1.0/2.0, J2ME OSGi, etc)
> - Bluetooth, 3D, Multimedia, Web Services optional API's
> - Proprietary APIs from device manufacturers and operators
>
> In addition to this, there are more
> - Requirements from operators and mobile markets
> - Localization, internationalization, branding, billing, etc.
> - New devices and APIs are published frequently.
>
> => End result for this is that e.g. two months mobile project may require
> double time for porting work
>
> To start to solve this, I see two main problem areas:
> - The different configurations and assets they require
> (Varying devices X different assets X operator reqs = ~amount of
> configurations)
>
> - The porting work to these different configurations
> The reference build is tested / modified against different
> configurations
>
> As the current fragmentation solutions focus in source code pre-processing,
> which certainly can solve some cases,
> but lacks the extendibility to the all aspects in the problem area. I
> haven't got anything against the pre-processing,
> but I'd like to say that it is not the only solution, but one of them.
>
> To try to answer that what could MTJ help in this area, probably there are
> some issues in the configuration area that
> we could try to solve (or make easier).
>
> One solution is to enable such device management that it supports following
> metadata:
> - Devices different physical characteristics
> - J2ME profiles and configurations CLDC and CDC area
> - Bluetooth, 3D, Multimedia, Web Services optional API's
> - Proprietary APIs from device manufacturers and operators
> - Localizations, internationalization
>
> Also interesting would be to add support to:
> - Branding (mainly UI related issues)
> - Adding an integrated mobile Java testing tool , which can be
> extended to different assets in this area
>
> The device management could enable grouping devices with some configuration
> criteria based on this metadata
> and that grouping could be used e.g. in the packaging/building process.
> And we could use the metadata with the Ant, preprocessing, packaging,
> building, branding, localization, etc.
>
> As starting point, the preprocessing is fine but we have also to see the big
> picture.
>
I agree with this sentiment. Preprocessing is just one part in the
larger picture. As you say, configuration management was also a strong
theme in my original document.
|
|
|
| Re: Device Fragmentation Use Cases [message #562381 is a reply to message #6776] |
Fri, 18 November 2005 16:00 |
| Eclipse User |
|
|
|
Originally posted by: thomas.bailey.sonyericsson.com
I like the meta group thinking - creation of virtual groups of devices
with similar characteristics then, taking preprocessing as first step,
association of "ifdefs" to group names perhaps.
|
|
|
| Re: Device Fragmentation Use Cases [message #562406 is a reply to message #6756] |
Fri, 18 November 2005 19:20 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> Device/Code/Resource/Configuration Management
>> =============================================
>> Additionally, I think MTJ should work kind of like Maven
>> (http://maven.apache.org).
>>
>> One should download and install a 'skeleton' of the development
>> environment...enough to do some things, but requiring more pieces via
>> web services to do anything of any real substance.
>>
>
> I guess I'm not quite sure about how Maven fits. I haven't spent any
> real time looking at Maven. I do know that Eclipse has its plugin model
> that can/should be used for some of this. I also believe that the WTP
> project has proposed some sort of a repository from which specific
> functionality can be downloaded "on the fly". In some ways this seems
> like it should be something the Eclipse Update Manager handles to me.
Hi Craig,
Yes, the Eclipse Update Manager functionality could very well handle
this kind of updating, but I think if the updating was handled there, it
would currently have to be all 'manual' updating, right?
What do you think of this "on the fly" kind of "MTJ <-> web service"
communication that I mentioned, where MTJ is initially downloaded by the
developers as a 'skeleton' and, depending on the project that is
configured (i.e. a 'central' server reads an XML file that gets
generated when the developer configures his/her project), MTJ gets
libraries/security domains/etc downloaded to it on an as-needed basis??
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562429 is a reply to message #6762] |
Fri, 18 November 2005 19:41 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> User Scenarios
>> =======================================
>> Add Devices
>> ===========
>> Craig...is the goal of this "Add Devices" user scenario to bring the
>> physical devices themselves (physically) into the arena of the MTJ
>> development environment?
>>
>
> Not really. I guess I'm just saying that MTJ should operate at a device
> level. All of the wireless toolkits define a set of devices that they
> can emulate. Those devices have a set of associated libraries, security
> domains and the like. Adding a device should import all of this
> information and make it available for use in creating and manipulating a
> project.
>
> One example of this is that the SonyEricsson toolkit actually has UEI
> devices that allow for on-device-debugging. By reusing their
> functionality, MTJ should be able to do on-device-debugging of these
> emulators automatically.
Hi Craig,
Ok, then what is this in the "Add Devices" scenario about devices being
"discovered" on a hard drive? Is something searching the hard drive for
a 'real' device or is it searching for something else like directories
with certain identifying characteristics or ???
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562480 is a reply to message #6783] |
Sat, 19 November 2005 22:40 |
Arto Laurila
Messages: 32
Registered: July 2009 |
Member |
|
|
Thomas Bailey wrote:
> I like the meta group thinking - creation of virtual groups of devices
> with similar characteristics then, taking preprocessing as first step,
> association of "ifdefs" to group names perhaps.
Yes, agree.
As also Craig wrote earlier, it would be useful to have a model, that
enables us to serve the device management, deployment, emulators,
building, etc.
We could model the devices as an object (object tree) that would be
populated with the actual device / emulator properties. And there could
be virtual groups of devices that we could use against e.g.
pre-processing, deployment, etc.
This kind of metadata management could serve the mobile developers quite
well to manage against the device fragmentation.
|
|
|
| Re: Device Fragmentation Use Cases [message #562505 is a reply to message #6790] |
Sun, 20 November 2005 19:20 |
Craig Setera
Messages: 54
Registered: July 2009 |
Member |
|
|
>
> Yes, the Eclipse Update Manager functionality could very well handle
> this kind of updating, but I think if the updating was handled there, it
> would currently have to be all 'manual' updating, right?
>
The Update Manager has an API that can be used to do anything
programmatically that can be done through the user interface.
> What do you think of this "on the fly" kind of "MTJ <-> web service"
> communication that I mentioned, where MTJ is initially downloaded by the
> developers as a 'skeleton' and, depending on the project that is
> configured (i.e. a 'central' server reads an XML file that gets
> generated when the developer configures his/her project), MTJ gets
> libraries/security domains/etc downloaded to it on an as-needed basis??
>
> :Steven
I think something like this would be useful, as long as it isn't the
only option. For instance, I would hate to be on a plane somewhere and
not have the stuff I needed because I couldn't download it ahead of
time. This is where I think that using the standard Update Manager
functionality in a slightly different way can work in favor of both options.
If I think of this in terms of downloading the necessary functionality
for a particular device platform, I would guess that is something that
the individual companies would want to host and control. Perhaps some
central registry using the update manager "mirrors" support so that the
functionality can be hosted at Nokia, SonyEricsson, etc. but the user
can go to one central location to access those sites.
Craig
|
|
|
| Re: Device Fragmentation Use Cases [message #562537 is a reply to message #6796] |
Sun, 20 November 2005 19:33 |
Craig Setera
Messages: 54
Registered: July 2009 |
Member |
|
|
>
>
> Hi Craig,
>
> Ok, then what is this in the "Add Devices" scenario about devices being
> "discovered" on a hard drive? Is something searching the hard drive for
> a 'real' device or is it searching for something else like directories
> with certain identifying characteristics or ???
>
> :Steven
In my experience with EclipseME, every single toolkit from the different
vendors all act slightly differently. I'm assuming that there is going
to be the need for vendor specific extensions for handling different
toolkits. It really doesn't matter whether or not these are emulators,
on-device debug proxies or something completely different. As long as
they are debuggable using JPDA, MTJ should be able to interface with them.
The current approach with most of the tools I've seen is to add things
one device at a time. For instance, the user must select the
appropriate "emulator.exe" and that single device is added. This is
ugly, slow and painful for no particularly good reason.
In my mind a better approach is one that works something like the following:
- User chooses c:\toolkits drive as the location to import from
- User chooses a recursive search or not
- If a recursive search is not requested, the current directory is
provided to each import extension to see if that extension
is the "owner". If so, the extension claims that directory
and does the right thing. For a UEI emulator extension, the
emulator.exe would be consulted for the information. Other
extensions would do things based on their own rules, such as
Siemens/BenQ consulting the registry.
- If a recursive search is requested, the above steps are performed
for the user selected directory and all subdirectories. In
this case, the system may discover many different types of
toolkits and emulators all based on the registered extensions.
The user is then prompted with the discovered toolkit emulators
and allowed to choose the emulators to actually import.
The key things to take away from this in my mind are:
- The user should not have to specify each emulator one by one. Most
users are going to have a large number of emulators installed
to deal with many platforms.
- The ability to recognize and configure emulators need to be
extensible because the different toolkits have different rules.
EclipseME has a start of some of this, but currently doesn't go
as far as I would like it to go. This is on the list for
future development on EclipseME.
Hope this clarifies things.
Craig
|
|
|
| Re: Device Fragmentation Use Cases [message #562590 is a reply to message #6825] |
Mon, 21 November 2005 16:35 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>>
>> Hi Craig,
>>
>> Ok, then what is this in the "Add Devices" scenario about devices
>> being "discovered" on a hard drive? Is something searching the hard
>> drive for a 'real' device or is it searching for something else like
>> directories with certain identifying characteristics or ???
>>
>> :Steven
>
>
> In my experience with EclipseME, every single toolkit from the different
> vendors all act slightly differently. I'm assuming that there is going
> to be the need for vendor specific extensions for handling different
> toolkits. It really doesn't matter whether or not these are emulators,
> on-device debug proxies or something completely different. As long as
> they are debuggable using JPDA, MTJ should be able to interface with them.
>
> The current approach with most of the tools I've seen is to add things
> one device at a time. For instance, the user must select the
> appropriate "emulator.exe" and that single device is added. This is
> ugly, slow and painful for no particularly good reason.
>
> In my mind a better approach is one that works something like the
> following:
> - User chooses c:\toolkits drive as the location to import from
> - User chooses a recursive search or not
> - If a recursive search is not requested, the current directory is
> provided to each import extension to see if that extension
> is the "owner". If so, the extension claims that directory
> and does the right thing. For a UEI emulator extension, the
> emulator.exe would be consulted for the information. Other
> extensions would do things based on their own rules, such as
> Siemens/BenQ consulting the registry.
> - If a recursive search is requested, the above steps are performed
> for the user selected directory and all subdirectories. In
> this case, the system may discover many different types of
> toolkits and emulators all based on the registered extensions.
> The user is then prompted with the discovered toolkit emulators
> and allowed to choose the emulators to actually import.
>
> The key things to take away from this in my mind are:
> - The user should not have to specify each emulator one by one. Most
> users are going to have a large number of emulators installed
> to deal with many platforms.
> - The ability to recognize and configure emulators need to be
> extensible because the different toolkits have different rules.
> EclipseME has a start of some of this, but currently doesn't go
> as far as I would like it to go. This is on the list for
> future development on EclipseME.
>
> Hope this clarifies things.
> Craig
Hi Craig,
Yes, the clarification is highly appreciated. Thank you!
And I agree with you on this.
:Steven
|
|
|
| Re: Device Fragmentation Use Cases [message #562608 is a reply to message #6818] |
Mon, 21 November 2005 16:57 |
| Eclipse User |
|
|
|
Originally posted by: steven.t.novakovich.nokia.com
Craig Setera wrote:
>>
>> Yes, the Eclipse Update Manager functionality could very well handle
>> this kind of updating, but I think if the updating was handled there,
>> it would currently have to be all 'manual' updating, right?
>>
> The Update Manager has an API that can be used to do anything
> programmatically that can be done through the user interface.
>
>> What do you think of this "on the fly" kind of "MTJ <-> web service"
>> communication that I mentioned, where MTJ is initially downloaded by
>> the developers as a 'skeleton' and, depending on the project that is
>> configured (i.e. a 'central' server reads an XML file that gets
>> generated when the developer configures his/her project), MTJ gets
>> libraries/security domains/etc downloaded to it on an as-needed basis??
>>
>> :Steven
>
>
> I think something like this would be useful, as long as it isn't the
> only option. For instance, I would hate to be on a plane somewhere and
> not have the stuff I needed because I couldn't download it ahead of
> time. This is where I think that using the standard Update Manager
> functionality in a slightly different way can work in favor of both
> options.
>
> If I think of this in terms of downloading the necessary functionality
> for a particular device platform, I would guess that is something that
> the individual companies would want to host and control. Perhaps some
> central registry using the update manager "mirrors" support so that the
> functionality can be hosted at Nokia, SonyEricsson, etc. but the user
> can go to one central location to access those sites.
>
> Craig
Hi Craig,
Once again, thanks for your very helpful input.
I agree, optionality (<- is there such a word?) would be necessary.
I see that Eclipse Update Manager can be used, which is good.
:Steven
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:31:35 GMT 2024
Powered by FUDForum. Page generated in 0.04723 seconds |
] 
Search
Help
Register
Login
Home
