At 3GSM in Barcelona, Sun announced it is collaborating with Openwave to integrate Openwave's XML-based MIDAS with Sun's Java ME Technologies to provide open, standards-based tools to deliver rich content for mobile phones. Directions Magazine's Joe Francica interviewed Eric Chu, Senior Director of Sun's Client Systems Group to explore the partnership and other technical developments. Directions
Magazine's Joe Francica interviewed Eric Chu, Senior Director of Sun's
Client Systems Group to determine more information about this
partnership and other technical developments.
Joe Francica (JF): What is the significance of the Sun/Openwave agreement?
Eric Chu (EC): If you look at the mobile handset today, you have primarily two applications environments; on one hand you have the browser environment with applications based on XML or WML and on the other you have people building Java-based applications. And those two worlds are entirely unconnected. So, what we are doing with Openwave is bringing together two worlds to allow, for example, applications to can run across the two application environments. For example, say we want to build a browser-based application to pass data to the Java-based application and vice versa as step one. As step two, we could leverage the W3C’s XML-based Compound Document Framework as part of JSR 290 to bring XML scripting and Java back into the mobile platform and thoroughly integrate them into one environment.
In the mapping world…based on what we are looking at, SVG (Scalable Vector Graphics) is playing a huge role in that type of content. And we want to make sure that SVG is tied in with Java as an underlying programming platform. We think in the 2D world we need an industry standard-based, texture based programming environment based on XML. We also needed something that could easily tie in with the Java programming logic.
JF: Are there any network limitations to driving graphics down to the handset?
EC: It's hard to answer that question in general, because the network limitations and capabilities differ region by region. Obviously in the U.S. we have a tough challenge, whereas in Asia it is less so. We actually do believe that one of the ways to mitigate some of these concerns is to have a powerful client engine in the device. With the notion of the original WAP model, if you wanted to change one bit on the screen, you had to download the entire page. To have a powerful client engine that allows the device to catch data, and to do rendering, and allows the dataset to be sent from the server,and allows the device from there on to present more sophistication to the user – such a client engine would mitigate some of the concerns that you are talking about.
JF: How do you see the implementation with Openwave being used with cellular carriers and is there any uptake with the carriers? Any applications to be launched?
EC: In some ways, part of the reason we are going down this path is because we have been involved with a group called 3G America. About 9 months ago there was a workshop that we held that 3G America helped us to participate in, and we wanted to share with carriers the preliminary 3G America recommendations, and we asked them for feedback in the areas we needed to focus on. From the feedback that we got, if you look at the Java programming process, the features that you find are actually quite rich. The problem that programmers are running into is consistency with the behavior of the device. And the consistency is not limited to only how the application behaves within Java, its also limited by the differences in the hardware, the differences in the performance, and differences in how the Java subsystem interacts with other subsystems in the device. And what they are saying about how the browser and Java interact with each other is not the same across the manufacturer of browsers and that creates a problem for them (the carriers). And that's one of the reasons that we are very much motivated to solve this problem.
JF: You mentioned that we should be more aware of JSR 248. Can you explain why?
EC: We work with a number different industry members to define Java-based standards. JSR 248 is about the next generation of the mobile Java platform. And so these descriptions are coming from Nokia, Vodafone, Motorola, Siemens, Sony-Ericsson, and Cingular…the usual suspects. What this specification document is doing is pulling together the collection of Java technologies that are relevant to the devices targeted for a certain time period. So, for example, in JSR 248, they need to define the Java mobile platform standard for devices in late 2006-2007 time frame. So, the reason why I mentioned this is that location is a big part of the specification. What this means is that we need to that have location capabilities and express those location capabilities in a consistent way to third party developers.
JF: Eric...thanks very much for your time
Joe Francica (JF): What is the significance of the Sun/Openwave agreement?
Eric Chu (EC): If you look at the mobile handset today, you have primarily two applications environments; on one hand you have the browser environment with applications based on XML or WML and on the other you have people building Java-based applications. And those two worlds are entirely unconnected. So, what we are doing with Openwave is bringing together two worlds to allow, for example, applications to can run across the two application environments. For example, say we want to build a browser-based application to pass data to the Java-based application and vice versa as step one. As step two, we could leverage the W3C’s XML-based Compound Document Framework as part of JSR 290 to bring XML scripting and Java back into the mobile platform and thoroughly integrate them into one environment.
In the mapping world…based on what we are looking at, SVG (Scalable Vector Graphics) is playing a huge role in that type of content. And we want to make sure that SVG is tied in with Java as an underlying programming platform. We think in the 2D world we need an industry standard-based, texture based programming environment based on XML. We also needed something that could easily tie in with the Java programming logic.
JF: Are there any network limitations to driving graphics down to the handset?
EC: It's hard to answer that question in general, because the network limitations and capabilities differ region by region. Obviously in the U.S. we have a tough challenge, whereas in Asia it is less so. We actually do believe that one of the ways to mitigate some of these concerns is to have a powerful client engine in the device. With the notion of the original WAP model, if you wanted to change one bit on the screen, you had to download the entire page. To have a powerful client engine that allows the device to catch data, and to do rendering, and allows the dataset to be sent from the server,and allows the device from there on to present more sophistication to the user – such a client engine would mitigate some of the concerns that you are talking about.
JF: How do you see the implementation with Openwave being used with cellular carriers and is there any uptake with the carriers? Any applications to be launched?
EC: In some ways, part of the reason we are going down this path is because we have been involved with a group called 3G America. About 9 months ago there was a workshop that we held that 3G America helped us to participate in, and we wanted to share with carriers the preliminary 3G America recommendations, and we asked them for feedback in the areas we needed to focus on. From the feedback that we got, if you look at the Java programming process, the features that you find are actually quite rich. The problem that programmers are running into is consistency with the behavior of the device. And the consistency is not limited to only how the application behaves within Java, its also limited by the differences in the hardware, the differences in the performance, and differences in how the Java subsystem interacts with other subsystems in the device. And what they are saying about how the browser and Java interact with each other is not the same across the manufacturer of browsers and that creates a problem for them (the carriers). And that's one of the reasons that we are very much motivated to solve this problem.
JF: You mentioned that we should be more aware of JSR 248. Can you explain why?
EC: We work with a number different industry members to define Java-based standards. JSR 248 is about the next generation of the mobile Java platform. And so these descriptions are coming from Nokia, Vodafone, Motorola, Siemens, Sony-Ericsson, and Cingular…the usual suspects. What this specification document is doing is pulling together the collection of Java technologies that are relevant to the devices targeted for a certain time period. So, for example, in JSR 248, they need to define the Java mobile platform standard for devices in late 2006-2007 time frame. So, the reason why I mentioned this is that location is a big part of the specification. What this means is that we need to that have location capabilities and express those location capabilities in a consistent way to third party developers.
JF: Eric...thanks very much for your time
From Our Homepage
Saying Farewell to an Amazing Journey
Communicating with Maps
Is There a GIS Career Ladder?
What does it mean to be geospatially smart? Series
Ways Real Estate and Property Developers Utilize Melissa GeoData for Data-Driven Decisions
Unlocking Value From Daily Satellite Imagery and Insights
Maximizing the Value of Your Address Data with Geo Addressing
How Indoor Mapping Enhances the Security of Smart Buildings
Look Ahead: AI, Location Intelligence and Efficiency
Collaboration Takes on Sea Level Rise & Dynamic Technology Environments
Brownies for Brownfields
Has Everything Been Mapped Already?
How Is Data Literacy Changing in an Artificial Intelligence Landscape
Portfolios for GIS Professionals: More Than Just Maps
How to Create a Distance Matrix in QGIS - A Step-by-Step Guide
7 Ideas for Bringing GIS into the K-12 Classroom
The Geography of Movement