[OpenAjaxMobile] Revised strawman ideas

[Jon Ferraiolo]

I made a minor change below (search for JONV3) to reflect an asynchronous
design for our APIs.

-----------

Before our last phone call, I put together some strawman proposals at:

* http://www.openajax.org/member/wiki/OpenAjax_Device_APIs

During the phone call, people pointed out shortcomings and things to think
about:

* http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-19

Here are some further thoughts that I have.


(1) Let's embrace modularization and asynchronous registration (in line
with the sentiment during the previous phone call). Let's subdivide the
universe of device APIs into distinct modules. This will support the
scenario where, if you only need geolocation and address book APIs, then it
is possible to only load those APIs and not all of the others. This will
help performance on all fronts, including JavaScript download time and DLL
loading time (if necessary).

In terms of my original strawman proposal, instead of:
--------
MyFunctions = {
geo: {
getCurrentLocation: function(...) { ... }
...
},
pim: {
getAddressBook: function(...) { ... }
...
}
...
};
OpenAjax.device.providers.register(AdapterName,MyFunctions);
--------

we would have something like this:
--------
MyGeoFunctions = {
getCurrentLocation(...) { ...}
...
};
OpenAjax.device.providers.register
(AdapterName,"geo",MyGeoFunctions,ReadyCallback,ErrorCallback);
--------
(Note: the above sample code illustrates the module concept, but probably
isn't exactly what we want to have.)


(2) Let's have feature hierarchies, which means more than one level of
modularization. For example, if we have a "pim" module, it might have
submodules for "addressBook" and "taskList". I propose that we use
JavaScript notation (i.e., dots) as the separator character. Therefore, one
possible module that we might have would be
"OpenAjax.device.pim.addressBook". To build on the previous example, we
might have something like this:
--------
MyAddressBookFunctions = {
getAddressBook(...) { ...}
...
};
OpenAjax.device.providers.register
(AdapterName,"pim.addressBook",MyAddressBookFunctions,ReadyCallback,ErrorCallback);

--------


(3) Let's get rid of the connection handles approach that I proposed
previously. Instead, assume that most of the time, there is exactly one
"provider" for each module of APIs. What this means is that instead of my
previous proposal:
--------
ConnHandle = OpenAjax.device.connect("XYZAdapter");
contacts = ConnHandle.pim.addressBook.getAddressBook(...);
--------

the rule would be that the last provider that was registered would take
over for any previous providers, and therefore we would have something like
this (JONV3: Now has asynch API design) :
--------
function MyCallBack(...) { var addrBook = ...; }
OpenAjax.device.pim.addressBook.getAddressBook(...,MyCallBack,...);
--------
(Note: Besides making things simpler for the application developer, it also
simplifies the implementation of the shim layer. I can explain why if
anyone wants to know.)
(Note: If something unusual comes up and there are two providers loaded for
the same module, the application can either invoke the provider's private
APIs or switch providers by calling "register" again to import the provider
that he needs just before a particular operation.)


(4) We don't need to develop an industry standard loader to make this
project work. At our previous phone call, there was discussion about
advantages and disadvantages of our open source project managing the
loading process on behalf of the adapters. After thinking things through, I
am convinced that JavaScript loading is orthogonal to the main
functionality of the shim layer. The key thing is that the provider's
JavaScript gets loaded, one way or another, and it doesn't matter to the
shim layer whether that JavaScript was loaded using a standard loader or an
adhoc loader. If the community desires a standard loader, my thinking is
that should be a separate activity from the device APIs activity.


I updated the wiki page at (
http://www.openajax.org/member/wiki/OpenAjax_Device_APIs) to reflect these
revised ideas. I hope there is some email discussion before the phone call
on Thursday.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080702/2f8734cd/attachment.html