From jferrai at us.ibm.com  Tue Jul  1 12:49:35 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Tue, 1 Jul 2008 12:49:35 -0700
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this week
	and next week
Message-ID: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>


I thought we should see who is available to show up for the Mobile TF phone
call this week, with next week as a backup.

Can you attend the phone call this week? (Thursday 9am California, noon New
York, 5pm Paris)
How about same time next week?

Thanks.
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080701/4e100e64/attachment.html 

From paddy.byers at gmail.com  Tue Jul  1 15:01:13 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Tue, 1 Jul 2008 23:01:13 +0100
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
	week and next week
In-Reply-To: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
References: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
Message-ID: <59db1b5a0807011501r42155a2at7dc32fd78f67abb8@mail.gmail.com>

Hi,

I'm available.

Thanks - Paddy

On Tue, Jul 1, 2008 at 8:49 PM, Jon Ferraiolo <jferrai at us.ibm.com> wrote:

> I thought we should see who is available to show up for the Mobile TF phone
> call this week, with next week as a backup.
>
> Can you attend the phone call this week? (Thursday 9am California, noon New
> York, 5pm Paris)
> How about same time next week?
>
> Thanks.
> Jon
>
>
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080701/eab00cc9/attachment.html 

From ksankar at cisco.com  Tue Jul  1 15:07:50 2008
From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Tue, 1 Jul 2008 15:07:50 -0700
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
	week and next week
In-Reply-To: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
References: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A05124001@xmb-sjc-219.amer.cisco.com>

Am booked this week. Free next week

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: Tuesday, July 01, 2008 12:50 PM
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
weekand next week

 

I thought we should see who is available to show up for the Mobile TF
phone call this week, with next week as a backup.

Can you attend the phone call this week? (Thursday 9am California, noon
New York, 5pm Paris)
How about same time next week?

Thanks.
Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080701/137a4c7d/attachment.html 

From boloker at us.ibm.com  Tue Jul  1 15:41:11 2008
From: boloker at us.ibm.com (David Boloker)
Date: Tue, 1 Jul 2008 17:41:11 -0500
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
 week	and next week
In-Reply-To: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
Message-ID: <OF84AEBC12.FE4B5796-ON85257479.007C514D-85257479.007C9DD0@us.ibm.com>

I'll be there!




Jon Ferraiolo/Menlo Park/IBM at IBMUS 
Sent by: mobile-bounces at openajax.org
07/01/08 03:49 PM
Please respond to
OpenAjax Alliance discussion list on Mobile Ajax <mobile at openajax.org>


To
mobile at openajax.org
cc

Subject
[OpenAjaxMobile] Please RSVP about Mobile TF phone call this week and next 
week






I thought we should see who is available to show up for the Mobile TF 
phone call this week, with next week as a backup.

Can you attend the phone call this week? (Thursday 9am California, noon 
New York, 5pm Paris)
How about same time next week?

Thanks.
Jon
_______________________________________________
mobile mailing list
mobile at openajax.org
http://openajax.org/mailman/listinfo/mobile

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

From jferrai at us.ibm.com  Tue Jul  1 22:07:27 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Tue, 1 Jul 2008 22:07:27 -0700
Subject: [OpenAjaxMobile] Revised strawman ideas
Message-ID: <OF06262389.56674A9D-ON8825747A.0015CC63-8825747A.001C25FB@us.ibm.com>



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:
--------
contacts = OpenAjax.device.pim.addressBook.getAddressBook(...);
--------
(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/20080701/752b1e7d/attachment-0001.html 

From Andrew.Sledd at ikivo.com  Wed Jul  2 01:28:51 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Wed, 2 Jul 2008 10:28:51 +0200
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
	weekand next week
In-Reply-To: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDDB68D9@SESTHSRV10.zoomon.local>

At the last meeting we agreed we would aim for meeting tomorrow. But if
that doesn't gain favor then next week is ok too.
Both work for me.
 
Andy

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: den 1 juli 2008 21:50
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
weekand next week



I thought we should see who is available to show up for the Mobile TF
phone call this week, with next week as a backup.

Can you attend the phone call this week? (Thursday 9am California, noon
New York, 5pm Paris)
How about same time next week?

Thanks.
Jon



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

From guillermo.caudevilla at vodafone.com  Wed Jul  2 02:22:50 2008
From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo,
	VF-ES (gcaudev))
Date: Wed, 2 Jul 2008 11:22:50 +0200
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this
	weekand next week
In-Reply-To: <OF2A07D31F.4CB5CDE8-ON88257479.006CB7F7-88257479.006CE8F7@us.ibm.com>
Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F0158C078@ESM9-MXMB05.vf-es.internal.vodafone.com>

I probably won?t be available tomorrow...

Guillermo Caudevilla Laliena 
R&D Engineer 
Vodafone Group Research & Development 

Mobile: + 34 610 513898 
Fax: + 34 974 215267 
Email:guillermo.caudevilla at vodafone.com 
Web: www.betavine.net 
Mobile web: betavine.mobi 
Alternative contact: Unai Labirua, unai.labirua at vodafone.com 

R&D Software Lab in Huesca 
Parque Tecnol?gico WALQA  Ctra. Zaragoza, Km 566. 22197 Cuarte, HUESCA (SPAIN) 
Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN
Registered in England No 3802001 

 

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: martes, 01 de julio de 2008 20:50
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Please RSVP about Mobile TF phone call this weekand next week



I thought we should see who is available to show up for the Mobile TF phone call this week, with next week as a backup.

Can you attend the phone call this week? (Thursday 9am California, noon New York, 5pm Paris)
How about same time next week?

Thanks.
Jon



Confidencialidad
Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios y propiedad de Vodafone Espa?a. Queda prohibida su divulgaci?n, copia o distribuci?n a terceros sin la previa autorizaci?n escrita de Vodafone Espa?a, en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente y la destrucci?n del mismo. 

Confidentiality
The information in this e-mail and in any attachments is classified as Vodafone Espa?a Confidential and Proprietary Information and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Vodafone Espa?a and is s strictly prohibited by law. If you have received this communication in error, please, notify the sender by reply e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080702/9c5e5617/attachment.html 

From jferrai at us.ibm.com  Wed Jul  2 07:51:52 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 2 Jul 2008 07:51:52 -0700
Subject: [OpenAjaxMobile] Revised strawman ideas
In-Reply-To: <OF06262389.56674A9D-ON8825747A.0015CC63-8825747A.001C25FB@us.ibm.com>
Message-ID: <OFC8FCBD7F.E6AAA238-ON8825747A.0050E5DA-8825747A.0051A751@us.ibm.com>


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 

From Andrew.Sledd at ikivo.com  Wed Jul  2 14:42:03 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Wed, 2 Jul 2008 23:42:03 +0200
Subject: [OpenAjaxMobile] Thrusday conf call reminder - the call is on.
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDDB6A16@SESTHSRV10.zoomon.local>

Time: 9amPT, noonET, 5pm London, 6pm Paris
 
The hot  topics two weeks ago were the aspects of modularization and loader.
Jon has revised his strawman and made new/adjusted  proposals.
Jon will present these and we can discuss.
 
Call details:


  Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205 5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205 5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

IRC channel 

IRC channel: irc.freenode.net, #oaa-mobile
Free online IRC client: http://java.freenode.net/ <http://java.freenode.net/> 


________________________________________________
Andrew Sledd
Ikivo AB 
?stermalmsgatan 87 C
SE-114 59 Stockholm
Sweden
Mobile: +46 70 305  7712
Fax: +46 8 534 811 86
Email: andrew.sledd at ikivo.com
<http://www.ikivo.com/> http://www.ikivo.com <http://www.ikivo.com/> 


The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

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

From jferrai at us.ibm.com  Wed Jul  2 16:00:46 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 2 Jul 2008 16:00:46 -0700
Subject: [OpenAjaxMobile] Strawman proposal for API modularization
Message-ID: <OF19BA9F23.D3B9848B-ON8825747A.007DE2D4-8825747A.007E69D9@us.ibm.com>



One of the things we talked about in our most recent phone call was that we
needed to start talking about how to go about modularization all of the
various device APIs we might pursue. I have pulled together a strawman
proposal for initial discussion on the following wiki page:

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

The wiki page has a table:
* The first two columns represent copy/paste information from our
requirements page
* The 3rd column attempts to provide an executive summary of the key
interfaces in J2ME/MSA
* The 4th column attempts to provide an executive summary of the key
interfaces in MobileScript
* The 5th columns provides a high-level strawman for how to modularize the
given API within our initiative

(I did not provide a suggestion for the data feeds row. Nikunj is the
expert there.)

This is just a strawman to get some initial feedback so we can refine as we
proceed. One big caveat is that OMTP is supposedly doing something similar.
I might learn more about where things stand with OMTP in a phone call I
have just before our phone call tomorrow.

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

From jferrai at us.ibm.com  Thu Jul  3 07:53:12 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Thu, 3 Jul 2008 07:53:12 -0700
Subject: [OpenAjaxMobile] OMTP press release on device APIs
Message-ID: <OF2E6471DF.319B7A48-ON8825747B.0051B3B9-8825747B.0051C673@us.ibm.com>


FYI: http://www.theregister.co.uk/2008/07/03/omtp_bondi/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080703/3df60beb/attachment-0001.html 

From jferrai at us.ibm.com  Thu Jul  3 10:31:39 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Thu, 3 Jul 2008 10:31:39 -0700
Subject: [OpenAjaxMobile] Minutes 2008-07-03
Message-ID: <OFC982448D.5A135417-ON8825747B.00602B96-8825747B.0060485C@us.ibm.com>





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 

From rotan.hanrahan at mobileaware.com  Fri Jul  4 03:19:22 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Fri, 4 Jul 2008 06:19:22 -0400
Subject: [OpenAjaxMobile] Strawman proposal for API modularization
In-Reply-To: <OF19BA9F23.D3B9848B-ON8825747A.007DE2D4-8825747A.007E69D9@us.ibm.com>
References: <OF19BA9F23.D3B9848B-ON8825747A.007DE2D4-8825747A.007E69D9@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301A25C2E@FTO.mobileaware.com>

I know the people in Rococo quite well. They're specialists in Bluetooth
(early adopters, part of the JSR 82 team...) and should be able give
some authoritative info to fill in that particular blank box in the
table. I've forwarded the table to my contacts for comments.

 

---Rotan

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: 03 July 2008 00:01
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Strawman proposal for API modularization

 

One of the things we talked about in our most recent phone call was that
we needed to start talking about how to go about modularization all of
the various device APIs we might pursue. I have pulled together a
strawman proposal for initial discussion on the following wiki page:

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

The wiki page has a table:
* The first two columns represent copy/paste information from our
requirements page
* The 3rd column attempts to provide an executive summary of the key
interfaces in J2ME/MSA
* The 4th column attempts to provide an executive summary of the key
interfaces in MobileScript
* The 5th columns provides a high-level strawman for how to modularize
the given API within our initiative

(I did not provide a suggestion for the data feeds row. Nikunj is the
expert there.)

This is just a strawman to get some initial feedback so we can refine as
we proceed. One big caveat is that OMTP is supposedly doing something
similar. I might learn more about where things stand with OMTP in a
phone call I have just before our phone call tomorrow.

Jon

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

From paddy.byers at gmail.com  Fri Jul  4 05:12:18 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Fri, 4 Jul 2008 13:12:18 +0100
Subject: [OpenAjaxMobile] Strawman proposal for API modularization
In-Reply-To: <D5306DC72D165F488F56A9E43F2045D301A25C2E@FTO.mobileaware.com>
References: <OF19BA9F23.D3B9848B-ON8825747A.007DE2D4-8825747A.007E69D9@us.ibm.com>
	<D5306DC72D165F488F56A9E43F2045D301A25C2E@FTO.mobileaware.com>
Message-ID: <59db1b5a0807040512n5da2caf9p5b455b62e1fe5319@mail.gmail.com>

Hi,

> I know the people in Rococo quite well. They're specialists in Bluetooth
> (early adopters, part of the JSR 82 team?) and should be able give some
> authoritative info to fill in that particular blank box in the table. I've
> forwarded the table to my contacts for comments.
>
I did speak to Sean O'Sullivan back at 3GSM about Rococo writing a bluetooth
javascript API and  contributing it to OAA, and he said they were
interested.

Thanks - Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080704/2ca43eda/attachment.html 

From jferrai at us.ibm.com  Tue Jul  8 12:37:12 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Tue, 8 Jul 2008 12:37:12 -0700
Subject: [OpenAjaxMobile] W3C's geolocation API
Message-ID: <OF25DD9765.EC16E54C-ON88257480.006B9ABE-88257480.006BC6DF@us.ibm.com>


Here is the spec:

* http://dev.w3.org/geo/api/spec-source.html

I like their API and suggest that we model our APIs in a parallel manner.
Kai told the W3C that he likes their API, also. What does everyone else
think?

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080708/0a59a816/attachment.html 

From rotan.hanrahan at mobileaware.com  Tue Jul  8 13:45:54 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Tue, 8 Jul 2008 16:45:54 -0400
Subject: [OpenAjaxMobile] W3C's geolocation API
References: <OF25DD9765.EC16E54C-ON88257480.006B9ABE-88257480.006BC6DF@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D39C6E1A@FTO.mobileaware.com>

Just a word of caution. What is referenced in the email is not, as the email subject suggests, the W3C's geolocation API.
 
To be clear, the W3C has no such API. The W3C is currently working on a charter for a group to deal with the design of such an API, and while the chartering activity is going on, Matt Womer (who is W3C staff responsible for drafting the charter) has invited contributions and comments. The link in the email (below) is a contribution from a member of Google's Gears team. Other contributions, suggestions and comments are expected.
 
The argument about the scope, deliverables, modus operandi and other matters pertaining to the proposed W3C working group on Geolocation is ongoing. If you are interested, follow the public mailing list here:
 
http://lists.w3.org/Archives/Public/public-geolocation/
 
I hope this clarifies.
 
---Rotan.

________________________________

From: mobile-bounces at openajax.org on behalf of Jon Ferraiolo
Sent: Tue 08/07/2008 20:37
To: mobile at openajax.org
Subject: [OpenAjaxMobile] W3C's geolocation API



Here is the spec:

* http://dev.w3.org/geo/api/spec-source.html

I like their API and suggest that we model our APIs in a parallel manner. Kai told the W3C that he likes their API, also. What does everyone else think?

Jon





From Andrew.Sledd at ikivo.com  Wed Jul 16 01:32:28 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Wed, 16 Jul 2008 10:32:28 +0200
Subject: [OpenAjaxMobile] Mobile TF Conferecan Call Reminder
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDDF38C9@SESTHSRV10.zoomon.local>

Hi all,
 
The next conference call is this Thusday July 17. See below for details.
 
Minutes from previous meeitng can be found here: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-03 <http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-03>  
 
 
Time: 9amPT, noonET, 5pm London, 6pm Paris
 
Call details:


  Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205 5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205 5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

IRC channel 

IRC channel: irc.freenode.net, #oaa-mobile
Free online IRC client: http://java.freenode.net/ <http://java.freenode.net/> 


________________________________________________
Andrew Sledd
Ikivo AB 
?stermalmsgatan 87 C
SE-114 59 Stockholm
Sweden
Mobile: +46 70 305  7712
Fax: +46 8 534 811 86
Email: andrew.sledd at ikivo.com
<http://www.ikivo.com/> http://www.ikivo.com <http://www.ikivo.com/> 


The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080716/0ca74ce0/attachment.html 

From jferrai at us.ibm.com  Wed Jul 16 15:48:14 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 16 Jul 2008 15:48:14 -0700
Subject: [OpenAjaxMobile] Some ideas on API design
Message-ID: <OF5F63FB60.99A0502D-ON88257488.007C90E5-88257488.007D4428@us.ibm.com>



I posted some ideas on how our device APIs might work. I attempted to come
up with something that was consistent with previous discussion (e.g.,
asynchronous), would be natural to JavaScript developers, and aligned with
the general approach proposed by Google for the geolocation APIs.

Here is the wiki page that I'm working on:

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

I didn't get as far on the above wiki page as I had hoped I would before
sending this email. I hope to work on it some more before the phone call
tomorrow. In any case, please review what I have so far so we can bat
things around at the phone call. If you see things you don't like or have
suggestions for improvement, please send email with your comments in
advance of the phone call.

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

From paddy.byers at gmail.com  Thu Jul 17 00:28:42 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Thu, 17 Jul 2008 08:28:42 +0100
Subject: [OpenAjaxMobile] {Filename?} Some ideas on API loader
Message-ID: <59db1b5a0807170028s75aa0624s7e95b980d4e2b6c3@mail.gmail.com>

Warning: This message has had one or more attachments removed
Warning: (loader.js).
Warning: Please read the "Kattare-Attachment-Warning.txt" attachment(s) for more information.

Hi,

In the last call we discussed issues relating to the use of a loader
function versus simple inclusion of APIs by explicit reference to a script.
I agreed to submit a proposal on how a loader might work.

Please see the attached. I haven't thought through all of the details but
you should get the idea. One issue not dealt with in the proposal is that
the loading of modules/APIs will in some cases be asynchronous and I haven't
included any way of handling that, but my idea was that the OpenAjax Hub
functionality would deal with that part.

We can discuss on today's call if you like (but it sounds like we should
devote most time this week to the discussion of actual APIs).

Thanks - Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080717/5fdb214d/attachment.html 
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "loader.js"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the original attachment.

At Thu Jul 17 00:28:55 2008 the virus scanner said:
   MailScanner: Possible Microsoft JScript attack (loader.js)

-- 
Postmaster
Kattare Internet, LLC
www.kattare.com

For all your IT requirements visit: http://www.transtec.co.uk

From paddy.byers at gmail.com  Thu Jul 17 00:33:48 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Thu, 17 Jul 2008 08:33:48 +0100
Subject: [OpenAjaxMobile] {Filename?} Some ideas on API loader
In-Reply-To: <59db1b5a0807170028s75aa0624s7e95b980d4e2b6c3@mail.gmail.com>
References: <59db1b5a0807170028s75aa0624s7e95b980d4e2b6c3@mail.gmail.com>
Message-ID: <59db1b5a0807170033ja219bf0q7e14ccb29efd60ca@mail.gmail.com>

Dear MailScanner

The original e-mail attachment "loader.js"
> is on the list of unacceptable attachments for this site and has been
> replaced by this warning message.


Try this.

Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080717/f1079af2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loader.zip
Type: application/zip
Size: 1286 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080717/f1079af2/attachment.zip 

From guillermo.caudevilla at vodafone.com  Thu Jul 17 04:53:40 2008
From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo,
	VF-ES (gcaudev))
Date: Thu, 17 Jul 2008 13:53:40 +0200
Subject: [OpenAjaxMobile] Mobile TF Conferecan Call Reminder
In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDDF38C9@SESTHSRV10.zoomon.local>
Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F0168C2F3@ESM9-MXMB05.vf-es.internal.vodafone.com>

Unfortunately I cannot join this afternoon.
Regards.
Guillermo.

Guillermo Caudevilla Laliena 
R&D Engineer 
Vodafone Group Research & Development 

Mobile: + 34 610 513898 
Fax: + 34 974 215267 
Email:guillermo.caudevilla at vodafone.com 
Web: www.betavine.net 
Mobile web: betavine.mobi 
Alternative contact: Unai Labirua, unai.labirua at vodafone.com 

R&D Software Lab in Huesca 
Parque Tecnol?gico WALQA  Ctra. Zaragoza, Km 566. 22197 Cuarte, HUESCA (SPAIN) 
Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN
Registered in England No 3802001 

 

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Andrew Sledd
Sent: mi?rcoles, 16 de julio de 2008 10:32
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: [OpenAjaxMobile] Mobile TF Conferecan Call Reminder


Hi all,
 
The next conference call is this Thusday July 17. See below for details.
 
Minutes from previous meeitng can be found here: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-03 <http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-03>  
 
 
Time: 9amPT, noonET, 5pm London, 6pm Paris
 
Call details:


  Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205 5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205 5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

IRC channel 

IRC channel: irc.freenode.net, #oaa-mobile
Free online IRC client: http://java.freenode.net/ <http://java.freenode.net/> 


________________________________________________
Andrew Sledd
Ikivo AB 
?stermalmsgatan 87 C
SE-114 59 Stockholm
Sweden
Mobile: +46 70 305  7712
Fax: +46 8 534 811 86
Email: andrew.sledd at ikivo.com
<http://www.ikivo.com/> http://www.ikivo.com <http://www.ikivo.com/> 


The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

 
Confidencialidad
Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios y propiedad de Vodafone Espa?a. Queda prohibida su divulgaci?n, copia o distribuci?n a terceros sin la previa autorizaci?n escrita de Vodafone Espa?a, en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente y la destrucci?n del mismo. 

Confidentiality
The information in this e-mail and in any attachments is classified as Vodafone Espa?a Confidential and Proprietary Information and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Vodafone Espa?a and is s strictly prohibited by law. If you have received this communication in error, please, notify the sender by reply e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080717/591576f6/attachment-0001.html 

From jferrai at us.ibm.com  Thu Jul 17 07:56:13 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Thu, 17 Jul 2008 07:56:13 -0700
Subject: [OpenAjaxMobile] {Filename?} Some ideas on API loader
In-Reply-To: <59db1b5a0807170033ja219bf0q7e14ccb29efd60ca@mail.gmail.com>
Message-ID: <OF7F7BBE31.8E409216-ON88257489.00514DEB-88257489.00520D59@us.ibm.com>


> Try this.

Hi Paddy,
I tried it and I like it. Thanks for pulling this together. IMO this is a
very good JavaScript approach.

My only question is the 'name' parameter to the load() and makeURI()
functions:
------
function makeURI(name,version,params){
      return name+"?v="+version+encodeParams(params)+webvm.defaults.params;
}
------
What are some examples for 'name'? Would it be something like 'WebVM' or
'WebVM.js' or 'http://aplixcorp.com/code/WebVM.js'? In the OpenAjax
Registry, we key off of a short name that usually matches the global
JavaScript object that the given Ajax toolkit uses for most of its work.
For example, the Registry entries for jQuery and Dojo are "jQuery" and
"dojo", respectively. (Note: dojo actually uses dojo, dijit, and maybe one
or two other global objects.)

Jon



mobile-bounces at openajax.org wrote on 07/17/2008 12:33:48 AM:

> Dear MailScanner

> The original e-mail attachment "loader.js"
> is on the list of unacceptable attachments for this site and has been
> replaced by this warning message.
>
> Try this.
>
> Paddy
> [attachment "loader.zip" deleted by Jon Ferraiolo/Menlo Park/IBM]
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080717/06cc5326/attachment.html 

From jferrai at us.ibm.com  Thu Jul 17 18:04:30 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Thu, 17 Jul 2008 18:04:30 -0700
Subject: [OpenAjaxMobile] Dojo's (and Ext's and jQuery's) use of associative
	arrays as parameters
Message-ID: <OF90EDBDC2.343E2508-ON8825748A.00039902-8825748A.0005E7CF@us.ibm.com>



I am researching the Dojo build system (which came up both in the Mobile TF
and IDE WG phone calls this week). In going through some of the Dojo
materials, I found the following example within their hello_world tutorial
at (?http://dojotoolkit.org/book/dojo-book-0-9/hello-world-tutorial):

------
dojo.xhrGet({
           url: 'HelloWorldResponseGET.php',
           load: helloCallback,
           error: helloError,
           content: {name: dojo.byId('name').value }
        });
------

Two things to observe: (a) the single-object associative-array approach,
(b) two callbacks (success and error).

There are other parameters to xhrGet, including timeout controls, as shown
at (http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.xhrGet). There are a
number of APIs in Dojo that use the single-object associative-array
approach.

I also skimmed through some of the APIs for another popular library, Ext
JS, and they also used the single-object associative-array approach in a
number of their APIs.

jQuery doesn't seem to use single-object associative-arrays as parameters
as often as Dojo and Ext JS, but it does appear in some of jQuery's APIs.

Here is what I conclude:
* JavaScript developers are able to deal with APIs that use associative
arrays to pass name-value pairs
* But none of the major toolkits goes overboard using this technique

Jon



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

From apeller at us.ibm.com  Thu Jul 17 19:30:25 2008
From: apeller at us.ibm.com (Adam Peller)
Date: Thu, 17 Jul 2008 22:30:25 -0400
Subject: [OpenAjaxMobile] Dojo's (and Ext's and jQuery's) use of
	associative	arrays as parameters
In-Reply-To: <OF90EDBDC2.343E2508-ON8825748A.00039902-8825748A.0005E7CF@us.ibm.com>
Message-ID: <OF6764BA6B.6A632609-ON8525748A.000D1EA8-8525748A.000DC233@us.ibm.com>


Just a footnote to what Jon said about callbacks...  dojo.xhr uses
dojo.Deferred, which is a more generalized mechanism for callbacks, copied
from Bob Ippolito's work on Mochi kit, which in turn was inspired by
Twisted (Python).

http://mochikit.com/doc/html/MochiKit/Async.html

I don't know how consistently the associative array approach is applied in
Dojo, but I think it's generally used for one or more of the following
reasons

1) the arguments are too numerous to list out, and it would be awkward to
make some optional while they are all ordered, so the hash is a natural
solution
2) to make "future-proof" without breaking the signature
3) to allow for reuse/mixins for functions with similar args
4) because the author was object-happy

-Adam



                                                                           
             Jon                                                           
             Ferraiolo/Menlo                                               
             Park/IBM at IBMUS                                             To 
             Sent by:                  mobile at openajax.org                 
             mobile-bounces at op                                          cc 
             enajax.org                                                    
                                                                   Subject 
                                       [OpenAjaxMobile] Dojo's (and Ext's  
             07/17/08 09:04 PM         and jQuery's) use of associative    
                                       arrays as parameters                
                                                                           
             Please respond to                                             
             OpenAjax Alliance                                             
              discussion list                                              
              on Mobile Ajax                                               
                                                                           
                                                                           




I am researching the Dojo build system (which came up both in the Mobile TF
and IDE WG phone calls this week). In going through some of the Dojo
materials, I found the following example within their hello_world tutorial
at (http://dojotoolkit.org/book/dojo-book-0-9/hello-world-tutorial):

------
dojo.xhrGet({
url: 'HelloWorldResponseGET.php',
load: helloCallback,
error: helloError,
content: {name: dojo.byId('name').value }
});
------

Two things to observe: (a) the single-object associative-array approach,
(b) two callbacks (success and error).

There are other parameters to xhrGet, including timeout controls, as shown
at (http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.xhrGet). There are a
number of APIs in Dojo that use the single-object associative-array
approach.

I also skimmed through some of the APIs for another popular library, Ext
JS, and they also used the single-object associative-array approach in a
number of their APIs.

jQuery doesn't seem to use single-object associative-arrays as parameters
as often as Dojo and Ext JS, but it does appear in some of jQuery's APIs.

Here is what I conclude:
* JavaScript developers are able to deal with APIs that use associative
arrays to pass name-value pairs
* But none of the major toolkits goes overboard using this technique

Jon



_______________________________________________
mobile mailing list
mobile at openajax.org
http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080717/5a5ac1ad/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080717/5a5ac1ad/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic08739.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080717/5a5ac1ad/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080717/5a5ac1ad/attachment-0002.gif 

From jferrai at us.ibm.com  Mon Jul 21 09:43:52 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Mon, 21 Jul 2008 09:43:52 -0700
Subject: [OpenAjaxMobile] Minutes 2008-07-17
Message-ID: <OF1CBAD31B.CD0B2876-ON8825748D.005BBAB5-8825748D.005BE840@us.ibm.com>



Here are the minutes from last Thursday's phone call:

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





Attendees
      Paddy Byers, Aplix
      Jon Ferraiolo, IBM
      Adam Peller, IBM
      Andrew Sledd, Ikivo (co-chair)
      Ian Hay, Orange France-Telecom


Minutes

OMTP report from Paddy


Paddy: We are talking about how to respond to W3C Widget Requirements. We
are thin on the ground due to summer holidays. We should have public
working drafts from both the arch/security committee and the interfaces
committee. Mostly mid-level requirements that states the functionality that
we want. There will be some low-level requirements that are moving towards
actual low-level APIs but those are embryonic.


Paddy: I forwarded Jon's proposed APIs to the OMTP list. Not fully
consistent with what we have been working on. In general, the set of
principles are good but I don't agree on all of the details.



General process going forward


Jon: What I am thinking is that we discuss high-level approaches in the
phone call, but work out the details such as the exact APIs in the open
source effort


Andy: Yes



Loader


Paddy: I don't want to monopolize the call with the loader. We talked about
it for most of the call last week


Jon: Andy, Adam, have you looked at Paddy's loader JavaScript?


Andy: Just now


Adam: Looks similar to Dojo, which uses two mechanisms, both dynamic script
and xhr


Paddy: If we go for the loader, then we want the ability for a particular
loader to add its own private implementation components. Works like Browser
Plus. Then have a fallback behavior that is portable. Resolve name and
version into a URI is the standard case.


Paddy: Regarding Jon's question, the name is a URI. Could be opaque like a
URN or an http URI to which you append parameters. But the script could be
more intelligent.


Adam: Sorry, I missed earlier discussion, but can we back up? Why not just
load script manually?


Paddy: We talked about a number of advantages to a standard loader. Among
the advantage, you can tell if a module is already loaded. Also, provides
the ability to pass parameters and satisfy particular requests.


Adam: There are pitfalls. The latency issue of loading script tags
separately. Prevents the ability to put inline JavaScript. You can use
async requests but that has possibility of race conditions. If you use
synchronous XHR, it blocks everything else. It is difficult to know when a
script has been loaded.


Paddy: In our model, things key off of onload. But without a loader, chance
of more roundtrips.


Adam: With loader approach, chance of race conditions.


Paddy: What does loader do in dojo? Hide things from the programmer?


Adam: Yes


Paddy: Individual toolkits can optimize on the proposed approach, such as
dojo offering a more advanced loader. My code is just an illustration of
functionality, not exactly how it would work.


Adam: But I don't think this would slide into dojo


Paddy: But everything could have been loaded beforehand


Adam: Yes, that's how dojo works


Paddy: Need to look how this aligns with existing frameworks


Jon: We need to study this against dojo and other toolkits


Adam: Most toolkits put the burden on the developer


Andy: Given our fast-track approach, which will give developers what they
need?


Adam: We don't want to do something that has performance problems


Jon: Yes, if it isn't optimal in performance, it won't get adopted


Paddy: What we want to avoid is load, then go get more things, which isn't
good. Need to trigger before doc load. Provided you do that, you have
contained any damage. Need to be optimized away.


Adam: May have to promote this approach to a best practice. Dojo has to
wait for onload to avoid race conditions


Andy/Adam/Jon: We have to assume that anything that is problematic on
desktop will be worse on mobile due to increased fragmentation.


Paddy: Not always the case that a script element will be added.


Andy: There is the advantage of parsing parameters.


Adam: Of course it is possible to add parameters to the URI. I love the
benefits but it raises questions. Also, may load a library (DLL) which adds
more timing issues and latency issues.


Andy/Paddy: Network latencies will dominate.


Jon: Let's close discussion and have someone study dojo.


Andy: Adam, can you write up why loader isn't winning favor in desktop
browser world?


Adam: I'm not against a loader, I just want to see how well things will fit
in. Dojo provides quick development but offers various optimizations for
deployment.


Jon: I'll take the action to work with Adam to study dojo and other
libraries



Jon's API proposals


Jon: Just a starting point for discussion. I proposed CRUD-like method
names just arbitrarily to align with something that exists in industry. If
there are other approaches, bring them up. I'm not tied to the CRUD method
names.


Adam: How about getters and setters?


Jon: I have proposed you retrieve the whole property bag. But maybe we
should add getters and setters for particular properties.


Adam: Dojo data has CRUD-like APIs. Maybe a batch approach.


Jon: Do we need a transaction approach with callbacks?


Paddy: Only needed if API itself has a transaction notion.


Paddy: Let's talk about the one-arg proposal. All args as an associative
array. Haven't seen that before. Is that usual? Versus numbered args.


Adam: Sort of leverages the whole JSON movement. I've seen it used for
complex methods and flexibility.


Paddy: Yes, allows extensibility. Interesting approach.


Paddy: A disadvantage is increased garbage for collection. Naive usage
would create garbage.


Andy: Need modularity at the right level so you don't load too much.


PaddY: Some callbacks may not be clear relative to success versus failure.
Seems arbitrary. Also, what is the parameter list for callbacks? Also,
sometimes you want to pass the original object to the callback function.


Jon: My proposal takes the approach used by the OpenAjax Hub which sends
both publisher and subscriber data to the callback.


Paddy: Good to sketch out some examples.


Jon: Yes


Paddy: Back to shadow objects. But sometimes you will pass a real object
with APIs. For example, file object with a but of methods


Jon: Yes, right, by saying always shadow objects, that's too extreme


Andy: A principle, not a requirement


Paddy: API doc should be clear whether pure shadow or pure references


Jon: Yes


Paddy: Better to be consistent


Jon: Will update the spec to reflect comments from this phone call

Next phone call
      No Andy
      Maybe Paddy
      Try for 2 weeks from now. Backup is 3 weeks from now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080721/a7a44577/attachment.html 

From jferrai at us.ibm.com  Mon Jul 28 11:57:08 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Mon, 28 Jul 2008 11:57:08 -0700
Subject: [OpenAjaxMobile] Let's postpone our next phone call until Aug 7
Message-ID: <OF4107D2FB.7C1B4903-ON88257494.0067DB95-88257494.00681BB2@us.ibm.com>



At our most recent phone call, we had tentatively scheduled the next phone
call for this week (Aug 31) with the backup date of Aug 7. Because of
various developments (e.g., impending releases of public drafts from OMTP),
I suggest that we go with the backup plan. That will also allow Andrew
Sledd to attend and lead the meeting.

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

From jferrai at us.ibm.com  Thu Jul 31 08:22:52 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Thu, 31 Jul 2008 08:22:52 -0700
Subject: [OpenAjaxMobile] Reminder: no meeting today, next week instead
Message-ID: <OF87DECBB5.F393005D-ON88257497.00546965-88257497.00547DBD@us.ibm.com>


Our next Mobile TF phone call will be next week, on Aug 7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080731/b17a7445/attachment.html 

From jferrai at us.ibm.com  Wed Aug  6 11:45:07 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 6 Aug 2008 11:45:07 -0700
Subject: [OpenAjaxMobile] Let's postpone our phone call one more week (until
	Aug 14)
Message-ID: <OF542D077C.245DA3D4-ON8825749D.0066D14E-8825749D.00670238@us.ibm.com>


OMTP hasn't uploaded their public drafts yet, but promise to do so by
Friday Aug. 8. Also, I know that some people are unavailable this week.

Therefore, I suggest that we not have a Mobile TF phone call this week, and
postpone until Thursday Aug 14.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080806/8586e1ec/attachment.html 

From paddy.byers at gmail.com  Wed Aug  6 13:15:33 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Wed, 6 Aug 2008 21:15:33 +0100
Subject: [OpenAjaxMobile] Let's postpone our phone call one more week
	(until Aug 14)
In-Reply-To: <OF542D077C.245DA3D4-ON8825749D.0066D14E-8825749D.00670238@us.ibm.com>
References: <OF542D077C.245DA3D4-ON8825749D.0066D14E-8825749D.00670238@us.ibm.com>
Message-ID: <59db1b5a0808061315t3d460469s9dd0a74a01a3c249@mail.gmail.com>

Hi,

I also won't be available for the 14th, nor the 21st, but have fun and I'll
be around after that.

Paddy

On Wed, Aug 6, 2008 at 7:45 PM, Jon Ferraiolo <jferrai at us.ibm.com> wrote:

> OMTP hasn't uploaded their public drafts yet, but promise to do so by
> Friday Aug. 8. Also, I know that some people are unavailable this week.
>
> Therefore, I suggest that we not have a Mobile TF phone call this week, and
> postpone until Thursday Aug 14.
>
> Jon
>
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080806/6ae5287b/attachment.html 

From jferrai at us.ibm.com  Fri Aug  8 09:36:38 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Fri, 8 Aug 2008 09:36:38 -0700
Subject: [OpenAjaxMobile] OMTP Bondi documents posted
Message-ID: <OF697C08C7.E647DE25-ON8825749F.005B2042-8825749F.005B3EDF@us.ibm.com>


OMTP has posted public drafts for their device APIs initiatives:

http://www.omtp.org/Bondi/PublicDraft.aspx

I recommend that we talk about these drafts as one of the topics for next
Thursday's phone call.

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

From jferrai at us.ibm.com  Wed Aug 13 13:15:06 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 13 Aug 2008 13:15:06 -0700
Subject: [OpenAjaxMobile] Agenda for tomorrow's phone call: Bondi
Message-ID: <OF37792185.A011DE6C-ON882574A4.006EC37A-882574A4.006F3EED@us.ibm.com>







Next meeting
      Date: August 14, 2008
      Time:
            9amPT, noonET, 5pm London, 6pm Paris
      Agenda
            Discuss Bondi specs: http://www.omtp.org/Bondi/PublicDraft.aspx
            OpenGardens comments on Bondi:
            http://opengardensblog.futuretext.com/archives/2008/07/omtp_bondi_a_de_1.html



See below for call-in information.



Conference Call PIN and Phone Numbers
   Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414

  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205 5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205 5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080813/c350fae1/attachment.html 

From nickolas at us.ibm.com  Wed Aug 13 17:08:52 2008
From: nickolas at us.ibm.com (Stewart Nickolas)
Date: Wed, 13 Aug 2008 20:08:52 -0400
Subject: [OpenAjaxMobile] Nickolas, Stewart is out of the office.
Message-ID: <OF6D5C8BB3.36B37357-ON852574A5.0000D007-852574A5.0000D007@us.ibm.com>


I will be out of the office starting  08/12/2008 and will not return until
08/18/2008.

I will respond to your message when I return.


From jferrai at us.ibm.com  Mon Sep  1 16:11:39 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Mon, 1 Sep 2008 16:11:39 -0700
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4 Sept or
	Friday 5 Sept
Message-ID: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>


We were planning to have a phone call this Thursday, but it turns out that
I am presenting at a conference at our normal phone call time (9am
Thursday).

Could people please RSVP with their availability for the following time
slots for a Mobile TF phone call this week:

1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris

The main topic will be reviewing the status of the OMTP Bondi project,
latest news about activities at W3C and what role OpenAjax Alliance might
play going forward.

Thanks.
Jon




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080901/9291a6a8/attachment.html 

From guillermo.caudevilla at vodafone.com  Mon Sep  1 23:12:31 2008
From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo,
	VF-ES (gcaudev))
Date: Tue, 2 Sep 2008 08:12:31 +0200
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
	Sept orFriday 5 Sept
In-Reply-To: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F0168CED1@ESM9-MXMB05.vf-es.internal.vodafone.com>

Thrusday might be ok for me.

Guillermo Caudevilla Laliena 
R&D Engineer 
Vodafone Group Research & Development 

Mobile: + 34 610 513898 
Fax: + 34 974 215267 
Email:guillermo.caudevilla at vodafone.com 
Web: www.betavine.net 
Mobile web: betavine.mobi 
Alternative contact: Unai Labirua, unai.labirua at vodafone.com 

R&D Software Lab in Huesca 
Parque Tecnol?gico WALQA  Ctra. Zaragoza, Km 566. 22197 Cuarte, HUESCA (SPAIN) 
Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN
Registered in England No 3802001 

 

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: martes, 02 de septiembre de 2008 1:12
To: mobile at openajax.org
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4 Sept orFriday 5 Sept



We were planning to have a phone call this Thursday, but it turns out that I am presenting at a conference at our normal phone call time (9am Thursday).

Could people please RSVP with their availability for the following time slots for a Mobile TF phone call this week:

1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris

The main topic will be reviewing the status of the OMTP Bondi project, latest news about activities at W3C and what role OpenAjax Alliance might play going forward.

Thanks.
Jon







Confidencialidad
Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios y propiedad de Vodafone Espa?a. Queda prohibida su divulgaci?n, copia o distribuci?n a terceros sin la previa autorizaci?n escrita de Vodafone Espa?a, en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente y la destrucci?n del mismo. 

Confidentiality
The information in this e-mail and in any attachments is classified as Vodafone Espa?a Confidential and Proprietary Information and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Vodafone Espa?a and is s strictly prohibited by law. If you have received this communication in error, please, notify the sender by reply e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/5de949f9/attachment.html 

From ian.hay at orange-ftgroup.com  Mon Sep  1 23:54:51 2008
From: ian.hay at orange-ftgroup.com (ian.hay at orange-ftgroup.com)
Date: Tue, 2 Sep 2008 07:54:51 +0100
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
	Sept orFriday 5 Sept
In-Reply-To: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
Message-ID: <F3249EEDDE787140AE0EDCD25CD4D640053E2C53@UKEXBRIMBX002.uk.orangegad.com>


Hi,
 
Either of the Thursday slots are fine for me
 
Cheers
 
Ian


________________________________

	From: mobile-bounces at openajax.org
[mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo
	Sent: 02 September 2008 00:12
	To: mobile at openajax.org
	Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
Sept orFriday 5 Sept
	
	

	We were planning to have a phone call this Thursday, but it turns out
that I am presenting at a conference at our normal phone call time (9am
Thursday).
	
	Could people please RSVP with their availability for the following
time slots for a Mobile TF phone call this week:
	
	1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
	2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
	3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
	4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
	5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
	
	The main topic will be reviewing the status of the OMTP Bondi
project, latest news about activities at W3C and what role OpenAjax Alliance
might play going forward.
	
	Thanks.
	Jon
	
	
	
	
	
	



*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/31c005cf/attachment.html 

From paddy.byers at gmail.com  Tue Sep  2 00:50:52 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Tue, 2 Sep 2008 08:50:52 +0100
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
	Sept or Friday 5 Sept
In-Reply-To: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
References: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
Message-ID: <59db1b5a0809020050ocbe9306j19db5a89c2952270@mail.gmail.com>

Hi,

I can do either of the times on Thursday.

Thanks - Paddy

On Tue, Sep 2, 2008 at 12:11 AM, Jon Ferraiolo <jferrai at us.ibm.com> wrote:

> We were planning to have a phone call this Thursday, but it turns out that
> I am presenting at a conference at our normal phone call time (9am
> Thursday).
>
> Could people please RSVP with their availability for the following time
> slots for a Mobile TF phone call this week:
>
> 1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
> 2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
> 3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
> 4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
> 5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
>
> The main topic will be reviewing the status of the OMTP Bondi project,
> latest news about activities at W3C and what role OpenAjax Alliance might
> play going forward.
>
> Thanks.
> Jon
>
>
>
>
>
>
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/4e781be6/attachment.html 

From rotan.hanrahan at mobileaware.com  Tue Sep  2 03:41:39 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Tue, 2 Sep 2008 11:41:39 +0100
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
	Sept orFriday 5 Sept
In-Reply-To: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
References: <OF7FFC8BD0.A0BA84F6-ON882574B7.007E8C33-882574B7.007F6928@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301B0768B@FTO.mobileaware.com>

Both those Thursday times should be OK for me. We're just about to get
back into full action here in W3C, after the summer hiatus, so I can
give you a quick picture of what I expect to see happening over the next
few months. (That repository API I mentioned a few months back is about
to appear in public, elevated to "proposed Rec" level, so it's getting
close to the time when an Ajax-related vocabulary of device/browser
properties would become a hot topic, and maybe that's sometime I can
describe and put on the table for consideration over the next few
months.)

 

I've scanned through the OMTP Bondi interface working draft, mainly
looking for places where properties are mentioned, just to see if there
could be synergy with similar/related properties identified at the
server side and therefore relevant to the emerging ontology at the W3C
UWA group. Some were of potential interest. I also noted that the draft
had at least one incomplete item where on page 77 it says "If an attempt
is made to retrieve a property with any reserved key, the corresponding
value MUST not be returned, and it MUST not be possible to determine
from the response whether or not that property", which is obviously an
unfinished sentence. Perhaps the work "exists" is missing from the end?
Although that would be inconsistent with IFC-GR-060.1 elsewhere in the
document. I've sent my feedback to OMTP.

 

---Rotan.

 

 

 

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: 02 September 2008 00:12
To: mobile at openajax.org
Subject: [OpenAjaxMobile] RSVP: Phone call time slots for Thursday 4
Sept orFriday 5 Sept

 

We were planning to have a phone call this Thursday, but it turns out
that I am presenting at a conference at our normal phone call time (9am
Thursday).

Could people please RSVP with their availability for the following time
slots for a Mobile TF phone call this week:

1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris

The main topic will be reviewing the status of the OMTP Bondi project,
latest news about activities at W3C and what role OpenAjax Alliance
might play going forward.

Thanks.
Jon






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/f1bab148/attachment-0001.html 

From sbhola at us.ibm.com  Tue Sep  2 05:06:23 2008
From: sbhola at us.ibm.com (Sumeer Bhola)
Date: Tue, 2 Sep 2008 08:06:23 -0400
Subject: [OpenAjaxMobile] Sumeer Bhola/Watson/IBM is out of the office.
Message-ID: <OF0910BEA0.FE28C24E-ON852574B8.004280CE-852574B8.004280CE@us.ibm.com>


I will be out of the office starting  08/29/2008 and will not return until
09/08/2008.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/3eabdbc0/attachment.html 

From jferrai at us.ibm.com  Tue Sep  2 16:20:47 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Tue, 2 Sep 2008 16:20:47 -0700
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and
 proposals for how to generalize
Message-ID: <OF11B8BC52.5138819B-ON882574B8.0063BAE0-882574B8.00803F3F@us.ibm.com>



This email contains an analysis of the W3C's latest geolocation spec and
some thoughts about whether it would be good to pattern other device APIs
to use the same approaches. The email also makes various proposals about
several open issues. We could probably spend the entire hour on Thursday
walking through this email (and the inevitable email reponses that will
arise between now and then).

These comments refer to the Aug. 15 draft of the Geolocation API spec found
at:

* http://dev.w3.org/geo/api/spec-source.html

---------------------------
EXECUTIVE SUMMARY
---------------------------

Here are the key APIs defined in the geolocation spec:

* navigator.geolocation.lastPosition - an object holding most recent
geolocation position

* navigator.geolocation.getCurrentPosition(successCallback [, errorCallback
[,options]])
--- successCallback is the callback function
--- errorCallback (optional) is the error callback function
--- options (optional) can include extra parameters and provides for future
extensibility

* navigator.geolocation.watchPosition(successCallback [, errorCallback
[,options]])
--- see getCurrentPosition()

* navigator.geolocation.clearWatch(watchId) - where watchId is the return
value from watchPosition()

The successCallback receives a Position object defined as follows:

  interface Position {
    readonly attribute double latitude:;
    readonly attribute double longitude;
    readonly attribute double altitude:;
    readonly attribute double accuracy:;
    readonly attribute double altitudeAccuracy;
    readonly attribute double heading
    readonly attribute double velocity:
    readonly attribute DOMTimeStamp timestamp;
  };


---------------------------
JON'S EVALUATION
---------------------------

The W3C geolocation APIs are generally fine as is. The things I like about
this API:

* Simple and straightforward
* Good design for future extensibility due to the options object and the
position object
* I think it is good that they have both successCallback and errorCallback
as the first two parameters. This emphasizes to the developer that he might
want to pay close attention to error handling, such as being denied access
to the API for security reasons.
* I think it is good that it the API is placed onto navigator.geolocation
(versus omtp.whatever or OpenAjax.device.whatever)
* I think it is good to allow direct JS access to the most recent position,
such as window.geolocation.lastPosition.latitude, but the W3C spec needs to
warn developers that if they attempt to access that property and they don't
have permission, the property's value will be "undefined".

My concerns about this API:

(1) Not really a concern per se, but there is nothing in the spec yet about
security.OMTP's efforts will supplement the work done by the W3C.
(2) There needs to be additional query APIs for:
--(a) Checking to see if geolocation APIs are available
--(b) If so, what version of the APIs are available
--(c) Whether this particular application has permission to access those
APIs
(3) There is no support for Bondi's requirements about dynamically loading
of an implementation of particular APIs

Regarding (1), the W3C geolocation spec could say something general about
how a USER AGENT SHOULD provide a secure computing environment that has
careful implementation strategy to protect the user's privacy, and then
references OMTP's security spec as a security framework that can be used.
My thinking is that the W3C isn't a good place to write security specs. In
other words, as a general approach, W3C defines the APIs and OMTP defines
the security model. (Although OMTP should work on APIs that the W3C isn't
moving fast enough on yet and then probably turn those APIs over to the W3C
when the W3C is ready.)

Regarding (2a), the application can just check to see if the
navigator.geolocation object is present (i.e., not "undefined").

Regarding (2b), the W3C simply needs to put a 'version' read-only property
on the Geolocation interface.

Regarding (2c), I suggest that OMTP define the APIs for checking on whether
an application has permission to use the APIs. I would suggest something
like:

* navigator.apiPermissionsCheck(api_uri, successCallback [, errorCallback
[,options]])

where the 'api_uri' is a unique URI for a given API module. The 'options'
parameter provides an extensible architecture for the application to pass
in parameters. (One warning to the Bondi folks: the W3C has some specs with
feature URLs already, such as
http://www.w3.org/TR/SVGMobile12/feature.html. My guess is that Rotan can
educate us about other relevant work at the W3C.)

Regarding (3), long-term, I believe browsers will implement device APIs
natively, in which case dynamically attaching an implementation is the
minority case. Therefore, I think it is fine that the primary geolocation
APIs are simple and don't deal with the dynamic loading features. Instead,
dynamic loading should be a separate set of JS APIs. The geolocation APIs
would use the currently loaded implementation.

---------------------------
GOOD MODEL FOR OTHER APIs?
---------------------------

Are the W3C geolocation APIs a good model for other device APIs? I would
say yes. Here is a sketch for how other device APIs might look following
the pattern established by the geolocation APIs. (I used
http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules to help
build this analysis.)

Note that the parameters to the APIs would align with what the W3C has done
with geolocation: successCallback, errorCallback, and options.

Phone call APIs:
* navigator.phone.call() - calls a given number
* navigator.phone.answer() - answers the current call
* navigator.phone.hangup() - terminates the current call
* navigator.phone.{inbox,outbox,missed,all} - list management APIs (e.g.,
delete, get details)
* navigator.phone.{watchIncoming(),watchOutgoing(),watchMissed()}

SMS and MMS:
* navigator.{sms,mms}.send() - sends an SMS or MMS,
* navigator.{sms,mms}.{inbox,outbox,drafts} - list management APIs (e.g.,
delete, get details)
* navigator.{sms,mms}.{watchIncoming(),watchOutgoing()}

EMail:
* navigator.email.send() - sends an email
* navigator.email.{inbox,outbox,drafts,trash} - list management APIs (e.g.,
delete, get details)
* navigator.email.{watchIncoming(),watchOutgoing()}
(there will be a number of other email APIs, but I am only providing a
sketch)

AddressBook:
* navigator.contacts: list management APIs (e.g., add, delete, get details)

Calendar:
* navigator.calendar.{inbox,outbox,drafts,trash} - list management APIs
(e.g., add, delete, get details)
* navigator.calendar.{addReminder()}

Tasks:
* navigator.tasks: list management APIs (e.g., add, delete, get details)
* navigator.tasks.{addReminder()}

Power:
* navigator.power.{powerSource,chargeLevel,criticalBattery,charging,...}
* navigator.power.watchCriticalBattery(),watchChargeCompleted
(),watchPowerSourceChanged(),,...}

Network:
*
navigator.network.{current,cellular,wifi,bluetooth}.{signalStrength,networkType,criticalBattery,roaming,,...}
* navigator.network.watchOutOfCoverage(),,...}

Time:
(Not sure what exists already in the browser, but if we need to invent
something, here goes)
* navigator.clock.{date,time,timezone}
* navigator.clock.watchTimeZoneChange(),,...}

Media:
* navigator.resources.{images,audio, video} - list management APIs (e.g.,
delete, get details)
* (need other APIs for capture and annotate)

File I/O:
* W3C is working on APIs in this area

Camera:
navigator.camera.*

Effectors:
* navigator.effectors.mode
* navigator.effectors.setMode()
* navigator.effectors.watchModeChange()

Accelerometer:
* navigator.accelerometer.mode
* navigator.accelerometer.setMode()
* navigator.accelerometer.watchModeChange())

Memory:
* navigator.memory.watchOutOfMemory()

Console:
(Need to see what browser APIs exist already. Firefox/Firebug definitely
has a console object)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080902/6857b31d/attachment.html 

From rotan.hanrahan at mobileaware.com  Wed Sep  3 01:10:31 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Wed, 3 Sep 2008 09:10:31 +0100
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and
	proposals for how to generalize
In-Reply-To: <OF11B8BC52.5138819B-ON882574B8.0063BAE0-882574B8.00803F3F@us.ibm.com>
References: <OF11B8BC52.5138819B-ON882574B8.0063BAE0-882574B8.00803F3F@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301B077D5@FTO.mobileaware.com>

One of those inevitable email responses...

 

Once again I urge caution in referring to this as a W3C Specification.
It is not. It is a proposal submitted to the W3C for consideration as
the starting point of work on a geo-location API spec. Currently no
official group has been given formal responsibility for this work. It
might even be the case that this particular submission is discarded in
favour of something better.

 

Matt Womer is the W3C staff member responsible for steering the proposal
to set up a group to deal with geo-location. He is also my rep for the
group I chair, but he is currently on vacation so I have no up-to-date
information to offer regarding any progress being made on geo-location.

 

It is my understanding that if the geo-location group is set up then the
proposed spec will be taken under advisement, along with all of the
technical comments to date on the public mailing list that was set up
for the purpose. Obviously it would be of benefit for the OpenAjax
Alliance to add to these comments. Furthermore, assuming the group is
set up, the OAA can have an ongoing liaison with the group through the
public channels and possibly through overlapping membership (a common
informal mechanism that can be efficient and fruitful). A formal liaison
for this purpose is unnecessary (not least because we could do without
the paperwork!).

 

Regarding Jon's analysis, this is very comprehensive indeed! Assuming we
can come to a common position on the matters raised, we can make a
submission to W3C, via the appropriate list, to ensure they are
considered when the W3C group is eventually formed.

 

I'd also like to open an informal channel to Matt as soon as possible,
and when the group is formed then we can arrange a joint teleconference
to discuss any issues that arise.

 

Finally, regarding Jon's comment on "feature URLs", the current approach
within W3C is to use URIs (or increasingly, IRIs) as unique identifiers.
It is not necessarily the case that an individual URI can be
dereferenced, either to something human-readable or machine-readable.
However, some groups take the view that they should dereference to
something human-readable where the processing model does not require the
referenced resource to be fetched. If you are familiar with DTD or
Schema URLs you'll understand this issue, although fetching is generally
not performed for "well known" URLs* in order to avoid bottlenecks.

 

---Rotan

 

* Some people use URL and URI interchangeably, though this is not
strictly correct.

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: 03 September 2008 00:21
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and
proposals for how to generalize

 

This email contains an analysis of the W3C's latest geolocation spec and
some thoughts about whether it would be good to pattern other device
APIs to use the same approaches. The email also makes various proposals
about several open issues. We could probably spend the entire hour on
Thursday walking through this email (and the inevitable email reponses
that will arise between now and then).

These comments refer to the Aug. 15 draft of the Geolocation API spec
found at:

* http://dev.w3.org/geo/api/spec-source.html

---------------------------
EXECUTIVE SUMMARY
---------------------------

Here are the key APIs defined in the geolocation spec:

* navigator.geolocation.lastPosition - an object holding most recent
geolocation position

* navigator.geolocation.getCurrentPosition(successCallback [,
errorCallback [,options]])
--- successCallback is the callback function
--- errorCallback (optional) is the error callback function
--- options (optional) can include extra parameters and provides for
future extensibility

* navigator.geolocation.watchPosition(successCallback [, errorCallback
[,options]])
--- see getCurrentPosition()

* navigator.geolocation.clearWatch(watchId) - where watchId is the
return value from watchPosition()

The successCallback receives a Position object defined as follows:

interface Position {
readonly attribute double latitude
<http://dev.w3.org/geo/api/spec-source.html#lat> ;
readonly attribute double longitude
<http://dev.w3.org/geo/api/spec-source.html#lon> ;
readonly attribute double altitude
<http://dev.w3.org/geo/api/spec-source.html#altitude> ;
readonly attribute double accuracy
<http://dev.w3.org/geo/api/spec-source.html#accuracy> ;
readonly attribute double altitudeAccuracy
<http://dev.w3.org/geo/api/spec-source.html#altitude-accuracy> ;
readonly attribute double heading
<http://dev.w3.org/geo/api/spec-source.html#heading> 
readonly attribute double velocity
<http://dev.w3.org/geo/api/spec-source.html#velocity> 
readonly attribute DOMTimeStamp timestamp
<http://dev.w3.org/geo/api/spec-source.html#timestamp> ;
};


---------------------------
JON'S EVALUATION
---------------------------

The W3C geolocation APIs are generally fine as is. The things I like
about this API:

* Simple and straightforward
* Good design for future extensibility due to the options object and the
position object
* I think it is good that they have both successCallback and
errorCallback as the first two parameters. This emphasizes to the
developer that he might want to pay close attention to error handling,
such as being denied access to the API for security reasons.
* I think it is good that it the API is placed onto
navigator.geolocation (versus omtp.whatever or OpenAjax.device.whatever)
* I think it is good to allow direct JS access to the most recent
position, such as window.geolocation.lastPosition.latitude, but the W3C
spec needs to warn developers that if they attempt to access that
property and they don't have permission, the property's value will be
"undefined".

My concerns about this API:

(1) Not really a concern per se, but there is nothing in the spec yet
about security.OMTP's efforts will supplement the work done by the W3C.
(2) There needs to be additional query APIs for:
--(a) Checking to see if geolocation APIs are available
--(b) If so, what version of the APIs are available
--(c) Whether this particular application has permission to access those
APIs
(3) There is no support for Bondi's requirements about dynamically
loading of an implementation of particular APIs

Regarding (1), the W3C geolocation spec could say something general
about how a USER AGENT SHOULD provide a secure computing environment
that has careful implementation strategy to protect the user's privacy,
and then references OMTP's security spec as a security framework that
can be used. My thinking is that the W3C isn't a good place to write
security specs. In other words, as a general approach, W3C defines the
APIs and OMTP defines the security model. (Although OMTP should work on
APIs that the W3C isn't moving fast enough on yet and then probably turn
those APIs over to the W3C when the W3C is ready.)

Regarding (2a), the application can just check to see if the
navigator.geolocation object is present (i.e., not "undefined").

Regarding (2b), the W3C simply needs to put a 'version' read-only
property on the Geolocation interface.

Regarding (2c), I suggest that OMTP define the APIs for checking on
whether an application has permission to use the APIs. I would suggest
something like:

* navigator.apiPermissionsCheck(api_uri, successCallback [,
errorCallback [,options]])

where the 'api_uri' is a unique URI for a given API module. The
'options' parameter provides an extensible architecture for the
application to pass in parameters. (One warning to the Bondi folks: the
W3C has some specs with feature URLs already, such as
http://www.w3.org/TR/SVGMobile12/feature.html. My guess is that Rotan
can educate us about other relevant work at the W3C.)

Regarding (3), long-term, I believe browsers will implement device APIs
natively, in which case dynamically attaching an implementation is the
minority case. Therefore, I think it is fine that the primary
geolocation APIs are simple and don't deal with the dynamic loading
features. Instead, dynamic loading should be a separate set of JS APIs.
The geolocation APIs would use the currently loaded implementation.

---------------------------
GOOD MODEL FOR OTHER APIs?
---------------------------

Are the W3C geolocation APIs a good model for other device APIs? I would
say yes. Here is a sketch for how other device APIs might look following
the pattern established by the geolocation APIs. (I used
http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules to help
build this analysis.)

Note that the parameters to the APIs would align with what the W3C has
done with geolocation: successCallback, errorCallback, and options.

Phone call APIs:
* navigator.phone.call() - calls a given number
* navigator.phone.answer() - answers the current call
* navigator.phone.hangup() - terminates the current call
* navigator.phone.{inbox,outbox,missed,all} - list management APIs
(e.g., delete, get details)
* navigator.phone.{watchIncoming(),watchOutgoing(),watchMissed()}

SMS and MMS:
* navigator.{sms,mms}.send() - sends an SMS or MMS
* navigator.{sms,mms}.{inbox,outbox,drafts} - list management APIs
(e.g., delete, get details)
* navigator.{sms,mms}.{watchIncoming(),watchOutgoing()}

EMail:
* navigator.email.send() - sends an email
* navigator.email.{inbox,outbox,drafts,trash} - list management APIs
(e.g., delete, get details)
* navigator.email.{watchIncoming(),watchOutgoing()}
(there will be a number of other email APIs, but I am only providing a
sketch)

AddressBook:
* navigator.contacts: list management APIs (e.g., add, delete, get
details)

Calendar:
* navigator.calendar.{inbox,outbox,drafts,trash} - list management APIs
(e.g., add, delete, get details)
* navigator.calendar.{addReminder()}

Tasks:
* navigator.tasks: list management APIs (e.g., add, delete, get details)
* navigator.tasks.{addReminder()}

Power:
* navigator.power.{powerSource,chargeLevel,criticalBattery,charging,...}
*
navigator.power.watchCriticalBattery(),watchChargeCompleted(),watchPower
SourceChanged(),,...}

Network:
*
navigator.network.{current,cellular,wifi,bluetooth}.{signalStrength,netw
orkType,criticalBattery,roaming,,...}
* navigator.network.watchOutOfCoverage(),,...}

Time:
(Not sure what exists already in the browser, but if we need to invent
something, here goes)
* navigator.clock.{date,time,timezone}
* navigator.clock.watchTimeZoneChange(),,...}

Media:
* navigator.resources.{images,audio, video} - list management APIs
(e.g., delete, get details)
* (need other APIs for capture and annotate)

File I/O:
* W3C is working on APIs in this area

Camera:
navigator.camera.*

Effectors:
* navigator.effectors.mode
* navigator.effectors.setMode()
* navigator.effectors.watchModeChange()

Accelerometer:
* navigator.accelerometer.mode
* navigator.accelerometer.setMode()
* navigator.accelerometer.watchModeChange()

Memory:
* navigator.memory.watchOutOfMemory()

Console:
(Need to see what browser APIs exist already. Firefox/Firebug definitely
has a console object)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080903/88e4cd5f/attachment-0001.html 

From jferrai at us.ibm.com  Wed Sep  3 10:19:40 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 3 Sep 2008 10:19:40 -0700
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs
	and	proposals for how to generalize
In-Reply-To: <D5306DC72D165F488F56A9E43F2045D301B077D5@FTO.mobileaware.com>
Message-ID: <OFF54D073F.A155161A-ON882574B9.005D54D1-882574B9.005F2F4E@us.ibm.com>

Hi Rotan,
Yes, of course, the Geolocation WG does not yet have an approved charter,
and even if the charter is approved as is, there are lots of potential
changes that might happen along the way. Therefore, I agree that from a
formal process perspective, the current geolocation spec technically is
just a proposal. However, given the people who are involved in developing
the spec (e.g., Google, the mapping leader, and Microsoft, also big in
mapping), the degree of public discussion so far, emerging partnership
between W3C and the mobile operator community (in the form of OMTP), and
the prevailing political winds (favorable winds towards HTML5-related
efforts), my prediction is that this particular spec has a really good
chance of remaining largely intact. Of course, others might read the tea
leaves differently. Also, as one of the people at OpenAjax Alliance, I like
the APIs that they have developed, so at least one person at OpenAjax will
be supportive.

I definitely encourage appropriate liaison activities between W3C and
OpenAjax Alliance (and OMTP), whether formal or informal. Right now there
are 3 industry groups that are active in the device APIs area, W3C, OMTP
and OpenAjax Alliance. We should do our best to all march in the same
direction, and as far as I can tell, we all have sincere intents towards
working together in an effective manner. Here is my current thinking about
how to divide the work up:

* W3C develops the API specs that defines some (or maybe all) of the actual
JavaScript device APIs,
* OMTP develops security specs that the W3C can reference. W3C stays out of
security specs. (Traditionally, a difficult area for the W3C)
* OMTP defines JavaScript APIs for technologies that W3C hasn't launched
yet but that the industry needs. They specs might be transitioned to W3C at
a future time.
* OpenAjax reviews all of the above work and provides feedback,
particularly on how well the above work aligns with the needs of Ajax
developers
* OpenAjax might define some JavaScript APIs for technologies that the
industry needs but OMTP and W3C haven't started yet
* OpenAjax might launch on open source JavaScript shim layer activity that
allows JavaScript access to legacy device APIs, but such an effort probably
requires the available of mobile browser plugins such as Aplix's WebVM for
such an effort to be viable.

Jon

mobile-bounces at openajax.org wrote on 09/03/2008 01:10:31 AM:

> One of those inevitable email responses?
>
> Once again I urge caution in referring to this as a W3C
> Specification. It is not. It is a proposal submitted to the W3C for
> consideration as the starting point of work on a geo-location API
> spec. Currently no official group has been given formal
> responsibility for this work. It might even be the case that this
> particular submission is discarded in favour of something better.
>
> Matt Womer is the W3C staff member responsible for steering the
> proposal to set up a group to deal with geo-location. He is also my
> rep for the group I chair, but he is currently on vacation so I have
> no up-to-date information to offer regarding any progress being made
> on geo-location.
>
> It is my understanding that if the geo-location group is set up then
> the proposed spec will be taken under advisement, along with all of
> the technical comments to date on the public mailing list that was
> set up for the purpose. Obviously it would be of benefit for the
> OpenAjax Alliance to add to these comments. Furthermore, assuming
> the group is set up, the OAA can have an ongoing liaison with the
> group through the public channels and possibly through overlapping
> membership (a common informal mechanism that can be efficient and
> fruitful). A formal liaison for this purpose is unnecessary (not
> least because we could do without the paperwork!).
>
> Regarding Jon?s analysis, this is very comprehensive indeed!
> Assuming we can come to a common position on the matters raised, we
> can make a submission to W3C, via the appropriate list, to ensure
> they are considered when the W3C group is eventually formed.
>
> I?d also like to open an informal channel to Matt as soon as
> possible, and when the group is formed then we can arrange a joint
> teleconference to discuss any issues that arise.
>
> Finally, regarding Jon?s comment on ?feature URLs?, the current
> approach within W3C is to use URIs (or increasingly, IRIs) as unique
> identifiers. It is not necessarily the case that an individual URI
> can be dereferenced, either to something human-readable or machine-
> readable. However, some groups take the view that they should
> dereference to something human-readable where the processing model
> does not require the referenced resource to be fetched. If you are
> familiar with DTD or Schema URLs you?ll understand this issue,
> although fetching is generally not performed for ?well known? URLs*
> in order to avoid bottlenecks.
>
> ---Rotan
>
> * Some people use URL and URI interchangeably, though this is not
> strictly correct.
>
> From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
> On Behalf Of Jon Ferraiolo
> Sent: 03 September 2008 00:21
> To: mobile at openajax.org
> Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs
> and proposals for how to generalize
>
> This email contains an analysis of the W3C's latest geolocation spec
> and some thoughts about whether it would be good to pattern other
> device APIs to use the same approaches. The email also makes various
> proposals about several open issues. We could probably spend the
> entire hour on Thursday walking through this email (and the
> inevitable email reponses that will arise between now and then).
>
> These comments refer to the Aug. 15 draft of the Geolocation API
> spec found at:
>
> * http://dev.w3.org/geo/api/spec-source.html
>
> ---------------------------
> EXECUTIVE SUMMARY
> ---------------------------
>
> Here are the key APIs defined in the geolocation spec:
>
> * navigator.geolocation.lastPosition - an object holding most recent
> geolocation position
>
> * navigator.geolocation.getCurrentPosition(successCallback [,
> errorCallback [,options]])
> --- successCallback is the callback function
> --- errorCallback (optional) is the error callback function
> --- options (optional) can include extra parameters and provides for
> future extensibility
>
> * navigator.geolocation.watchPosition(successCallback [,
> errorCallback [,options]])
> --- see getCurrentPosition()
>
> * navigator.geolocation.clearWatch(watchId) - where watchId is the
> return value from watchPosition()
>
> The successCallback receives a Position object defined as follows:
>
> interface Position {
> readonly attribute double latitude;
> readonly attribute double longitude;
> readonly attribute double altitude;
> readonly attribute double accuracy;
> readonly attribute double altitudeAccuracy;
> readonly attribute double heading
> readonly attribute double velocity
> readonly attribute DOMTimeStamp timestamp;
> };
>
>
> ---------------------------
> JON'S EVALUATION
> ---------------------------
>
> The W3C geolocation APIs are generally fine as is. The things I like
> about this API:
>
> * Simple and straightforward
> * Good design for future extensibility due to the options object and
> the position object
> * I think it is good that they have both successCallback and
> errorCallback as the first two parameters. This emphasizes to the
> developer that he might want to pay close attention to error
> handling, such as being denied access to the API for security reasons.
> * I think it is good that it the API is placed onto navigator.
> geolocation (versus omtp.whatever or OpenAjax.device.whatever)
> * I think it is good to allow direct JS access to the most recent
> position, such as window.geolocation.lastPosition.latitude, but the
> W3C spec needs to warn developers that if they attempt to access
> that property and they don't have permission, the property's value
> will be "undefined".
>
> My concerns about this API:
>
> (1) Not really a concern per se, but there is nothing in the spec
> yet about security.OMTP's efforts will supplement the work done by the
W3C.
> (2) There needs to be additional query APIs for:
> --(a) Checking to see if geolocation APIs are available
> --(b) If so, what version of the APIs are available
> --(c) Whether this particular application has permission to access those
APIs
> (3) There is no support for Bondi's requirements about dynamically
> loading of an implementation of particular APIs
>
> Regarding (1), the W3C geolocation spec could say something general
> about how a USER AGENT SHOULD provide a secure computing environment
> that has careful implementation strategy to protect the user's
> privacy, and then references OMTP's security spec as a security
> framework that can be used. My thinking is that the W3C isn't a good
> place to write security specs. In other words, as a general
> approach, W3C defines the APIs and OMTP defines the security model.
> (Although OMTP should work on APIs that the W3C isn't moving fast
> enough on yet and then probably turn those APIs over to the W3C when
> the W3C is ready.)
>
> Regarding (2a), the application can just check to see if the
> navigator.geolocation object is present (i.e., not "undefined").
>
> Regarding (2b), the W3C simply needs to put a 'version' read-only
> property on the Geolocation interface.
>
> Regarding (2c), I suggest that OMTP define the APIs for checking on
> whether an application has permission to use the APIs. I would
> suggest something like:
>
> * navigator.apiPermissionsCheck(api_uri, successCallback [,
> errorCallback [,options]])
>
> where the 'api_uri' is a unique URI for a given API module. The
> 'options' parameter provides an extensible architecture for the
> application to pass in parameters. (One warning to the Bondi folks:
> the W3C has some specs with feature URLs already, such as http:
> //www.w3.org/TR/SVGMobile12/feature.html. My guess is that Rotan can
> educate us about other relevant work at the W3C.)
>
> Regarding (3), long-term, I believe browsers will implement device
> APIs natively, in which case dynamically attaching an implementation
> is the minority case. Therefore, I think it is fine that the primary
> geolocation APIs are simple and don't deal with the dynamic loading
> features. Instead, dynamic loading should be a separate set of JS
> APIs. The geolocation APIs would use the currently loaded implementation.
>
> ---------------------------
> GOOD MODEL FOR OTHER APIs?
> ---------------------------
>
> Are the W3C geolocation APIs a good model for other device APIs? I
> would say yes. Here is a sketch for how other device APIs might look
> following the pattern established by the geolocation APIs. (I used
> http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules to
> help build this analysis.)
>
> Note that the parameters to the APIs would align with what the W3C
> has done with geolocation: successCallback, errorCallback, and options.
>
> Phone call APIs:
> * navigator.phone.call() - calls a given number
> * navigator.phone.answer() - answers the current call
> * navigator.phone.hangup() - terminates the current call
> * navigator.phone.{inbox,outbox,missed,all} - list management APIs
> (e.g., delete, get details)
> * navigator.phone.{watchIncoming(),watchOutgoing(),watchMissed()}
>
> SMS and MMS:
> * navigator.{sms,mms}.send() - sends an SMS or MMS
> * navigator.{sms,mms}.{inbox,outbox,drafts} - list management APIs
> (e.g., delete, get details)
> * navigator.{sms,mms}.{watchIncoming(),watchOutgoing()}
>
> EMail:
> * navigator.email.send() - sends an email
> * navigator.email.{inbox,outbox,drafts,trash} - list management APIs
> (e.g., delete, get details)
> * navigator.email.{watchIncoming(),watchOutgoing()}
> (there will be a number of other email APIs, but I am only providinga
sketch)
>
> AddressBook:
> * navigator.contacts: list management APIs (e.g., add, delete, get
details)
>
> Calendar:
> * navigator.calendar.{inbox,outbox,drafts,trash} - list management
> APIs (e.g., add, delete, get details)
> * navigator.calendar.{addReminder()}
>
> Tasks:
> * navigator.tasks: list management APIs (e.g., add, delete, get details)
> * navigator.tasks.{addReminder()}
>
> Power:
> * navigator.power.{powerSource,chargeLevel,criticalBattery,charging,...}
> * navigator.power.watchCriticalBattery(),watchChargeCompleted(),
> watchPowerSourceChanged(),,...}
>
> Network:
> * navigator.network.{current,cellular,wifi,bluetooth}.
> {signalStrength,networkType,criticalBattery,roaming,,...}
> * navigator.network.watchOutOfCoverage(),,...}
>
> Time:
> (Not sure what exists already in the browser, but if we need to
> invent something, here goes)
> * navigator.clock.{date,time,timezone}
> * navigator.clock.watchTimeZoneChange(),,...}
>
> Media:
> * navigator.resources.{images,audio, video} - list management APIs
> (e.g., delete, get details)
> * (need other APIs for capture and annotate)
>
> File I/O:
> * W3C is working on APIs in this area
>
> Camera:
> navigator.camera.*
>
> Effectors:
> * navigator.effectors.mode
> * navigator.effectors.setMode()
> * navigator.effectors.watchModeChange()
>
> Accelerometer:
> * navigator.accelerometer.mode
> * navigator.accelerometer.setMode()
> * navigator.accelerometer.watchModeChange()
>
> Memory:
> * navigator.memory.watchOutOfMemory()
>
> Console:
> (Need to see what browser APIs exist already. Firefox/Firebug
> definitely has a console object)
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080903/b46c21ed/attachment-0001.html 

From rotan.hanrahan at mobileaware.com  Wed Sep  3 12:55:23 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Wed, 3 Sep 2008 20:55:23 +0100
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation
	APIs	and	proposals for how to generalize
In-Reply-To: <OFF54D073F.A155161A-ON882574B9.005D54D1-882574B9.005F2F4E@us.ibm.com>
References: <D5306DC72D165F488F56A9E43F2045D301B077D5@FTO.mobileaware.com>,
	<OFF54D073F.A155161A-ON882574B9.005D54D1-882574B9.005F2F4E@us.ibm.com>
Message-ID: <7DC3B717-ACB6-473D-A375-4DA7036B50F4@mimectl>

Thanks Jon. We're thinking along the same lines.

As you probably know, one of the key ingredients of good specification management is correct and consistent labeling, which is why the W3C has a well-defined process and a strict publications mechanism. Still, your prediction is probably not far off, for all the reasons you describe. My concern is only to ensure that the first visible contact between OAA and the proposed geo-location group gets off to a good start.

Regarding the possible roles of the three groups you have mentioned, the outline seems reasonable. It wouldn't be true, however, to say that W3C stays out of security specs, given that the consortium has been responsible for SOAP security extensions, the Web Security Context, Cross-site Access Controls, various security requirements for XML encryption, XML key management, Web Services and so on... though I concede that security wouldn't be their speciality. Indeed, it is probably fair to say that W3C groups that are not dedicted to security matters would welcome such work being shouldered by external experts.

Finally, I want to pick up on one particular word from your original message: simple. I completely agree that the primary geo-location API should be simple. There is a danger, however, that the appearance of a W3C group dealing with geo-location API issues might be seen as "the only game in town" and will come under pressure from many directions to have everyone's favourite features included in the specification. That would be dangerous; it would be a recipe for continuous argument and perpetual procrastination. Perhaps one of the best things we could do for the nebulous working group is to give it some opinion on what we would consider to be the "bare minimum" for a working geo-location API. If they can create such an API in a reasonable time, that would be a success. We need the geo-location "axioms". The orthogonal atomic features. No more, no less.

I'm no GL expert, so perhaps others could jump in here to separate the must-haves from the nice-to-haves.

---Rotan





From: Jon Ferraiolo
Sent: Wed 03/09/2008 18:19
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: Re: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and proposals for how to generalize


Hi Rotan,
Yes, of course, the Geolocation WG does not yet have an approved charter, and even if the charter is approved as is, there are lots of potential changes that might happen along the way. Therefore, I agree that from a formal process perspective, the current geolocation spec technically is just a proposal. However, given the people who are involved in developing the spec (e.g., Google, the mapping leader, and Microsoft, also big in mapping), the degree of public discussion so far, emerging partnership between W3C and the mobile operator community (in the form of OMTP), and the prevailing political winds (favorable winds towards HTML5-related efforts), my prediction is that this particular spec has a really good chance of remaining largely intact. Of course, others might read the tea leaves differently. Also, as one of the people at OpenAjax Alliance, I like the APIs that they have developed, so at least one person at OpenAjax will be supportive.

I definitely encourage appropriate liaison activities between W3C and OpenAjax Alliance (and OMTP), whether formal or informal. Right now there are 3 industry groups that are active in the device APIs area, W3C, OMTP and OpenAjax Alliance. We should do our best to all march in the same direction, and as far as I can tell, we all have sincere intents towards working together in an effective manner. Here is my current thinking about how to divide the work up:

* W3C develops the API specs that defines some (or maybe all) of the actual JavaScript device APIs
* OMTP develops security specs that the W3C can reference. W3C stays out of security specs. (Traditionally, a difficult area for the W3C)
* OMTP defines JavaScript APIs for technologies that W3C hasn't launched yet but that the industry needs. They specs might be transitioned to W3C at a future time.
* OpenAjax reviews all of the above work and provides feedback, particularly on how well the above work aligns with the needs of Ajax developers
* OpenAjax might define some JavaScript APIs for technologies that the industry needs but OMTP and W3C haven't started yet
* OpenAjax might launch on open source JavaScript shim layer activity that allows JavaScript access to legacy device APIs, but such an effort probably requires the available of mobile browser plugins such as Aplix's WebVM for such an effort to be viable.

Jon


[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080903/93a3f456/attachment.html 

From jferrai at us.ibm.com  Wed Sep  3 18:09:56 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Wed, 3 Sep 2008 18:09:56 -0700
Subject: [OpenAjaxMobile] Thursday phone call: noon US-PT, 3pm US-DT, 8pm UK,
	9pm Paris
Message-ID: <OF481201DE.652CC3AE-ON882574BA.000606F0-882574BA.00066736@us.ibm.com>



Time slot #2 got the most votes.

Time: Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris

Topics:
* Review OMTP Bondi
* Latest news about activities at W3C
* Jon's review of W3C geolocation and whether those API approaches can be
applied generally
* What role OpenAjax Alliance might play in this space going forward

-------------------------------------

   Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414

  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205 5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205 5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300





----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 09/03/2008 06:05 PM
-----
                                                                           
             Jon                                                           
             Ferraiolo/Menlo                                               
             Park/IBM at IBMUS                                             To 
             Sent by:                  mobile at openajax.org                 
             mobile-bounces at op                                          cc 
             enajax.org                                                    
                                                                   Subject 
                                       [OpenAjaxMobile] RSVP: Phone call   
             09/01/2008 04:11          time slots for Thursday 4 Sept or   
             PM                        Friday 5 Sept                       
                                                                           
                                                                           
             Please respond to                                             
             OpenAjax Alliance                                             
              discussion list                                              
              on Mobile Ajax                                               
             <mobile at openajax.                                             
                   org>                                                    
                                                                           
                                                                           




We were planning to have a phone call this Thursday, but it turns out that
I am presenting at a conference at our normal phone call time (9am
Thursday).

Could people please RSVP with their availability for the following time
slots for a Mobile TF phone call this week:

1) Thursday, 4Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris
2) Thursday, 4Sept., noon US-PT, 3pm US-DT, 8pm UK, 9pm Paris
3) Friday, 5Sept., 9am US-PT, noon US-DT, 5pm UK, 6pm Paris
4) Friday, 5Sept., 10am US-PT, 1pm US-DT, 6pm UK, 7pm Paris
5) Friday, 5Sept., 11am US-PT, 2pm US-DT, 7pm UK, 8pm Paris

The main topic will be reviewing the status of the OMTP Bondi project,
latest news about activities at W3C and what role OpenAjax Alliance might
play going forward.

Thanks.
Jon




_______________________________________________
mobile mailing list
mobile at openajax.org
http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080903/5d5dad72/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic29636.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080903/5d5dad72/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080903/5d5dad72/attachment-0003.gif 

From rotan.hanrahan at mobileaware.com  Thu Sep  4 13:13:56 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Thu, 4 Sep 2008 21:13:56 +0100
Subject: [OpenAjaxMobile] Minutes - caution
In-Reply-To: <OF481201DE.652CC3AE-ON882574BA.000606F0-882574BA.00066736@us.ibm.com>
References: <OF481201DE.652CC3AE-ON882574BA.000606F0-882574BA.00066736@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301B079F5@FTO.mobileaware.com>

Hi Jon,

 

Just to make sure that dirty linen isn't aired in public, could you not
mention too much about the "political tension" in W3C regarding the
geo-location work in the minutes of today's call. Preferably none at
all. :) I'm conscious of how delicate a balance these things can be from
time to time, and several feathers need to be unruffled first.

 

---Rotan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080904/7ad16bc1/attachment.html 

From rotan.hanrahan at mobileaware.com  Thu Sep  4 13:51:11 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Thu, 4 Sep 2008 21:51:11 +0100
Subject: [OpenAjaxMobile] XML Languages
In-Reply-To: <OF481201DE.652CC3AE-ON882574BA.000606F0-882574BA.00066736@us.ibm.com>
References: <OF481201DE.652CC3AE-ON882574BA.000606F0-882574BA.00066736@us.ibm.com>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301BC7D3A@FTO.mobileaware.com>

Just to put into writing what I said about XML language design today, in
the context of assessing XACML...

 

I describe four factors to consider when designing a language that uses
XML:

 

1.       The complexity of human authoring. Will the language be written
in its raw format by a human? If so, the more complex the language, the
greater the chance of errors. Good tools and validators can help, if
they are available.

2.       The complexity of processing the XML. If it is to be consumed
by a machine, then the structure of the representations should reflect
the manner in which the data is best processed. Will it require a single
or multiple passes? Does it involve deep structures? Will the values
require exotic characters (in which case element attributes should be
avoided)? There are no hard and fast rules I can offer here, because
each use case brings its own set of challenges.

3.       Expressivity. A language that is too loose (i.e. can express a
lot) can demand much more of a processor than a language with a narrow
focus. Sometimes you only need a small amount, in which case you can
trim the fat.

4.       Human readability. Will the instances of this XML language be
read by people? If so, have you considered how the instances would be
transformed (e.g. via XSLT)? Would you be satisfied that reading the raw
XML would convey the right information to the reader?

 

There may be additional  considerations beyond the broad four above, but
my advice (based on years of floating around the XML merry-go-round in
W3C) is to keep those factors in mind when you are designing from
scratch, or evaluating a new language.

 

---Rotan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080904/7b9ae241/attachment.html 

From jferrai at us.ibm.com  Sun Sep  7 12:00:06 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Sun, 7 Sep 2008 12:00:06 -0700
Subject: [OpenAjaxMobile] Minutes 2008-09-04
Message-ID: <OF29114BDA.DC9EFBFD-ON882574BD.0068208B-882574BD.00686139@us.ibm.com>



Sorry it took me a few days to post the minutes.

URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-04

Mobile Minutes 2008-09-04


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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080907/4d7bd65f/attachment.html 

From paddy.byers at gmail.com  Mon Sep 15 02:11:32 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Mon, 15 Sep 2008 10:11:32 +0100
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and
	proposals for how to generalize
In-Reply-To: <OF11B8BC52.5138819B-ON882574B8.0063BAE0-882574B8.00803F3F@us.ibm.com>
References: <OF11B8BC52.5138819B-ON882574B8.0063BAE0-882574B8.00803F3F@us.ibm.com>
Message-ID: <59db1b5a0809150211o76defed2p81cf259bf00465bc@mail.gmail.com>

Hi,

I like the callback idea, in that the API is the same irrespective of
whether the implementation works synchronously or asynchronously. In
principle, any given implementation could elect either to complete
synchronously or asynchronously depending on the circumstances of the
request.

However, in effect this forces all code to be written to expect asynchronous
behaviour, which can end up with things a lot more awkward. For example,
suppose you wanted to do a sequence of things conventionally:

doThis();
doThat();
doTheOther();

With the callback-possibly-asynchronous style of API (if each successive
call depends on results of the previous call) you'd need to do:

doThis(function() {doThat(function() {doTheOther();});});

So what happens when you want to iterate, eg in the conventional style you'd
do:

while(success) {
  success = pim.addContact(contactsToBeAdded[index++]);
}

?

It seems there isn't an obvious analogue - you can write something that is
potentially recursive (if it happens that the addContact API is
synchronous), or you could initiate a series of potentially asynchronous
calls in parallel and wait for all the results to arrive.

I think if a call is known to be either synchronous or known to be
asynchronous it definitely helps to know, and typically user code would be
written one way or another depending on the expected behaviour. I agree it
is neater to capture both types of behaviour in a single style of API, but
you can also argue that the behaviour should be explicit in the form of the
API, if it is defined, to avoid any possible confusion (either on the part
of users of the API or implementers).

Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080915/6210bd13/attachment.html 

From jferrai at us.ibm.com  Mon Sep 15 09:17:21 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Mon, 15 Sep 2008 09:17:21 -0700
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs
	and	proposals for how to generalize
In-Reply-To: <59db1b5a0809150211o76defed2p81cf259bf00465bc@mail.gmail.com>
Message-ID: <OF3269D56D.EEE485C0-ON882574C5.0058E2D1-882574C5.00597AFA@us.ibm.com>


Hi Paddy,
Yes, good points.

I thought that we had discussed async vs sync back in the May/June
timeframe when I had originally suggested that all APIs should use an async
model, but people pointed out similar concerns as you have below, and as I
remember the async proponents (perhaps just me) conceded that in some cases
a synchronous APIs makes sense. But if doThis(), doThat() and doTheOther()
all have potential response delays, then the developer is stuck with having
to deal with the async programming complexities.

Jon





                                                                           
             "Paddy Byers"                                                 
             <paddy.byers at gmai                                             
             l.com>                                                     To 
             Sent by:                  "OpenAjax Alliance discussion list  
             mobile-bounces at op         on Mobile Ajax"                     
             enajax.org                <mobile at openajax.org>               
                                                                        cc 
                                                                           
             09/15/2008 02:11                                      Subject 
             AM                        Re: [OpenAjaxMobile] Analysis of    
                                       W3C's latest geolocation APIs and   
                                       proposals for how to generalize     
             Please respond to                                             
             OpenAjax Alliance                                             
              discussion list                                              
              on Mobile Ajax                                               
             <mobile at openajax.                                             
                   org>                                                    
                                                                           
                                                                           




Hi,

I like the callback idea, in that the API is the same irrespective of
whether the implementation works synchronously or asynchronously. In
principle, any given implementation could elect either to complete
synchronously or asynchronously depending on the circumstances of the
request.

However, in effect this forces all code to be written to expect
asynchronous behaviour, which can end up with things a lot more awkward.
For example, suppose you wanted to do a sequence of things conventionally:

doThis();
doThat();
doTheOther();

With the callback-possibly-asynchronous style of API (if each successive
call depends on results of the previous call) you'd need to do:

doThis(function() {doThat(function() {doTheOther();});});

So what happens when you want to iterate, eg in the conventional style
you'd do:

while(success) {
  success = pim.addContact(contactsToBeAdded[index++]);
}

?

It seems there isn't an obvious analogue - you can write something that is
potentially recursive (if it happens that the addContact API is
synchronous), or you could initiate a series of potentially asynchronous
calls in parallel and wait for all the results to arrive.

I think if a call is known to be either synchronous or known to be
asynchronous it definitely helps to know, and typically user code would be
written one way or another depending on the expected behaviour. I agree it
is neater to capture both types of behaviour in a single style of API, but
you can also argue that the behaviour should be explicit in the form of the
API, if it is defined, to avoid any possible confusion (either on the part
of users of the API or implementers).

Paddy_______________________________________________
mobile mailing list
mobile at openajax.org
http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080915/437bb6a6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080915/437bb6a6/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic08606.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080915/437bb6a6/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080915/437bb6a6/attachment-0002.gif 

From paddy.byers at gmail.com  Mon Sep 15 09:59:59 2008
From: paddy.byers at gmail.com (Paddy Byers)
Date: Mon, 15 Sep 2008 17:59:59 +0100
Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and
	proposals for how to generalize
In-Reply-To: <OF3269D56D.EEE485C0-ON882574C5.0058E2D1-882574C5.00597AFA@us.ibm.com>
References: <59db1b5a0809150211o76defed2p81cf259bf00465bc@mail.gmail.com>
	<OF3269D56D.EEE485C0-ON882574C5.0058E2D1-882574C5.00597AFA@us.ibm.com>
Message-ID: <59db1b5a0809150959x8685ecaxb3ca83c6fc1254ff@mail.gmail.com>

Hi,

> I thought that we had discussed async vs sync back in the May/June
> timeframe when I had originally suggested that all APIs should use an async
> model, but people pointed out similar concerns as you have below, and as I
> remember the async proponents (perhaps just me) conceded that in some cases
> a synchronous APIs makes sense. But if doThis(), doThat() and doTheOther()
> all have potential response delays, then the developer is stuck with having
> to deal with the async programming complexities.
>
Yes - if the methods really are asynchronous then the programmer has to deal
with it.

All I was saying was:
- the code that expects async is necessarily a lot uglier than the code that
expects sync;
- therefore, if it is known that a method really is synchronous then it
would be good to make it explicit and document that in the API;
- there might be an advantage in having a different style of API to make it
more explicit than just by documentation.

I know I agreed with it last time around :) but having tried it out for real
I realise it can end up being pretty messy.

Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080915/c69f316f/attachment.html 

From Andrew.Sledd at ikivo.com  Thu Sep 18 01:21:08 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Thu, 18 Sep 2008 10:21:08 +0200
Subject: [OpenAjaxMobile] Reminder: No call today. Next call 25th of
	September. /eom
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDF50FF2@SESTHSRV10.zoomon.local>

 
 

________________________________________________
Andrew Sledd
Ikivo AB 
?stermalmsgatan 87 C
SE-114 59 Stockholm
Sweden
Mobile: +46 70 305  7712
Fax: +46 8 534 811 86
Email: andrew.sledd at ikivo.com
<http://www.ikivo.com/> http://www.ikivo.com <http://www.ikivo.com/> 


The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080918/7a729a32/attachment.html 

From jferrai at us.ibm.com  Mon Sep 22 08:47:04 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Mon, 22 Sep 2008 08:47:04 -0700
Subject: [OpenAjaxMobile] Mobile Device APIs Style Guide
Message-ID: <OFFB1A32E4.141AA4C8-ON882574CC.00568D3A-882574CC.0056B533@us.ibm.com>


In preparation for Thursday's phone call, I wrote a first draft of a style
guide with a set of guidelines for how JavaScript APIs to mobile device
services should look.

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

I am expecting lively discussion on Thursday. :-)

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

From Andrew.Sledd at ikivo.com  Thu Sep 25 03:55:21 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Thu, 25 Sep 2008 12:55:21 +0200
Subject: [OpenAjaxMobile] Reminder: Conf call information
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDF8E32F@SESTHSRV10.zoomon.local>

Hi all,
Just a reminder of the call in details and some links to relevant
discussion items.
Andy
 
Minutes of previous telcon 
http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-04
 
See also Jon's Mobile Device APIs Stype Guide on the wiki (link inline
below).
 
Call Time:  9amPT, noonET, 5pm London, 6pm Paris
Passcode:           460566

Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205
5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205
5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: den 22 september 2008 17:47
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Mobile Device APIs Style Guide



In preparation for Thursday's phone call, I wrote a first draft of a
style guide with a set of guidelines for how JavaScript APIs to mobile
device services should look.

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

I am expecting lively discussion on Thursday. :-)

Jon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080925/2eb86813/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT1855448.txt
Url: http://openajax.org/pipermail/mobile/attachments/20080925/2eb86813/attachment.txt 

From rotan.hanrahan at mobileaware.com  Thu Sep 25 04:45:14 2008
From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan)
Date: Thu, 25 Sep 2008 12:45:14 +0100
Subject: [OpenAjaxMobile] Reminder: Conf call information
In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDF8E32F@SESTHSRV10.zoomon.local>
References: <234EB4699C751A4A95DF4FD8D041BBFDF8E32F@SESTHSRV10.zoomon.local>
Message-ID: <D5306DC72D165F488F56A9E43F2045D301C26E88@FTO.mobileaware.com>

Regarding checking Jon's draft against existing JavaScript APIs, the
draft geolocation API is not the only kid on the block. (The Geolocation
group is now formally calling for participants, so we can expect "real"
work to commence soon.) Anyway, there are a few other APIs that you can
take a look at, such as these two:

 

Selectors API

http://dev.w3.org/2006/webapi/selectors-api/

 

DCCI (which binds to JavaScript, among other things)

http://www.w3.org/TR/DPF/

 

In many cases, APIs intended for widespread use beyond a single
implementation language are specified in (some flavour of) IDL. To see
if these APIs are available in JavaScript you'll need to search for
implementation reports. For the moment, the evolving geolocation API has
JavaScript in mind as the target implementation environment, but it
would not surprise me if some generalisations were to creep in. The
Widgets API is also being positioned for use with JavaScript
(ECMAScript) http://www.w3.org/TR/2007/WD-widgets-reqs-20070705/ 

 

As it's now almost certain that I won't be able to attend today's call,
I'll give here a few of my comments on Jon's first draft.

 

*         Separate the guidelines from any specific evaluation of an
API. This means take the geolocation material out to a separate page.

*         To facilitate the above, give every guideline a unique code. I
recommend that you adopt the approach used by the MWI Best Practices
group. See this: http://www.w3.org/TR/mobile-bp/

*         I very much approve of the high-level items (Simplicity,
Directness, Consistency etc) being prominent in the text. I would add a
short introductory text to each one of these to explain why they are
requirements. For example:

o   Simplicity means the API is easy to adopt, less prone to developer
errors and easier to test. Simplicity is not the same as small, though
often a simple API is also small. A simple API should not depend on too
much prior knowledge/experience in order to be immediately useful to a
typical developer. Constructs in a simple API should require few
reserved names, and few parameters. Unless for obvious convenience, a
simple API will have only one way to exercise each significant function
(i.e. feature orthogonality).

*         I'm not so sure that API handlers are necessarily evil. (As
I'm probably not going to be on the call, perhaps this can be expanded
upon via email?)

*         There is probably a good argument for expanding on the Async
vs Sync part of the doc, possibly to offer some suggestions as to when
each of the approaches is appropriate. The draft text suggests that in
every situation, one approach will be favourable to the other, but I
wonder if there are cases where both could be useful and it may be
better for the developer (who is closer to the specific problem domain)
to decide which approach to use. (Imagine the chaos if the network stack
designers had decided that sync/async was preferable to async/sync.)

*         The mention of the callback to indicate success/failure
reminds me of my personal gripe that the issue of reporting abnormal
behaviour is constantly present but seldom addressed. It would be good
if all APIs were to report failure in the same way, as this would
provide for a much more consistent debugging environment.

*         On the issue of versioning, many APIs can identify the
specification they implement by reporting the IRI (URL) of the
specification. For example, implementations of the DDR API (recently
published as a Proposed Rec) return a String (which implementers agree
should incorporate the URL of the specification, in the same way that
reported DDR Vocabularies also report their IRIs). Returning a number is
not as specific, unless some agency is made responsible for the number
increments.
http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/#sec-Service-getImp
lementationVersion 

*         Regarding the use of associative arrays for extensibility,
this is something that helps with backwards compatibility (as the
additional data would be ignored by older systems). The use of
associative arrays does not itself prevent newer versions of an API from
coming into being, and it wouldn't be a problem to completely re-invent
an API so long as there was a reliable means of detecting which versions
you were using, and were able to use whatever versions you discovered.
As this isn't always the case, backwards compatibility is seen as
desirable. However, as many versions roll over and the years go by,
backwards compatibility can be a barrier to innovation. This is a tough
call.

 

OK, that's enough for now. Again, my apologies for not being able to
make the call today.

 

---Rotan.

 

 

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Andrew Sledd
Sent: 25 September 2008 11:55
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: [OpenAjaxMobile] Reminder: Conf call information

 

Hi all,

Just a reminder of the call in details and some links to relevant
discussion items.

Andy

 

Minutes of previous telcon
http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-04

 

See also Jon's Mobile Device APIs Stype Guide on the wiki (link inline
below).

 

Call Time:  9amPT, noonET, 5pm London, 6pm Paris

Passcode:           460566
 
Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205
5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205
5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

 

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: den 22 september 2008 17:47
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Mobile Device APIs Style Guide

In preparation for Thursday's phone call, I wrote a first draft of a
style guide with a set of guidelines for how JavaScript APIs to mobile
device services should look.

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

I am expecting lively discussion on Thursday. :-)

Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080925/a2531670/attachment-0001.html 

From Andrew.Sledd at ikivo.com  Thu Sep 25 05:38:21 2008
From: Andrew.Sledd at ikivo.com (Andrew Sledd)
Date: Thu, 25 Sep 2008 14:38:21 +0200
Subject: [OpenAjaxMobile] Reminder: Conf call information
In-Reply-To: <D5306DC72D165F488F56A9E43F2045D301C26E88@FTO.mobileaware.com>
Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDF8E38D@SESTHSRV10.zoomon.local>

Thanks Rotan.
 
We will review your comments briefly during the call.
 
Andy

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Rotan Hanrahan
Sent: den 25 september 2008 13:45
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: Re: [OpenAjaxMobile] Reminder: Conf call information



Regarding checking Jon's draft against existing JavaScript APIs, the
draft geolocation API is not the only kid on the block. (The Geolocation
group is now formally calling for participants, so we can expect "real"
work to commence soon.) Anyway, there are a few other APIs that you can
take a look at, such as these two:

 

Selectors API

http://dev.w3.org/2006/webapi/selectors-api/

 

DCCI (which binds to JavaScript, among other things)

http://www.w3.org/TR/DPF/

 

In many cases, APIs intended for widespread use beyond a single
implementation language are specified in (some flavour of) IDL. To see
if these APIs are available in JavaScript you'll need to search for
implementation reports. For the moment, the evolving geolocation API has
JavaScript in mind as the target implementation environment, but it
would not surprise me if some generalisations were to creep in. The
Widgets API is also being positioned for use with JavaScript
(ECMAScript) http://www.w3.org/TR/2007/WD-widgets-reqs-20070705/ 

 

As it's now almost certain that I won't be able to attend today's call,
I'll give here a few of my comments on Jon's first draft.

 

*         Separate the guidelines from any specific evaluation of an
API. This means take the geolocation material out to a separate page.

*         To facilitate the above, give every guideline a unique code. I
recommend that you adopt the approach used by the MWI Best Practices
group. See this: http://www.w3.org/TR/mobile-bp/

*         I very much approve of the high-level items (Simplicity,
Directness, Consistency etc) being prominent in the text. I would add a
short introductory text to each one of these to explain why they are
requirements. For example:

o   Simplicity means the API is easy to adopt, less prone to developer
errors and easier to test. Simplicity is not the same as small, though
often a simple API is also small. A simple API should not depend on too
much prior knowledge/experience in order to be immediately useful to a
typical developer. Constructs in a simple API should require few
reserved names, and few parameters. Unless for obvious convenience, a
simple API will have only one way to exercise each significant function
(i.e. feature orthogonality).

*         I'm not so sure that API handlers are necessarily evil. (As
I'm probably not going to be on the call, perhaps this can be expanded
upon via email?)

*         There is probably a good argument for expanding on the Async
vs Sync part of the doc, possibly to offer some suggestions as to when
each of the approaches is appropriate. The draft text suggests that in
every situation, one approach will be favourable to the other, but I
wonder if there are cases where both could be useful and it may be
better for the developer (who is closer to the specific problem domain)
to decide which approach to use. (Imagine the chaos if the network stack
designers had decided that sync/async was preferable to async/sync.)

*         The mention of the callback to indicate success/failure
reminds me of my personal gripe that the issue of reporting abnormal
behaviour is constantly present but seldom addressed. It would be good
if all APIs were to report failure in the same way, as this would
provide for a much more consistent debugging environment.

*         On the issue of versioning, many APIs can identify the
specification they implement by reporting the IRI (URL) of the
specification. For example, implementations of the DDR API (recently
published as a Proposed Rec) return a String (which implementers agree
should incorporate the URL of the specification, in the same way that
reported DDR Vocabularies also report their IRIs). Returning a number is
not as specific, unless some agency is made responsible for the number
increments.
http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/#sec-Service-getImp
lementationVersion 

*         Regarding the use of associative arrays for extensibility,
this is something that helps with backwards compatibility (as the
additional data would be ignored by older systems). The use of
associative arrays does not itself prevent newer versions of an API from
coming into being, and it wouldn't be a problem to completely re-invent
an API so long as there was a reliable means of detecting which versions
you were using, and were able to use whatever versions you discovered.
As this isn't always the case, backwards compatibility is seen as
desirable. However, as many versions roll over and the years go by,
backwards compatibility can be a barrier to innovation. This is a tough
call.

 

OK, that's enough for now. Again, my apologies for not being able to
make the call today.

 

---Rotan.

 

 

 

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Andrew Sledd
Sent: 25 September 2008 11:55
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: [OpenAjaxMobile] Reminder: Conf call information

 

Hi all,

Just a reminder of the call in details and some links to relevant
discussion items.

Andy

 

Minutes of previous telcon
http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-04

 

See also Jon's Mobile Device APIs Stype Guide on the wiki (link inline
below).

 

Call Time:  9amPT, noonET, 5pm London, 6pm Paris

Passcode:           460566
 
Conference Access:
  Toll free:                                         1-888-619-1583
  Toll:                                              1-719-457-1414
 
  International toll free - Argentina:               0800 666 3149
  International toll free - Australia:               1 800 105 680
  International toll free - Austria:                 0 800 291 941
  International toll free - Belgium:                 0 800 75 240
  International toll free - Chile:                   123 0020 9725
  International toll free - China, Northern Region:  10 800 714 1201
  International toll free - China, Southern Region:  10 800 140 1180
  International toll free - Colombia:                01 800 518 0789
  International toll free - Costa Rica:              0800 015 0616
  International toll free - Czech Republic:          800 700 294
  International toll free - Denmark:                 80 886 215
  International toll free - Dominican Republic:      1 888 751 4488
  International toll free - Ecuador:                 1 800 020 321
  International toll free - France:                  0 800 90 0161
  International toll free - Germany:                 0 800 181 9019
  International toll free - Greece:                  00 800 161 2205
5955
  International toll free - Hong Kong:               800 901 110
  International toll free - Hungary:                 06 800 162 50
  International toll free - India:                   000 800 1006 980
  International toll free - Indonesia:               001 803 017 5955
  International toll free - Ireland:                 1 800 760 547
  International toll free - Israel:                  1 809 246 041
  International toll free - Italy:                   800 873 739
  International toll free - Japan:                   00531 16 0844
  International toll free - Lithuania:               8 800 3 05 25
  International toll free - Luxembourg:              800 2 7665
  International toll free - Malaysia:                1 800 813 714
  International toll free - Mexico:                  001 800 514 5955
  International toll free - Monaco:                  800 93 416
  International toll free - Netherlands:             0 800 023 5303
  International toll free - New Zealand:             0 800 451 015
  International toll free - Norway:                  800 196 65
  International toll free - Panama:                  00 800 226 5955
  International toll free - Poland:                  00 800 111 49 58
  International toll free - Portugal:                800 819 728
  International toll free - Russia:                  810 800 2704 1012
  International toll free - Singapore:               800 101 2002
  International toll free - Slovenia:                0 800 80203
  International toll free - South Africa:            0 800 980 988
  International toll free - South Korea:             003 0813 1963
  International toll free - Spain:                   900 947 604
  International toll free - Sweden:                  02 079 7556
  International toll free - Switzerland:             0 800 564 397
  International toll free - Thailand:                001 800 156 205
5955
  International toll free - Trinidad-Tobago:         1 800 205 5955
  International toll free - UK:                      0 808 101 1146
  International toll free - Uruguay:                 0004 019 0188
  International toll free - Venezuela:               0 800 100 8300

 

________________________________

From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: den 22 september 2008 17:47
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Mobile Device APIs Style Guide

In preparation for Thursday's phone call, I wrote a first draft of a
style guide with a set of guidelines for how JavaScript APIs to mobile
device services should look.

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

I am expecting lively discussion on Thursday. :-)

Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080925/e12808c9/attachment-0001.html 

From jferrai at us.ibm.com  Sat Sep 27 05:12:32 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Sat, 27 Sep 2008 05:12:32 -0700
Subject: [OpenAjaxMobile] Minutes 2008-09-25 and updated style guide
Message-ID: <OFEDFF0FEE.1C2CFACE-ON882574D1.0042846C-882574D1.00431109@us.ibm.com>



At the bottom of this email are the minutes from our Thursday phone call.

During the phone call, we discussed the Mobile Device APIs Style Guide:

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

I have now updated the style guide to reflect the discussion on Thursday.
We decided to leave the document mostly intact because the community (both
OMTP and W3C) has already begun discussing its contents, and we wanted to
minimize confusion by having the document change too much in the middle of
debate of its merits. To see what changes I made, here is the Change Log
(which is now at the top of the document):

---------------------------------
Change log

2008-09-26


Various changes to reflect discussion at the 2008-09-25 phone call.
      Beefed up the introduction to attempt to be clear about what this
      document is trying to do and what it isn't trying to do. Emphasize
      that the document was created at the request of the OMTP to reflect
      the "Ajax/JavaScript perspective". Indicate that we recognize that
      there are other perspectives that OMTP and W3C need to take into
      account, also.
      In the section on Requesting and Checking Permissions, removed our
      previous recommendations for canUse() and apiPermissionsCheck() and
      instead this section now simply attempts to describe the requirement
      for browser-based applications to be able to request the use of
      device APIs
      Added some editorial comments to the Directness section to reflect
      discussion during the 2008-09-25 phone call
      Added a recommendation that OMTP define its APIs on its own global
      object (e.g., window.bondi) in order to prevent conflict from future
      overlapping specs from the W3C
      Add new section about error handling with sync APIs, where we
      identify some alternatives, but then say there isn't one preferred
      way.
---------------------------------

Below are the minutes from Thursday's phone call:

--------------------------------

Mobile Minutes 2008-09-25


URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-25



Attendees
      Paddy Byers, Aplix
      Andy Sledd, Ikivo
      Jon Ferraiolo, IBM
      Adam Peller, IBM (and Dojo)

Minutes


(reviewing
http://www.openajax.org/member/wiki/Mobile_Device_APIs_Style_Guide_


Andy: Rotan suggests IDL. I thought we talked about that last phone call.


Jon: (Looking at minutes) Yes. Last time Rotan suggested that we just focus
on JavaScript and not worry about other languages.


Andy: Right after you say that OpenAjax Alliance focuses only on JavaScript


Jon: The two audiences for the style guide are OMTP and W3C. We were asked
to do this style guide by OMTP folks, Nick Allott and David Pollington in
particular. OMTP is mainly interested in JavaScript, right?


Paddy: Yes, I believe that is so.


Jon: On the W3C side, times have change in the past 13 years. When DOM
started, Java applets were a much bigger thing and JavaScript was just for
small things in the browser. Now, people are trying to use JavaScript for
major development. ECMA4 was an attempt to make JavaScript into a major
language. More recently, there is a race to speed JavaScript performance,
with JITs and everything. It's now OK for real programmers to use
JavaScript. So even on the W3C side, JavaScript might have more importance
than previously.


Andy: OK, let's have others look at other languages.


Jon: I suggest that we include in the intro more explicit comments to
emphasize that we are focused only on JavaScript.


Paddy: A couple of personal reactions and a report on some recent chat at
the W3C. First issue is directness. At the W3C, there are a couple of
different opinions. One said that directness was good. Another said this
contradicts the current draft of the widgets spec. There, you have a config
doc which lists the API dependencies where each feature has an API. You
specify the API you want to use with a shortname and an URI, similar to XML
namespaces. This makes the API available to the widget but doesn't bind
into the JS environment. Then the widget does a getfeature and then gets
the root object of that API.


Paddy: This is part of a draft document that is still under discussion. The
advantage is that you don't have to manage conflicts over multiple APIs
wanting to be at the same location. Jon's proposal contradicts the latest
widgets proposal.


Andy: I assume the directness recommendation was intentional, but was the
contradiction with W3C Widgets intentional?


Jon: The directness recommendation was most definitely intentional. The
reason we did the style guide was because we were asked to express the
point of view of the Ajax/JavaScript developer community. There has been a
clear consensus among the Ajax toolkits that has emerged around making APIs
available in a direct manner. I mentioned an example of how Dojo went from
indirect APIs in dojo 0.4 for client-server communications to direct apis
in dojo 1.0.


Paddy: The webapps discussion list also talked about the risk of API
hijacking.


Adam: There is work at ECMA 3.1 to have the ability to seal off certain
objects.


Jon: The risk of hijacking a JavaScript object is across most of JavaScript
today. It wouldn't be a new thing for device APIs. JavaScript today is very
flexible.


Paddy/Adam: (comments about how different browsers offer different
abilities and constraints around changing the JavaScript environment, how
some browsers allow changing the prototypes for built-in objects such as
Array)


Adam: Next draft of ECMA will attempt to provide more consistency


Jon: The fundamental basis of web security is that a user goes to a web
site and then the web site controls the bits that come down to the user's
browser. Since the web site controls the content, the web site can prevent
hijacking.


Adam: Except for mashups, for which there are isolation approaches, such as
what OpenAjax is doing.


Jon: Yes. But I'm not buying the argument that requiring indirection before
getting access to APIs provides a tangible security advantage.


Adam: Also, ECMA might be coming in same timeframe.


Paddy: Takes a long time to get new features into browsers. Can't have a
dependency on EMCA.


Adam: Yes, can't assume that these new ECMA features will be available. But
we can say that our problems are the same as the rest of the Web.


Paddy: That's one topic. It would be good to continue to watch webapps and
BONDI discussions.


Paddy: We have just made changes to WebVM to match W3C Widgets.


(Jon/Paddy try to find the load/bind features in the W3C Widgets specs but
can't find them. Paddy will research and point out which specs have these
APIs.)


Jon: Adam, as a long-time developer of an Ajax toolkit, what do you think
about the directness issue?


Adam: Complex APIs tend to collapse from their own weight, with load and
register complexities. These approaches are foreign the JavaScript and Ajax
developers. You are going down the road towards something like CORBA.


Jon: Not that there is anything wrong with the more complex approaches.
It's just that we were asked to represent the perspective of the JavaScript
developer community and produce a style guide that aligns with their
collective point of view.


Adam/Jon: The Ajax community has gravitated to simple and direct APIs.


Adam: Granted, the Ajax community isn't dealing with host environments.


Jon: How about we emphasize in the preface that our recommendations reflect
the point of view of the Ajax community, which is just one point of view
among others. Also, emphasize that our recommendations reflect the
requirements from JavaScript developers, but there are other requirements
that we aren't taking into account.


Paddy: I think that's OK.


Paddy: getfeature avoids the need to manage namespaces. Allows two
different APIs for same feature without worrying about conflicts.


Andy: Should we say that we realize that our proposal not allow multiple
APIs for same feature?


Paddy: Advice to BONDI: put APIs onto a bondi. object but recognize that
those APIs might move to a different place in the future


Jon: For example, move to navigator object when W3C takes over a spec?


Paddy: Yes


Jon: Other things?


Paddy: People have objected to the security check APIs. People say you
shouldn't allow programmatic access to check security. Some say it is
unnecessary and others say this is a vulnerability since a web page can
check to see if access is possible without user knowing that the web page
is looking for attack opportunities.


Andy: Would this really happen in practice?


Paddy: Instead of asking whether you can use an API, instead you would try
to use the API and then a security exception would be raised. The idea is
that when a widget gets installed, it says what features it needs, and
either succeeds with installation or fails. If success, then the widget can
use the features.


Jon: From a security perspective, what's the difference between calling a
function to get a return code to see if you have permission or calling a
function and seeing if an exception is raised?


Paddy: Not much. But the checking function might invoke a prompt to ask the
user to allow access.


Adam: The common pattern in the JavaScript world is to check for existence


Jon: Two separate workflows. With widgets, there is an installer when
permissions can be checked. But what about a mapping browser application
where the app wants to show the user's current location? There is no
installer involved. You just go to the web page. The web page needs to know
whether it can use the geolocation APIs or not.


Paddy: BONDI hasn't looked at this workflow yet. In BONDI, the binding
action is when the exception might be called, and the exception has a
return code. But when you call the action, there is no way to introspect.
Not sure if introspection would provide greater vulnerability. Not much
detail in W3C discussion about introspection APIs other than "I don't like"


Jon: It's OK with me to drop the introspection feature. I thought there was
a requirement for them based on our work last spring and the BONDI
requirements. OK to leave it off and wait until someone says they need it.


Andy: But isn't there a workflow that will need this?


Paddy: It is likely that if you had a web site that needs the API and you
go to it for the first time, then the platform would prompt you if it's OK.
In some cases, maybe Vodafone has a deal with Google, and permissions for
Google are put into the phone and the Web site just works. BONDI doesn't
have introspection APIs. These are interesting suggestions, but maybe
allowing discovery without anyone knowing about it isn't good


Andy: (question about user experience)


Paddy: We don't know about the best user experience yet.


Jon: If I were on the other side and I saw this feature and heard Paddy's
explanations, I'd be worried too.


Andy: Are we unanimous for removal?


Jon: I suggest that we have a page that talks about the workflow
requirement, but list the potential problems with an introspection approach


(everyone ok with that)


Paddy: Another item. sync vs async. With async, you can't raise an error,
so errors must come through callbacks. But with sync, you can either return
a value, or throw an error, or invoke a callback. What is the
recommendation?


Jon/Adam: No standard answer. The Ajax community hasn't gravitated to any
one approach. It's more of a matter of personal taste and opinion.


Paddy: Can we include a comment about this?


Jon: Yes


Jon: I'll make incremental changes to reflect our discussion. That way,
people who have already looked the first version will see something that is
familiar to them when they see the updated version.


end of meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080927/355e000a/attachment.html 

From sbhola at us.ibm.com  Sat Sep 27 13:02:59 2008
From: sbhola at us.ibm.com (Sumeer Bhola)
Date: Sat, 27 Sep 2008 16:02:59 -0400
Subject: [OpenAjaxMobile] Sumeer Bhola/Watson/IBM is out of the office.
Message-ID: <OF8BE52AD4.B8BE3FCE-ON852574D1.006E2307-852574D1.006E2307@us.ibm.com>


I will be out of the office starting  09/27/2008 and will not return until
12/31/2009.

I have left IBM. You can reach me at sumeer at acm.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080927/f234c2b3/attachment.html 

From jferrai at us.ibm.com  Tue Sep 30 10:32:45 2008
From: jferrai at us.ibm.com (Jon Ferraiolo)
Date: Tue, 30 Sep 2008 10:32:45 -0700
Subject: [OpenAjaxMobile] Call for Participation for W3C Workshop on
	Security for Access to Device APIs from the Web
Message-ID: <OFB8B0BACF.F6C844F5-ON882574D4.005FBC78-882574D4.0060622A@us.ibm.com>



There is a lot of industry activity around Mobile Device APIs, which allows
the Web Runtime to access device services such as location, address book,
phone dialer, file system, and many other things. The idea is that you
should be able to use HTML+JS to do the sorts of things you can do with C++
or Java, and you should allow web pages to do the same sorts of things you
can do with installed applications. However, all of this flexibility raises
security concerns. To discuss these security concerns, the W3C and OMTP are
co-sponsoring an industry workshop on Dec 10-11 in London.

I encourage people to submit position papers and attend the workshop. I am
planning to draft an OpenAjax Alliance position paper for this workshop and
attend the workshop.

Jon

----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 09/30/2008 10:25 AM
-----
                                                                           
             Dominique                                                     
             Hazael-Massieux                                               
             <dom at w3.org>                                               To 
             Sent by:                  team-secure-web-pc at w3.org           
             team-secure-web-p                                          cc 
             c-request at w3.org                                              
                                                                   Subject 
                                       Call for Participation Announced    
             09/30/2008 08:11                                              
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           





Hello,

The Call for Participation has now been officially published by W3C:
http://www.w3.org/
http://www.w3.org/2008/security-ws/

This means you can now start advertizing the workshop among your
communities; please find below a draft message that can serve as a basis
for inviting people to participate to the workshop.

It is really important that we attract all the important industry
players to this workshop if we want to make it a successful event, and
I'm hoping you will be able to help us make it happen!

Thanks,

Dom

------------------
W3C just announced a call for participation to a Workshop on security
for access to device APIs from the Web, in London on December 10-11
2008.
http://www.w3.org/2008/security-ws/

A W3C Workshop is an opportunity for any interested parties to interact
and exchange ideas on the topics under discussion. W3C Membership is NOT
required to participate in a W3C Workshop.

This workshop will focus on the *security challenges* involved in
allowing Web applications and widgets to access the APIs that allow to
control devices features such as cameras, GPS systems, connectivity and
battery levels, external applications launch, access to personal data
(e.g. calendar or addressbook), etc, not traditionally available from
the Web environment.

To participate to this workshop, interested parties need to submit a
position paper relevant to this topic before *October 30 2008* to
team-secure-web at w3.org. These position papers will be reviewed by the
workshop program committee, and will serve as a basis for the agenda of
the two days workshop. Submitters will be notified of acceptance of
their papers by November 17.

A position paper should:
  * explain your interest in the Workshop
      * be aligned with the Workshop's stated goals
      * be 5 to 10 pages long (2000 - 4000 words)
      * be formatted in (valid) HTML/XHTML, PDF, or plain text

Interested parties are invited to inform the workshop organizers that
they are planning to submit a position paper by sending as soon as
possible an expression of interest to team-secure-web at w3.org, including
the number of persons from their organizations that are planning to
attend the workshop.

Topics in scope for the workshop include:
      * Existing frameworks on desktop and mobile platforms to regulate
        security policies for specific APIs,
      * Similarities and differences of the security approaches in
        desktop and mobile platforms, in a browser and in a widgets
        environment,
      * Usability of security relevant user interactions; issues and
        opportunities in the mobile environment,
      * Safe language and API subsets, and models for application use of
        such subsets,
      * Policy based trust delegation mechanisms,
      * Reducing the attack surface exposed by Web page scripts
      * Role of authentication of users and applications in securing API
        access,
      * Increasing awareness of good security practices for Web
        applications,
      * Usability of security and privacy policies

The discussions at this workshop are expected to be relevant in
particular to the following W3C Working Groups:
      * Web Applications Working Group
      * Geolocation Working Group
      * Ubiquitous Web Applications Working Group
      * HTML Working Group
      * Web Security Context Working Group

Should you have any question, please contact Dominique Hazael-Massieux
<dom at w3.org>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080930/143676a0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic27018.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080930/143676a0/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/mobile/attachments/20080930/143676a0/attachment-0001.gif