Mobile Minutes 2008-09-04
From MemberWiki
Contents |
Attendees
- David Boloker, IBM (co-chair)
- Jon Ferraiolo, IBM
- Paddy Byers, Aplix
- John Hardi, Motricity
- Rotan Hanrahan, MobileAware
- Andrew Sledd, Ikivo (co-chair)
- Ian Hay, Orange France-Telecom
- David Pollington, Vodafone
Minutes
OMTP BONDI review
Paddy: I am editor of the architecture document and attended most of the other meetings.
Jon: How baked are the documents and technologies under development at OMTP?
Paddy: My assessment. People are bringing requirements mainly, not always solutions. Closer collaboration with W3C. Better attention to feasibility lately. Ambitious on the time frame. Actually interfaces aren't that difficult, but if you want quality APIs, it will be a challenge to fit within the target timeframe. Regarding architecture and security, good discussion at the requirements level and a good amount of sympathy for our efforts at W3C webapps. Good target to shoot for. But finding a reference implementation that meets all of the goals, particularly quality, will be more challenging. We have been involved in quite intensive work. A lot of buy-in so far. But the ending impact depends on the quality of what we produce.
DavidP: I would agree. A lot of effort from the operators to make it successful. A good set of requirements. Trick is turning the requirements into APIs and reference code.
Jon: Has the reference implementation chosen yet?
DavidP/Paddy: Will be discussed next week in Austin.
Andrew: Is there a push towards things that are already defined and implemented within the industry?
Paddy: Will discuss next week. My view is that there won't be an all or nothing reference implementation. Note that the RI doesn't need to be all open source or all from a single vendor. Of course we don't want a Frankenstein's monster with pieces that don't fit together. Aplix has offered a framework that will allow for independent implementations of the pieces.
Jon: Yes, given your loader research, you seem well-suited for that.
Jon: Regarding the BONDI specs themselves, I am highly positive about what I see so far. I have looked at the specs in depth and read them all. The only major negative I see so far is the ridiculous verbosity of XACML. I have talked to Nick Allott about this and he says that the OMTP participants recognize this and will be exploring approaches to find ways to simplify.
Paddy: Yes, I agree. We found that XACML fit our needs nicely. It allowed us to move forward quickly. But it comes with a huge amount of baggage. Not just its verbosity, but also its generality. For example, you can use arbitrary XPath expressions in the rules. In my opinion, too much for mobile. We aren't sure yet how to address this.
Andrew: Does everyone agree that this needs to be addressed?
Paddy: I do. I think most of the OMTP members think so also. We need some sort of profiling.
Jon: My advice is to use real-life scenarios to help figure out the subsetting. And I mean real-life, and the existing use cases and examples might be too artificial. Therefore, it might be necessary to cycle back on the use cases for a bit in order to best inform the profiling initiative.
Paddy: It is a good thing that we have separated out the security language from the security implementation. For example, the fact that something is signed is not necessarily a requirement for policy.
Rotan: I'm not sure what exactly the problem is with XACML. Two main reasons why a particular XML format isn't suitable. First, potential complexity of human authoring. If there are scenarios where you need to hand-code, then you don't want it to be too complex. Second, complex processing. Sometimes you want to design an XML format to allows for efficient implementation of complex logic.
Jon: XACML has shortcomings on both fronts. I believe it will be hand-coded often and by people with little knowledge of XACML. Also, it has high processing requirements which is bad on devices where you want to preserve the battery.
Paddy: XACML isn't natural for hand-coders.
Jon: Don't mean to bash XACML. Just saying for this scenario it is too verbose and complex.
Paddy: Adapting lock stock and barrel won't work
Jon: But Rotan makes good points
Rotan: Just restating W3C best practices. Need to provide an exact proposal.
Paddy: Had had some discussions with XACML people.
Rotan: I can bring issues to the W3C
Paddy: First we meet next week, then I'll info to you
Jon's review of W3C geolocation
Paddy: Jon's discussion of geoloc could be a big benefit to us
Andrew: How is OMTP and W3C liaison going?
Paddy: Lots of discussions at OMTP but Jon's proposals are more advanced. Would be good to have a style guide
Jon: My overall assessment is that W3C geolocation has reasonable APIs. When I think about how it might be improved, I have a hard time justifying proposed changes. It is clear that for each decision they made they had a reason behind it. I also looked at whether their approaches could be a model for other device APIs and concluded that their approaches can be used for other APIs. One huge benefit to the geolocation work is that it can establish precedent which others can adopt and thereby streamline and accelerate standards development.
Paddy: I agree. Good to abstract those principles into a style guide.
Rotan: Talking about JavaScript APIs or general APIs?
Jon: At OpenAjax, we are focused only on JavaScript.
Rotan: I think it would be good to explicitly say that your comments are only for JS APIs. That will help get favorable attention at W3C. Maybe someone else can define language-neutral APIs.
Paddy: In Java, every API locks because of multithreading. This approach should work with Java. Also, Java is typed. Problem is that the optimal JS API will be different than the optimal Java API.
Jon: OK, I'll start work on an OpenAjax style guide.
DavidP: Makes perfect sense.
Jon: I'll work with Adam Peller, who is on this committee and one of the Dojo experts. We can review it here and with the rest of OpenAjax Alliance.
Paddy: I think this would be really valuable.
W3C
Rotan: W3C MWI will be coming to a close, to be followed by MWI2. Whereas MWI1 wrote specs, MWI2 will focus on workshops on prominent topics, designed for quick turnaround. Maybe there will be an exception with Best Practices and affect of proxies when in the presence of Ajax and other active content. For that, we will be doing a set of guidelines for the industry. Tech Plenary next month. Afterwards, lots of announcements.
Rotan: geolocation WG is still being formed, probably close to completion. Matt Wormer is the organizer.
Jon: Is OMTP looking at DCCI?
Rotan: The request has come in. But need to understand their requirements to make sure we can meet their needs. OMA has a server technology. Then W3C has DCAP and DCCI on browser. All based on UWA ontololgies for compatbility.
Jon: geolocation doesn't have feature feature. Maybe use DCCI for that?
Rotan: Matt in a prior life implemented DCCI before calling map APIs. Only impediment is political.
JF/RH: Maybe DCCI to discover, then call other APIs
Jon: Seems like the winning strategy. Maybe OAA can help by making a recommendation
Rotan: Would be good
Next meeting
Andrew: Jon, can you be ready for a call in 2 weeks?
Jon: DavidP and I will be at a conference on that date.
(discussion)
Decision: Next call on Sept 25 at normal time (9am US-PT)
