From MemberWiki

URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-03

Contents 1 Attendees 2 Agenda 3 Minutes 3.1 OMTP 3.2 Modularization proposal 3.3 Loader vs no loader 3.4 Next Steps

Attendees

• David Boloker, IBM
• Jon Ferraiolo, IBM
• Andrew Sledd, Ikivo
• Paddy Byers, Aplix
• David Pollington, Vodafone

Agenda

Review the following:

• http://openajax.org/pipermail/mobile/2008q3/000313.html
• http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules
• http://www.openajax.org/member/wiki/OpenAjax_Device_APIs

Minutes

OMTP

Discussion of related OMTP work: They have requirements for security and requirements for interfaces. Plan to do reference implementation (in Ref Impl TF) in parallel with specs (in Arch/Security WG and Interfaces WG). Just yesterday launched a 2-week call for contributions. Will decide how to proceed after seeing contributions. Paddy thinks end-of-year is achievable for both specs and reference implementation, and that there appears to be enough industry commitment, but observes that it is not a goal to be comprehensive.

Arch/Security Group: Dan Applequist is chair, Paddy is vice-chair. Ref Impl TF: Fabio Ricciato of Telecom Italia is chair. Interfaces WG: Daniel Blonna of Telefonica is chair, Magnus of Ericsson is vice-chair.

Discussion of how our work relates to OMTP work. Paddy says that fragmentation won't disappear over night and that it isn't clear when the OMTP APIs will ship natively with devices. Paddy/Jon mention that there will be a period when it makes sense to have an Ajax library that addresses platform differences. DavidP/Jon mention that it is good to get the JavaScript perspective as represented by OpenAjax. Jon/Paddy/DavidP mention that our contributions are likely to be complementary rather than competitive with OMTP.

Modularization proposal

Paddy says that modularization proposal looks fine. Is logical and to some extent arbitrary. People agree that people should be flexible about whether it is foo.addressBook or foo.pim.addressBook. Paddy says that the important questions are in the area of shared approaches, such as base classes used by multiple APIs. Jon agrees. Jon mentions that advanced JavaScript developers might come up with base class approaches that look different than what might exist in languages such as Java because of unique features of JS.

Loader vs no loader

Jon's email said we shouldn't have a loader. Paddy pushes back wtih 6 points to consider.

1. OpenAjax.load(api_unique_id) instead of <script> - prevents multiple loading of the same logic
2. Loader approach allows developer to give interface id rather than have to know about the implementation
3. Loader approach allows parameters to be be supplied
4. Loader approach might allow for easier delegating to another loader, such as invoking Google loader for Google features
5. Loader approach allows for recursive loading of dependent modules
6. Loader approach doesn't force modularization implementation to be known by the programmer

Jon asks Paddy how the loader knows which implementation to use. Paddy says the implementations would be registered, and he was assuming the OpenAjax Registry. Paddy says their current JavaScript code uses private knowledge about how WebVM is loaded. Jon observes that Ajax libraries right now use "private knowledge" about existing browsers to initialize themselves properly, and that the most likely scenario is that the shim layer's widespread deployment and adoption would likely come from the feature shipping with popular Ajax toolkits, which would support a limited number of N popular device API platforms.

Jon says his instincts are that there would be an SPI that the loader would use, and that if documented, programmers could choose to bypass the loader and manually load SCRIPT tags.

Jon suggests we assume a standard loader (which is a change from Jon's recent email with proposals).

Next Steps

Paddy will send email with explanation for why a standard loader makes sense and will send in a proposal for how the loader would work.

Next phone call in two weeks (July 17)

Unless someone does this first, Jon will send detailed proposals on particular APIs, such as addressBook. Maybe after that discussion we will be ready to start work on open source.