[OpenAjaxMobile] Minutes 2008-07-03

[Jon Ferraiolo]

Mobile Minutes 2008-07-03

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




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..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080703/b333c630/attachment.html