From jferrai at us.ibm.com Tue Apr 1 16:47:43 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 1 Apr 2008 16:47:43 -0700 Subject: [OpenAjaxMobile] Reminder: phone call this Thursday Message-ID: At this Thursday's phone call, we will first check to see if anyone has any issues to discuss on the White Paper, but we hope that discussion will be short, and that Rick Saletta can then produce a final editor's draft which is ready for final review by the Mobile TF and can be turned over to the Marketing WG for publishing. Since we have had some initial discussion on the Use Cases page and the Security page, I suggest we have some initial discussion on the Objectives page and then the Requirements page, and if we manage to get through a quick initial pass on those two documents, then have more detailed discussion on Use Cases. Therefore, here is the order that I propose for Thursday: 1) White paper 2) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives (quick initial review and discussion) 3) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements (quick initial review and discussion) 4) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases (time permitting) 5) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security (if miracles occur) Jon Next Conference Call Date: each Thursday (starting with March 6, ending with April 24, but skipping March 20) Time: Through end of March: 9amPT, noonET, 4pm London, 5pm Paris April and later: 9amPT, noonET, 5pm London, 6pm Paris Agenda White paper: http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax We are hoping for a final, short discussion on April 1 on the white paper, followed by final edits Device APIs Objectives: Mobile Device APIs Objectives Use cases: Mobile Device APIs Use Cases Requirements: Mobile Device APIs Requirements Security: Mobile Device APIs Security 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 IRC channel IRC channel: irc.freenode.net, #oaa-mobile Free online IRC client: http://java.freenode.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080401/84eaf605/attachment.html From david.pollington at vodafone.com Wed Apr 2 12:11:15 2008 From: david.pollington at vodafone.com (Pollington, David, VF-Group) Date: Wed, 2 Apr 2008 21:11:15 +0200 Subject: [OpenAjaxMobile] Comments for the call tomorrow Message-ID: Hi all, Apologies for not being able to make the call tomorrow, but here is some input to the planned discussion: 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives In addition to the 2 options already identified (device APIs specified, open source code), a third option (which is not mutually exclusive) is to provide a layered API model whereby the full set of device APIs may be provided by the underlying platform but the developer has the freedom of developing his own set of 'working' APIs through JavaScript wrappers. Such an approach has a number of benefits including a) enabling the developer to decide whether they want 10 methods for originating a call or just 1, b) enabling the community to provide a very simple set of APIs to enable Developers to get started (the iPhone originally only provided a single API method for originating a call to keep things simple). This point also relates to the notion of providing a modular architecture (developer deciding to use the location API without bundling in the others) but also enables a mashup approach to APIs whereby a developer could create a single API for accessing an address from the address book and fetching a map (e.g., 'get map for this contact' method). Getting the right balance between consistency/interoperability and flexibility will be the key hence the suggestion for taking a multi-tiered approach to API definition and usage. 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements - Support for multiple Application deployment models 1. conventional websites; MAY? 2. locally installable widgets; SHOULD 3. pre-installed widgets. MUST The caveat here is the phrase 'subject to security policy'; if an adequate security mechanism can be defined and deployed then the answer could be Should or Must to all 3... - Support for multi-origin models Agree that a developer should be able to combine different modules to create a new Web app; the question is whether these are then bound up and signed as a package or whether the Web app is effectively assembled dynamically. We need to make this clear in the requirement (whichever way we choose to state the degree of compliancy required). - Support for extensibility Absolutely agree that developers should be able to define their own APIs and this could be effectively managed through a multi-tiered API model. In terms of API request, I guess it makes sense that the app has to pre-announce the APIs it intends to use to prevent the situation where the app loads and some of the functionality is denied by the underlying platform giving an inconsistent user experience. Enabling an app to determine underlying API support is probably a Must rather than a Should to allow apps to react accordingly and minimise impact on user experience. - Specific APIs I'll leave more detailed comments to Guillermo to contribute to the reflector but some general comments: By 'Phone events' I guess we mean incoming call alerts, missed call alerts - probably worth spelling this out. For the Address Book we need APIs to access particular fields within a Contact (such as phone number, address or even a Birthday) For Files we need to add modification/editing (e.g., to save Web app settings/state if nothing else) 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases Only one comment on this paper and that's in relation to the assumption that as native apps are able to gain access to all system APIs (subject to the appropriate signing) then so should pre-installed Web apps. The big issue I see here is that native apps are typically deployed as monolithic lumps of code whereas the very nature of a Web app is that it is connected both to the device APIs and to the Web at the same time and potentially allows additional script to be downloaded and executed dynamically. As such it presents much more risk than a native app. Not sure how we solve this one but worth pointing out the differences. Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080402/0b22c1a9/attachment.html From jferrai at us.ibm.com Thu Apr 3 08:31:16 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 3 Apr 2008 08:31:16 -0700 Subject: [OpenAjaxMobile] Is the call on today? In-Reply-To: <9e4f714f0804030806t6e33fb37w7ce68851325c36e4@mail.gmail.com> Message-ID: Hi Ajit, Time zone problems, I think! I am going to start the call in about half an hour. Jon "Ajit Jaokar" To Sent by: Jon Ferraiolo/Menlo Park/IBM at IBMUS ajit.jaokar at gmail cc .com Subject Is the call on today? 04/03/2008 08:06 AM I keep getting music .. rgds Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080403/dfb85b6f/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/20080403/dfb85b6f/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic06549.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080403/dfb85b6f/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/20080403/dfb85b6f/attachment-0002.gif From Torkel.Hambraeus at ikivo.com Thu Apr 3 08:36:24 2008 From: Torkel.Hambraeus at ikivo.com (Torkel Hambraeus) Date: Thu, 3 Apr 2008 17:36:24 +0200 Subject: [OpenAjaxMobile] regrets for todays meeting Message-ID: <234EB4699C751A4A95DF4FD8D041BBFD25E303@SESTHSRV10.zoomon.local> Due to an emergency I will not be able to attend todays meeting. regards, Torkel Hambraeus Ikivo From rotan.hanrahan at mobileaware.com Thu Apr 3 09:10:48 2008 From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan) Date: Thu, 3 Apr 2008 12:10:48 -0400 Subject: [OpenAjaxMobile] New API for adaptation - uses in Ajax In-Reply-To: References: <9e4f714f0804030806t6e33fb37w7ce68851325c36e4@mail.gmail.com> Message-ID: I'm still on a call right now, unfortunately, but I want to give my OAA (Mobile) colleagues a heads-up that the W3C DDWG's new server-side API to access information about the Web-enabled device (to permit adaptation of the response to that device) is likely to be formally published in a matter of days. I will send a link as soon as it is ready. As I've said before, and mentioned in the whitepaper, using device knowledge to adapt Ajax is a technical possibility, once the access to the delivery context is standardised. This is now achieved. (Now joining IRC for a few mins.) ---Rotan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080403/7271ce27/attachment.html From chaals at opera.com Thu Apr 3 09:28:09 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Thu, 03 Apr 2008 18:28:09 +0200 Subject: [OpenAjaxMobile] regrets for todays meeting In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFD25E303@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFD25E303@SESTHSRV10.zoomon.local> Message-ID: On Thu, 03 Apr 2008 17:36:24 +0200, Torkel Hambraeus wrote: > Due to an emergency I will not be able to attend todays meeting. > regards, > Torkel Hambraeus Sorry, I am still in a meeting that is going on and I cannot skip :( chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From jferrai at us.ibm.com Thu Apr 3 11:53:03 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 3 Apr 2008 11:53:03 -0700 Subject: [OpenAjaxMobile] Minutes 2008-04-03 Message-ID: Mobile Minutes 2008-04-03 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-03 Attendees David Boloker, IBM (co-chair) Rick Saletta, Wavemaker Nikunj Mehta, Oracle Jon Ferraiolo, IBM Paddy Byers, Aplix Kai Hendry, Aplix Anselm Garbe, Aplix Louenas Hamdi, SAP Ajit Jaokar, Futuretext Elin R??s,Ikivo Minutes White paper http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax Introduction Jon: Nikunj, how about introducing the introduction changes you propose Nikunj: I propose to beef up the introduction. State the goals clearly. State the audience clearly. State the intent clearly. State what the following sections will say. I have proposed new text. Jon: I skimmed it and it looks good. I certainly like what you are trying to do. I request a day to review more carefully, but everything looks good. Deadline for requesting changes Jon: How about establishing a deadline for speaking up or forever holding your peace? How about end of day Friday this week? Paddy/Erin: Fine RESOLUTION: Everyone has until end of day Friday to make final proposals to white paper, at which point Rick Salette will do the final, final draft Characterizing Mobile Ajax Support Today Nikunj: Descriptions of Ajax characteristics isn't sufficient. We say that Ajax can be used in combination in multiple ways, but white paper has constant friction between talking about existing web site or optimized mobile web sites. Should say that existing web sites work with mobile ajax as we define it but optimizations will result in a better experience. Might be implicit but better to clarify this. Jon: Not sure what you Ajax characteristics. Nikunj: What Ajax is and its current status. Is there something that talks about this? Jon: I don't think we have anything like that for desktop. Desktop browsers supported a set of features, and then the Ajax libraries found a way to do magic with existing desktop browsers. Nikunj: WP1 had some text. WOuld be good to reference to that white paper and say what exists on mobile. Also, hard to find where mobile ajax is today. Jon: Kai pointed out before others joined that we don't talk about the state of mobile ajax today sufficiently. I can take a crack at referencing Ajax characteristics from other white papers and summarize the current state of affairs. 1 or 2 paragraphs. Any objections? Nikunj: Ok with me. ACTION Jon to add 1 or 2 paragraphs about characterizing Ajax and current state Mobile Ajax in Practice Nikunj: I propose "Mobile Ajax in Action". That's what I see in other white papers. Better, shows power of the technology. Jon: Fine with me. ACTION Jon to change Practice to Action Opportunities and Challenges Nikunj: I propose promoting Mobile Opportunity to next higher level, remove short summary section before it, and remove Differences in UI section after it Jon: That's what I was proposing, also ACTION Change WP to reflect this suggestion Design for efficient download and launch Nikunj: Not good to have overlap between this section and network section. I have proposed how to merge into the network section, then remove download and launch section. Jon: I agree there is overlap. Your proposals look good to me. The graphic showing the performance table Louenas: Don't know where to put this. I have heard lots of misconceptions about Mobile Ajax. People say it uses lots of bandwidth, but it does not. Depends on the app. We should try to remove the misconceptions. Nikunj: Would be useful in the section Design for Network Louenas: Maybe this graphic isn't correct for the white paper, but a picture helps out. Might be main takeaway. Louenas: A study has found that network data has much more impact on battery than CPU processing that data Jon: Where to put it? How about a new section, Performance Considerations, just before the tips section? Louenas: Yes, maybe. I think it's a good idea ACTION Jon: move table to new Performance Considerations section Finishing the white paper Rick: Just one more pass is all I can do Jon: Therefore, I propose a Friday deadline, the Rick finishes it. Any objections? (no objections) Nikunj: I have added one new section that isn't colored blus, the network section. Just wanted to alert people. Mobile Device APIs Jon: Let's review David Pollington's email: http://openajax.org/pipermail/mobile/2008q2/000163.html Objectives Excerpt from David's email: In addition to the 2 options already identified (device APIs specified, open source code), a third option (which is not mutually exclusive) is to provide a layered API model whereby the full set of device APIs may be provided by the underlying platform but the developer has the freedom of developing his own set of 'working' APIs through JavaScript wrappers. Such an approach has a number of benefits including a) enabling the developer to decide whether they want 10 methods for originating a call or just 1, b) enabling the community to provide a very simple set of APIs to enable Developers to get started (the iPhone originally only provided a single API method for originating a call to keep things simple). This point also relates to the notion of providing a modular architecture (developer deciding to use the location API without bundling in the others) but also enables a mashup approach to APIs whereby a developer could create a single API for accessing an address from the address book and fetching a map (e.g., 'get map for this contact' method). Getting the right balance between consistency/interoperability and flexibility will be the key hence the suggestion for taking a multi-tiered approach to API definition and usage. Jon: I'm confused by what he means by "developer". There is the system developer working on the device or browser. There is the Ajax toolkit developer working on an Ajax library. And there is the app developer who is using the Ajax toolkit. Nikunj: I guess that "developer" means JavaScript developer, such as the jQuery developers. But I don't understand fully. Paddy: Anyone can write JS APIs on top of device APIs. People can use whatever APIs they like, such as an Ajax library, maybe OpenAjax Hub. But this is all out of scope of our discussion. It's just regular JavaScript development. How does that relate to us? First, maybe for security considerations. Perhaps we can allow applications to access high-level APIs but not lower-level ones. Could turn this into an objective. Second, the way a lot of frameworks work is that you don't always load the library directly, but instead you invoke a loader which then loads the library. A question we can ask is to request that device APIs can be loaded in some way. There has been some discussion at OpenAjax in this area. Call one API which then loads what is needed. Jon: Such an approach aligns with the shim layer idea with providers. You say which provider you need and then its JavaScript gets loaded. Paddy: We could define a portable APIs for that similar to Google's loader. Could have an open source implementation. When we define our scope, we might go beyond APIs but also the infrastructure that we need, including loading Jon: Brilliant. I like it. But at this point, I don't think we can go any further than what you just said. We can conclude "we think we might need a loader" but we won't know for sure until we roll up our sleeves and start coding things. Paddy: Sure. Jon: I'll send an email to David asking for clarifications ACTION Jon to ask DavidP for clarifications Requirements - Support for multiple Application deployment models 1. conventional websites; MAY? 2. locally installable widgets; SHOULD 3. pre-installed widgets. MUST The caveat here is the phrase 'subject to security policy'; if an adequate security mechanism can be defined and deployed then the answer could be Should or Must to all 3... - Support for multi-origin models Agree that a developer should be able to combine different modules to create a new Web app; the question is whether these are then bound up and signed as a package or whether the Web app is effectively assembled dynamically. We need to make this clear in the requirement (whichever way we choose to state the degree of compliancy required). - Support for extensibility Absolutely agree that developers should be able to define their own APIs and this could be effectively managed through a multi-tiered API model. In terms of API request, I guess it makes sense that the app has to pre-announce the APIs it intends to use to prevent the situation where the app loads and some of the functionality is denied by the underlying platform giving an inconsistent user experience. Enabling an app to determine underlying API support is probably a Must rather than a Should to allow apps to react accordingly and minimise impact on user experience. Jon: David has comments about application deployment model. I agree with his comments. Paddy: Yes, we do, too. Jon: I will try to merge his comments into the text unless someone objects. ACTION Jon to merge DavidP's comments about application deployment model into Requirements doc Jon: Now to multi-origin model. Regarding his question, there are separate use cases for both. Nikunj: Not clear what is meant. Different data sources or different markup or different script. Paddy: I think we intend to support all of the above. Nikunj: There may be different security concerns Jon: This is going to come up again and again. Complex subject. I'll take the action to attempt to make the text clearer. ACTION Jon to attempt to make multi-origin model clearer Nikunj: Will benefit form other OpenAjax work in related areas? Just reference this? Nothing here that is unique to mobile. Paddy: Security is the big issue. We have to think about when the system decides to grant access to an API, based on a particular identity. Question is whether the system can make a good decision if multiple different places are involved. The answer might be yes. Jon: We are having discussions at the same time in the Runtime TF effort. It is a complex area. We have at least 5 different proposals for the desktop to minimize the problem of cross-site scripting. Nikunj: One thing is that we need to make sure that the objectives capture this. Extensibility Jon: I would say the ability to query whether an API exists is a MUST Nikunj: Not clear whether David is talking about extensibility of JavaScript or native code. Yes, JavaScript needs to be able to test to see what is available. Is that what we mean here? Jon: I'm not sure who wrote the original extensibility text, Paddy, me or someone else, but my thinking was that extensibility was focused on the system side, where the device manufacturer or browser could innovate with newer APIs or extensions to existing APIs and not be constrained by whatever we do Nikunj: Need to make this clear ACTION Jon clarify extensibility section Next meeting Jon: Let's resume next week with David's section "Specific APIs". Hopefully David will join the call next week. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080403/4b018af5/attachment-0001.html From jferrai at us.ibm.com Thu Apr 3 12:25:22 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 3 Apr 2008 12:25:22 -0700 Subject: [OpenAjaxMobile] New API for adaptation - uses in Ajax In-Reply-To: Message-ID: Hi Rotan, Thanks for the heads-up. I'll put the link in the References section of the white paper once you send the link to the list. Jon "Rotan Hanrahan" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc 04/03/2008 09:10 Subject AM [OpenAjaxMobile] New API for adaptation - uses in Ajax Please respond to OpenAjax Alliance discussion list on Mobile Ajax I?m still on a call right now, unfortunately, but I want to give my OAA (Mobile) colleagues a heads-up that the W3C DDWG?s new server-side API to access information about the Web-enabled device (to permit adaptation of the response to that device) is likely to be formally published in a matter of days. I will send a link as soon as it is ready. As I?ve said before, and mentioned in the whitepaper, using device knowledge to adapt Ajax is a technical possibility, once the access to the delivery context is standardised. This is now achieved. (Now joining IRC for a few mins.) ---Rotan._______________________________________________ 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/20080403/51b155d3/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/20080403/51b155d3/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic24499.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080403/51b155d3/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/20080403/51b155d3/attachment-0002.gif From Andrew.Sledd at ikivo.com Thu Apr 3 23:04:46 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Fri, 4 Apr 2008 08:04:46 +0200 Subject: [OpenAjaxMobile] Regretts for Reminder: phone call this Thursday In-Reply-To: Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDC53616@SESTHSRV10.zoomon.local> Regretts. Unfortunately, last minute travel changes keep me from being able to participate tomorrow. Andy Sledd Ikivo AB ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 2 april 2008 01:48 To: mobile at openajax.org Subject: [OpenAjaxMobile] Reminder: phone call this Thursday At this Thursday's phone call, we will first check to see if anyone has any issues to discuss on the White Paper, but we hope that discussion will be short, and that Rick Saletta can then produce a final editor's draft which is ready for final review by the Mobile TF and can be turned over to the Marketing WG for publishing. Since we have had some initial discussion on the Use Cases page and the Security page, I suggest we have some initial discussion on the Objectives page and then the Requirements page, and if we manage to get through a quick initial pass on those two documents, then have more detailed discussion on Use Cases. Therefore, here is the order that I propose for Thursday: 1) White paper 2) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives (quick initial review and discussion) 3) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements (quick initial review and discussion) 4) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases (time permitting) 5) http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security (if miracles occur) Jon Next Conference Call * Date: each Thursday (starting with March 6, ending with April 24, but skipping March 20) * Time: * Through end of March: 9amPT, noonET, 4pm London, 5pm Paris * April and later: 9amPT, noonET, 5pm London, 6pm Paris * Agenda * White paper: http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax * We are hoping for a final, short discussion on April 1 on the white paper, followed by final edits * Device APIs * Objectives: Mobile Device APIs Objectives * Use cases: Mobile Device APIs Use Cases * Requirements: Mobile Device APIs Requirements * Security: Mobile Device APIs Security 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 IRC channel * IRC channel: irc.freenode.net, #oaa-mobile * Free online IRC client: http://java.freenode.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080404/494c0705/attachment-0001.html From jferrai at us.ibm.com Fri Apr 4 14:07:29 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 4 Apr 2008 14:07:29 -0700 Subject: [OpenAjaxMobile] Actions on white paper completed, Louenas's table replicated Message-ID: I have completed all of my actions on the white paper from yesterday's phone call. One thing in particular that I did was create a new "Performance Considerations" section in which I attempted to convert Louenas's table (which was an image within the wiki page) into wiki table syntax. I made some minor editorial changes along the way in the table. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080404/e7a381fa/attachment.html From jferrai at us.ibm.com Fri Apr 4 14:48:15 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 4 Apr 2008 14:48:15 -0700 Subject: [OpenAjaxMobile] Comments for the call tomorrow In-Reply-To: Message-ID: Hi David, I don't know if you have had a chance to review the minutes from yesterday's phone call yet, but we had questions about some of the things from your email, in particular what you mean by the term "developer". Are you referring to a system developer (e.g., someone who implements an operating system), a browser developer, an Ajax library developer, or a JavaScript application developer (who might use an Ajax library)? Our guess was that you were using the term "developer" to mean someone who is coding in JavaScript and attempting to access device services via JavaScript APIs. Is that correct? If so, then Paddy and I (and perhaps others) pointed out that JavaScript developers are not only free to create custom wrapper JavaScript functions, but in fact this would be a recommended programming practice in many scenarios. But Paddy and I think that's outside of the scope of what we need to do. Instead, our job is to define lower-level JavaScript APIs that provide more raw access to device services, on top of which Ajax libraries or individual programmers can build whatever wrapper functions they feel are desirable. Or perhaps we misunderstood. Thanks. Jon mobile-bounces at openajax.org wrote on 04/02/2008 12:11:15 PM: > Hi all, > > Apologies for not being able to make the call tomorrow, but here is > some input to the planned discussion: > > 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > In addition to the 2 options already identified (device APIs > specified, open source code), a third option (which is not mutually > exclusive) is to provide a layered API model whereby the full set of > device APIs may be provided by the underlying platform but the > developer has the freedom of developing his own set of 'working' > APIs through JavaScript wrappers. Such an approach has a number of > benefits including a) enabling the developer to decide whether they > want 10 methods for originating a call or just 1, b) enabling the > community to provide a very simple set of APIs to enable Developers > to get started (the iPhone originally only provided a single API > method for originating a call to keep things simple). > > This point also relates to the notion of providing a modular > architecture (developer deciding to use the location API without > bundling in the others) but also enables a mashup approach to APIs > whereby a developer could create a single API for accessing an > address from the address book and fetching a map (e.g., 'get map for > this contact' method). > > Getting the right balance between consistency/interoperability and > flexibility will be the key hence the suggestion for taking a multi- > tiered approach to API definition and usage. > > 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > - Support for multiple Application deployment models > > 1. conventional websites; MAY? > 2. locally installable widgets; SHOULD > 3. pre-installed widgets. MUST > > The caveat here is the phrase 'subject to security policy'; if an > adequate security mechanism can be defined and deployed then the > answer could be Should or Must to all 3... > > - Support for multi-origin models > > Agree that a developer should be able to combine different modules > to create a new Web app; the question is whether these are then > bound up and signed as a package or whether the Web app is > effectively assembled dynamically. We need to make this clear in > the requirement (whichever way we choose to state the degree of > compliancy required). > > - Support for extensibility > > Absolutely agree that developers should be able to define their own > APIs and this could be effectively managed through a multi-tiered > API model. In terms of API request, I guess it makes sense that the > app has to pre-announce the APIs it intends to use to prevent the > situation where the app loads and some of the functionality is > denied by the underlying platform giving an inconsistent user > experience. Enabling an app to determine underlying API support is > probably a Must rather than a Should to allow apps to react > accordingly and minimise impact on user experience. > > - Specific APIs > > I'll leave more detailed comments to Guillermo to contribute to the > reflector but some general comments: > > By 'Phone events' I guess we mean incoming call alerts, missed call > alerts - probably worth spelling this out. > For the Address Book we need APIs to access particular fields within > a Contact (such as phone number, address or even a Birthday) > For Files we need to add modification/editing (e.g., to save Web app > settings/state if nothing else) > > 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > > Only one comment on this paper and that's in relation to the > assumption that as native apps are able to gain access to all system > APIs (subject to the appropriate signing) then so should pre- > installed Web apps. The big issue I see here is that native apps > are typically deployed as monolithic lumps of code whereas the very > nature of a Web app is that it is connected both to the device APIs > and to the Web at the same time and potentially allows additional > script to be downloaded and executed dynamically. As such it > presents much more risk than a native app. Not sure how we solve > this one but worth pointing out the differences. > > Cheers, > > David > > > > > > > > > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington at vodafone.com > > Web: www.betavine.net > Mobile Web: betavine.mobi > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, > Berkshire RG14 2FN Registered in England No 3802001 > _______________________________________________ > 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/20080404/e3d2c62a/attachment.html From david.pollington at vodafone.com Sun Apr 6 12:45:16 2008 From: david.pollington at vodafone.com (Pollington, David, VF-Group) Date: Sun, 6 Apr 2008 21:45:16 +0200 Subject: [OpenAjaxMobile] Comments for the call tomorrow In-Reply-To: Message-ID: Hi Jon, Yes, just been through the minutes and noted some of the confusion which certainly wasn't intended on my part. In terms of the specific item around the device APIs I just wanted to ensure that it was clear for anyone reading the wiki that the app developer was able to define and use their own JavaScript wrappers. I appreciate that this may be out of scope but it marks a clear distinction (at least in my understanding) from the definition of JSRs in the JCP and in the past some of the Expert Groups have been known to agonise over the exact semantics of the APIs for a long time to ensure they addressed the varied needs of the target Java developers - this issue presumably doesn't arise to such a degree for JavaScript (?). Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 ________________________________ From: Jon Ferraiolo [mailto:jferrai at us.ibm.com] Sent: 04 April 2008 22:48 To: Pollington, David, VF-Group Cc: mobile at openajax.org Subject: Re: [OpenAjaxMobile] Comments for the call tomorrow Hi David, I don't know if you have had a chance to review the minutes from yesterday's phone call yet, but we had questions about some of the things from your email, in particular what you mean by the term "developer". Are you referring to a system developer (e.g., someone who implements an operating system), a browser developer, an Ajax library developer, or a JavaScript application developer (who might use an Ajax library)? Our guess was that you were using the term "developer" to mean someone who is coding in JavaScript and attempting to access device services via JavaScript APIs. Is that correct? If so, then Paddy and I (and perhaps others) pointed out that JavaScript developers are not only free to create custom wrapper JavaScript functions, but in fact this would be a recommended programming practice in many scenarios. But Paddy and I think that's outside of the scope of what we need to do. Instead, our job is to define lower-level JavaScript APIs that provide more raw access to device services, on top of which Ajax libraries or individual programmers can build whatever wrapper functions they feel are desirable. Or perhaps we misunderstood. Thanks. Jon mobile-bounces at openajax.org wrote on 04/02/2008 12:11:15 PM: > Hi all, > > Apologies for not being able to make the call tomorrow, but here is > some input to the planned discussion: > > 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > In addition to the 2 options already identified (device APIs > specified, open source code), a third option (which is not mutually > exclusive) is to provide a layered API model whereby the full set of > device APIs may be provided by the underlying platform but the > developer has the freedom of developing his own set of 'working' > APIs through JavaScript wrappers. Such an approach has a number of > benefits including a) enabling the developer to decide whether they > want 10 methods for originating a call or just 1, b) enabling the > community to provide a very simple set of APIs to enable Developers > to get started (the iPhone originally only provided a single API > method for originating a call to keep things simple). > > This point also relates to the notion of providing a modular > architecture (developer deciding to use the location API without > bundling in the others) but also enables a mashup approach to APIs > whereby a developer could create a single API for accessing an > address from the address book and fetching a map (e.g., 'get map for > this contact' method). > > Getting the right balance between consistency/interoperability and > flexibility will be the key hence the suggestion for taking a multi- > tiered approach to API definition and usage. > > 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > - Support for multiple Application deployment models > > 1. conventional websites; MAY? > 2. locally installable widgets; SHOULD > 3. pre-installed widgets. MUST > > The caveat here is the phrase 'subject to security policy'; if an > adequate security mechanism can be defined and deployed then the > answer could be Should or Must to all 3... > > - Support for multi-origin models > > Agree that a developer should be able to combine different modules > to create a new Web app; the question is whether these are then > bound up and signed as a package or whether the Web app is > effectively assembled dynamically. We need to make this clear in > the requirement (whichever way we choose to state the degree of > compliancy required). > > - Support for extensibility > > Absolutely agree that developers should be able to define their own > APIs and this could be effectively managed through a multi-tiered > API model. In terms of API request, I guess it makes sense that the > app has to pre-announce the APIs it intends to use to prevent the > situation where the app loads and some of the functionality is > denied by the underlying platform giving an inconsistent user > experience. Enabling an app to determine underlying API support is > probably a Must rather than a Should to allow apps to react > accordingly and minimise impact on user experience. > > - Specific APIs > > I'll leave more detailed comments to Guillermo to contribute to the > reflector but some general comments: > > By 'Phone events' I guess we mean incoming call alerts, missed call > alerts - probably worth spelling this out. > For the Address Book we need APIs to access particular fields within > a Contact (such as phone number, address or even a Birthday) > For Files we need to add modification/editing (e.g., to save Web app > settings/state if nothing else) > > 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > > Only one comment on this paper and that's in relation to the > assumption that as native apps are able to gain access to all system > APIs (subject to the appropriate signing) then so should pre- > installed Web apps. The big issue I see here is that native apps > are typically deployed as monolithic lumps of code whereas the very > nature of a Web app is that it is connected both to the device APIs > and to the Web at the same time and potentially allows additional > script to be downloaded and executed dynamically. As such it > presents much more risk than a native app. Not sure how we solve > this one but worth pointing out the differences. > > Cheers, > > David > > > > > > > > > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington at vodafone.com > > Web: www.betavine.net > Mobile Web: betavine.mobi > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, > Berkshire RG14 2FN Registered in England No 3802001 > _______________________________________________ > 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/20080406/41f41e4e/attachment.html From jferrai at us.ibm.com Sun Apr 6 15:37:42 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Sun, 6 Apr 2008 15:37:42 -0700 Subject: [OpenAjaxMobile] Comments for the call tomorrow In-Reply-To: Message-ID: Hi David, Thanks. This all makes sense, and it sounds like we are all in violent agreement about how JavaScript developers can customize APIs easily. Jon "Pollington, David, VF-Group" Jon Ferraiolo/Menlo Park/IBM at IBMUS cc 04/06/2008 12:45 PM Subject RE: [OpenAjaxMobile] Comments for the call tomorrow Hi Jon, Yes, just been through the minutes and noted some of the confusion which certainly wasn't intended on my part. In terms of the specific item around the device APIs I just wanted to ensure that it was clear for anyone reading the wiki that the app developer was able to define and use their own JavaScript wrappers. I appreciate that this may be out of scope but it marks a clear distinction (at least in my understanding) from the definition of JSRs in the JCP and in the past some of the Expert Groups have been known to agonise over the exact semantics of the APIs for a long time to ensure they addressed the varied needs of the target Java developers - this issue presumably doesn't arise to such a degree for JavaScript (?). Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 From: Jon Ferraiolo [mailto:jferrai at us.ibm.com] Sent: 04 April 2008 22:48 To: Pollington, David, VF-Group Cc: mobile at openajax.org Subject: Re: [OpenAjaxMobile] Comments for the call tomorrow Hi David, I don't know if you have had a chance to review the minutes from yesterday's phone call yet, but we had questions about some of the things from your email, in particular what you mean by the term "developer". Are you referring to a system developer (e.g., someone who implements an operating system), a browser developer, an Ajax library developer, or a JavaScript application developer (who might use an Ajax library)? Our guess was that you were using the term "developer" to mean someone who is coding in JavaScript and attempting to access device services via JavaScript APIs. Is that correct? If so, then Paddy and I (and perhaps others) pointed out that JavaScript developers are not only free to create custom wrapper JavaScript functions, but in fact this would be a recommended programming practice in many scenarios. But Paddy and I think that's outside of the scope of what we need to do. Instead, our job is to define lower-level JavaScript APIs that provide more raw access to device services, on top of which Ajax libraries or individual programmers can build whatever wrapper functions they feel are desirable. Or perhaps we misunderstood. Thanks. Jon mobile-bounces at openajax.org wrote on 04/02/2008 12:11:15 PM: > Hi all, > > Apologies for not being able to make the call tomorrow, but here is > some input to the planned discussion: > > 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > In addition to the 2 options already identified (device APIs > specified, open source code), a third option (which is not mutually > exclusive) is to provide a layered API model whereby the full set of > device APIs may be provided by the underlying platform but the > developer has the freedom of developing his own set of 'working' > APIs through JavaScript wrappers. Such an approach has a number of > benefits including a) enabling the developer to decide whether they > want 10 methods for originating a call or just 1, b) enabling the > community to provide a very simple set of APIs to enable Developers > to get started (the iPhone originally only provided a single API > method for originating a call to keep things simple). > > This point also relates to the notion of providing a modular > architecture (developer deciding to use the location API without > bundling in the others) but also enables a mashup approach to APIs > whereby a developer could create a single API for accessing an > address from the address book and fetching a map (e.g., 'get map for > this contact' method). > > Getting the right balance between consistency/interoperability and > flexibility will be the key hence the suggestion for taking a multi- > tiered approach to API definition and usage. > > 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > - Support for multiple Application deployment models > > 1. conventional websites; MAY? > 2. locally installable widgets; SHOULD > 3. pre-installed widgets. MUST > > The caveat here is the phrase 'subject to security policy'; if an > adequate security mechanism can be defined and deployed then the > answer could be Should or Must to all 3... > > - Support for multi-origin models > > Agree that a developer should be able to combine different modules > to create a new Web app; the question is whether these are then > bound up and signed as a package or whether the Web app is > effectively assembled dynamically. We need to make this clear in > the requirement (whichever way we choose to state the degree of > compliancy required). > > - Support for extensibility > > Absolutely agree that developers should be able to define their own > APIs and this could be effectively managed through a multi-tiered > API model. In terms of API request, I guess it makes sense that the > app has to pre-announce the APIs it intends to use to prevent the > situation where the app loads and some of the functionality is > denied by the underlying platform giving an inconsistent user > experience. Enabling an app to determine underlying API support is > probably a Must rather than a Should to allow apps to react > accordingly and minimise impact on user experience. > > - Specific APIs > > I'll leave more detailed comments to Guillermo to contribute to the > reflector but some general comments: > > By 'Phone events' I guess we mean incoming call alerts, missed call > alerts - probably worth spelling this out. > For the Address Book we need APIs to access particular fields within > a Contact (such as phone number, address or even a Birthday) > For Files we need to add modification/editing (e.g., to save Web app > settings/state if nothing else) > > 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > > Only one comment on this paper and that's in relation to the > assumption that as native apps are able to gain access to all system > APIs (subject to the appropriate signing) then so should pre- > installed Web apps. The big issue I see here is that native apps > are typically deployed as monolithic lumps of code whereas the very > nature of a Web app is that it is connected both to the device APIs > and to the Web at the same time and potentially allows additional > script to be downloaded and executed dynamically. As such it > presents much more risk than a native app. Not sure how we solve > this one but worth pointing out the differences. > > Cheers, > > David > > > > > > > > > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington at vodafone.com > > Web: www.betavine.net > Mobile Web: betavine.mobi > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, > Berkshire RG14 2FN Registered in England No 3802001 > _______________________________________________ > 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/20080406/f5d9d1ef/attachment-0001.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/20080406/f5d9d1ef/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic14166.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080406/f5d9d1ef/attachment-0004.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/20080406/f5d9d1ef/attachment-0005.gif From hendry at aplixcorp.com Tue Apr 8 06:33:07 2008 From: hendry at aplixcorp.com (Kai Hendry) Date: Tue, 8 Apr 2008 14:33:07 +0100 Subject: [OpenAjaxMobile] Mobile acid test Message-ID: Hi everyone, Thought I might draw your attention to some work going on at "Mobile Web Initiative Test Suites Working Group" at the W3C. They are putting together a "mobile acid test" (soon to be renamed) and I think it could perhaps do with a couple of extra tests in the Javascript department. http://dev.w3.org/2008/mobile-test/doc.html Can anyone suggest another good test besides the current "9. XMLHTTPRequest" test? http://dev.w3.org/2008/mobile-test/xmlhttprequest.js Discussion: http://lists.w3.org/Archives/Public/public-mwts/2008Apr/ Kind regards, From chaals at opera.com Tue Apr 8 09:17:23 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Tue, 08 Apr 2008 18:17:23 +0200 Subject: [OpenAjaxMobile] Mobile acid test In-Reply-To: References: Message-ID: On Tue, 08 Apr 2008 15:33:07 +0200, Kai Hendry wrote: > ... could perhaps do with a couple of extra tests in the Javascript > department. > http://dev.w3.org/2008/mobile-test/doc.html Actually, I am curious about what other things you think should be tested. It would be possible to make a bunch of common .js tests, if you think that's worthwhile... What other bits of javascript are important to mobile, and generally have implementation problems? > Can anyone suggest another good test besides the current "9. > XMLHTTPRequest" test? > http://dev.w3.org/2008/mobile-test/xmlhttprequest.js cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From jferrai at us.ibm.com Tue Apr 8 09:59:20 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 8 Apr 2008 09:59:20 -0700 Subject: [OpenAjaxMobile] Mobile acid test In-Reply-To: Message-ID: Hi Chaals, Many moons ago your CTO, Hakon, talked to me about mobile acid tests. I thought it was a good idea then and I think it is a good idea now, but someone has to do the work. Personally, I buy into the "One Web" notion, not only that there is a single Web shared by desktop and mobile, but that in the long-term, desktop and mobile share the same set of core Open Web technologies, where, in general, mobile devices are able to view and interact with the same exact content as the desktop Web, but obviously there are several details that need to be taken into account, such as lack of a mouse pointer on many mobile devices being just one of many. Therefore, given how I characterize my own personal version of "One Web", the same acid tests from the Web Standards Project that target desktop browsers should also work on future mobile browsers. But then the question is what *extra* tests do we need for mobile browsers? Here are some things that come to mind: 1) Should be able to render a desktop-size Web page (e.g., 1000x800), and scroll/pan/zoom to navigate around 2) Should be able to support all of the UI actions defined within ARIA (or some other way of expressing the device independent UI requirement) 3) Should support keyboard input somehow or other I'm sure there are many more. What do people think about working on such an acid test, and what sorts of things would it verify? Remember, one of the principal goals of OpenAjax Alliance is to drive the industry towards Ajax interoperability so that Web developers can utilize Ajax more effectively. Jon "Charles McCathieNevile" "OpenAjax Alliance discussion list Sent by: on Mobile Ajax" mobile-bounces at op enajax.org cc Subject 04/08/2008 09:17 Re: [OpenAjaxMobile] Mobile acid AM test Please respond to OpenAjax Alliance discussion list on Mobile Ajax On Tue, 08 Apr 2008 15:33:07 +0200, Kai Hendry wrote: > ... could perhaps do with a couple of extra tests in the Javascript > department. > http://dev.w3.org/2008/mobile-test/doc.html Actually, I am curious about what other things you think should be tested. It would be possible to make a bunch of common .js tests, if you think that's worthwhile... What other bits of javascript are important to mobile, and generally have implementation problems? > Can anyone suggest another good test besides the current "9. > XMLHTTPRequest" test? > http://dev.w3.org/2008/mobile-test/xmlhttprequest.js cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com _______________________________________________ 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/20080408/1bf88361/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/20080408/1bf88361/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic03849.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/1bf88361/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/20080408/1bf88361/attachment-0002.gif From jferrai at us.ibm.com Tue Apr 8 10:37:57 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 8 Apr 2008 10:37:57 -0700 Subject: [OpenAjaxMobile] Mobile acid test In-Reply-To: Message-ID: Sorry, Kai's original email arrived in my inbox after Chaals' response. Regarding W3C doing an acid test on Ajax support, that's fine with me, so long as something good happens somewhere. However, ultimately I would think the ideal best place ultimately for acid tests would be the Web Standards Project, assuming that mobile gets on their radar. Also, I would be concerned about W3C taking the lead on verifying "Ajax", since Ajax reflects the de facto standard of what is implemented in browsers, which is different than what W3C standards say should be implemented in browsers. With HTML5, these two ideas are merging together, but overall W3C is still attempting to define the future for what browsers should implement, whereas Ajax is mostly about the Open Web technologies that actually ship today. In particular, "Ajax" as we define it at the alliance goes much further than XMLHttpRequest. It also supports JSON via the dynamic SCRIPT tag, rich user interfaces leveraging leveraging clever JavaScript, local persistent storage, Comet-style server push, and countless other features. The possible role for OpenAjax Alliance in all of this would be to help out. We might work on requirements (i.e., acid tests need to test the following things) and we might work on some early versions of proposed tests. However, as I said in the previous paragraph, the Web Standards Project seems like a natural place long-term for mobile acid tests. Jon Jon Ferraiolo/Menlo Park/IBM at IBMUS To Sent by: OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax enajax.org cc 04/08/2008 09:59 Subject AM Re: [OpenAjaxMobile] Mobile acid test Please respond to OpenAjax Alliance discussion list on Mobile Ajax Hi Chaals, Many moons ago your CTO, Hakon, talked to me about mobile acid tests. I thought it was a good idea then and I think it is a good idea now, but someone has to do the work. Personally, I buy into the "One Web" notion, not only that there is a single Web shared by desktop and mobile, but that in the long-term, desktop and mobile share the same set of core Open Web technologies, where, in general, mobile devices are able to view and interact with the same exact content as the desktop Web, but obviously there are several details that need to be taken into account, such as lack of a mouse pointer on many mobile devices being just one of many. Therefore, given how I characterize my own personal version of "One Web", the same acid tests from the Web Standards Project that target desktop browsers should also work on future mobile browsers. But then the question is what *extra* tests do we need for mobile browsers? Here are some things that come to mind: 1) Should be able to render a desktop-size Web page (e.g., 1000x800), and scroll/pan/zoom to navigate around 2) Should be able to support all of the UI actions defined within ARIA (or some other way of expressing the device independent UI requirement) 3) Should support keyboard input somehow or other I'm sure there are many more. What do people think about working on such an acid test, and what sorts of things would it verify? Remember, one of the principal goals of OpenAjax Alliance is to drive the industry towards Ajax interoperability so that Web developers can utilize Ajax more effectively. Jon Inactive hide details for "Charles McCathieNevile" "Charles McCathieNevile" "Charles McCathieNevi le" To Sent by: mobile-bounc "OpenAjax Alliance es at openajax. discussion list on Mobile org Ajax" 04/08/2008 cc 09:17 AM Subject Please respond to OpenAjax Alliance discussion list Re: [OpenAjaxMobile] on Mobile Ajax Mobile acid test On Tue, 08 Apr 2008 15:33:07 +0200, Kai Hendry wrote: > ... could perhaps do with a couple of extra tests in the Javascript > department. > http://dev.w3.org/2008/mobile-test/doc.html Actually, I am curious about what other things you think should be tested. It would be possible to make a bunch of common .js tests, if you think that's worthwhile... What other bits of javascript are important to mobile, and generally have implementation problems? > Can anyone suggest another good test besides the current "9. > XMLHTTPRequest" test? > http://dev.w3.org/2008/mobile-test/xmlhttprequest.js cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile _______________________________________________ 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/20080408/b6aae186/attachment-0001.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/20080408/b6aae186/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic23824.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/b6aae186/attachment-0007.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/20080408/b6aae186/attachment-0008.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 09327072.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/b6aae186/attachment-0009.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 09261232.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/b6aae186/attachment-0010.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 09884918.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/b6aae186/attachment-0011.gif From chaals at opera.com Tue Apr 8 15:32:57 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 09 Apr 2008 00:32:57 +0200 Subject: [OpenAjaxMobile] Mobile acid test In-Reply-To: References: Message-ID: On Tue, 08 Apr 2008 19:37:57 +0200, Jon Ferraiolo wrote: > However, ultimately I would think the ideal best place ultimately for > acid tests would be the Web Standards Project, The WSP just blesses Acid tests at some point. As we saw with Acid3 (and Acid2 before it) this isn't the point at which the test is finalised - in both cases they have been happy to let Ian Hickson just unilaterally decide on changes to the test afterward. So if W3C makes a test that deserves the Acid tag, I think that's fine. > ... Also, I would be concerned about W3C taking the lead on > verifying "Ajax", since Ajax reflects the de facto standard of what is > implemented in browsers, which is different than what W3C standards say > should be implemented in browsers. Sure. But the direction of W3C towards doing better testing and being more concerned about the real world is one that I think we should be encouraging - we need a place to make new standards and W3C is a good one, but we also need to standardise things when they are ready, not before or after. > In particular, "Ajax" as we define > it at the alliance goes much further than XMLHttpRequest. It also > supports JSON via the dynamic SCRIPT tag, rich user interfaces > leveraging leveraging clever JavaScript, local persistent storage, > Comet-style > server push, and countless other features. I strongly suspect the things that really matter are actually quite countable... > The possible role for OpenAjax Alliance in all of this would be to help > out. We might work on requirements (i.e., acid tests need to test the > following things) and we might work on some early versions of proposed > tests. However, as I said in the previous paragraph, the Web Standards > Project seems like a natural place long-term for mobile acid tests. Sure, getting the WaSP to bless an Acid test (or acid-style test - for some reason the W3C group don't want to use the Acid name) is a sensible thing to do. But they don't actually develop them, and since Ian registered acidtests.org they don't even host them. I think it would be very valuable if the OAA proposed stuff to be tested. Since Opera is directly represented in the relevant Working group at W3C, we will generally propose stuff through our representative there (he happens to be head of Core QA at Opera too, so we think he is pretty qualified ;) ), but I will happily cross-post to this group about ideas for more tests that involve Ajax stuff... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From jferrai at us.ibm.com Tue Apr 8 15:41:27 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 8 Apr 2008 15:41:27 -0700 Subject: [OpenAjaxMobile] Mobile acid test In-Reply-To: Message-ID: Chaals, Everything you say below makes sense to me. If everyone else agrees, then the burden on this task force would be to identify the finite (vs countless) things that need to be tested with a mobile acid test. Easier said than done. As I said earlier, in general, the set of features to test in mobile Ajax consists of everything in desktop Ajax, plus a few other things (the hard part). Here are some of the few other things that are mobile specific: 1) Should be able to render a desktop-size Web page (e.g., 1000x800), and scroll/pan/zoom to navigate around 2) Should be able to support all of the UI actions defined within ARIA (or some other way of expressing the device independent UI requirement) 3) Should support keyboard input somehow or other The #2 item above is the most interesting. Becky Gibson of accessibility and ARIA fame (and who put ARIA support into Dojo) has joined this task force and is looking at mobile issues. Maybe she'll have some good ideas regarding #2 once she has some time to think about things. Jon "Charles McCathieNevile" "OpenAjax Alliance discussion list Sent by: on Mobile Ajax" mobile-bounces at op enajax.org cc Subject 04/08/2008 03:32 Re: [OpenAjaxMobile] Mobile acid PM test Please respond to OpenAjax Alliance discussion list on Mobile Ajax On Tue, 08 Apr 2008 19:37:57 +0200, Jon Ferraiolo wrote: > However, ultimately I would think the ideal best place ultimately for > acid tests would be the Web Standards Project, The WSP just blesses Acid tests at some point. As we saw with Acid3 (and Acid2 before it) this isn't the point at which the test is finalised - in both cases they have been happy to let Ian Hickson just unilaterally decide on changes to the test afterward. So if W3C makes a test that deserves the Acid tag, I think that's fine. > ... Also, I would be concerned about W3C taking the lead on > verifying "Ajax", since Ajax reflects the de facto standard of what is > implemented in browsers, which is different than what W3C standards say > should be implemented in browsers. Sure. But the direction of W3C towards doing better testing and being more concerned about the real world is one that I think we should be encouraging - we need a place to make new standards and W3C is a good one, but we also need to standardise things when they are ready, not before or after. > In particular, "Ajax" as we define > it at the alliance goes much further than XMLHttpRequest. It also > supports JSON via the dynamic SCRIPT tag, rich user interfaces > leveraging leveraging clever JavaScript, local persistent storage, > Comet-style > server push, and countless other features. I strongly suspect the things that really matter are actually quite countable... > The possible role for OpenAjax Alliance in all of this would be to help > out. We might work on requirements (i.e., acid tests need to test the > following things) and we might work on some early versions of proposed > tests. However, as I said in the previous paragraph, the Web Standards > Project seems like a natural place long-term for mobile acid tests. Sure, getting the WaSP to bless an Acid test (or acid-style test - for some reason the W3C group don't want to use the Acid name) is a sensible thing to do. But they don't actually develop them, and since Ian registered acidtests.org they don't even host them. I think it would be very valuable if the OAA proposed stuff to be tested. Since Opera is directly represented in the relevant Working group at W3C, we will generally propose stuff through our representative there (he happens to be head of Core QA at Opera too, so we think he is pretty qualified ;) ), but I will happily cross-post to this group about ideas for more tests that involve Ajax stuff... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com _______________________________________________ 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/20080408/4e208379/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/20080408/4e208379/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic12629.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080408/4e208379/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/20080408/4e208379/attachment-0002.gif From jferrai at us.ibm.com Wed Apr 9 11:42:19 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 9 Apr 2008 11:42:19 -0700 Subject: [OpenAjaxMobile] White paper is done, agenda for tomorrow Message-ID: Rick Saletta managed to find a block of time late yesterday to complete a final draft of the white paper. I have merged in his updates (plus fixed a few editorial problems I discovered), and the white paper is now complete, clean, and (I believe) ready to send to the Marketing WG for final review and publishing: * http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax At the meeting tomorrow, I suggest that we talk about one more final deadline before turning the white paper over to the Marketing WG. In my opinion, I think we have created a very good document. Therefore, thanks very much to Rick for all of his hard work. Last week we were discussing David Pollington's email, and didn't finish, so I assume we will continue where we left off. Here is his email: * http://openajax.org/pipermail/mobile/2008q2/000163.html Which will focus our attention on the Requirements page. Jon -------------------------------- Next Conference Call Date: each Thursday (starting with March 6, ending with April 24, but skipping March 20) Time: Through end of March: 9amPT, noonET, 4pm London, 5pm Paris April and later: 9amPT, noonET, 5pm London, 6pm Paris Agenda White paper: http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax We are hoping for a final, short discussion on April 1 on the white paper, followed by final edits Device APIs Objectives: Mobile Device APIs Objectives Use cases: Mobile Device APIs Use Cases Requirements: Mobile Device APIs Requirements Security: Mobile Device APIs Security 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 IRC channel IRC channel: irc.freenode.net, #oaa-mobile Free online IRC client: http://java.freenode.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080409/b4a5e4f8/attachment-0001.html From nikunj.mehta at oracle.com Wed Apr 9 12:00:01 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Wed, 09 Apr 2008 12:00:01 -0700 Subject: [OpenAjaxMobile] White paper is done, agenda for tomorrow In-Reply-To: References: Message-ID: <47FD1231.6020404@oracle.com> As previously reported, we are still using the word web and not the correct form Web. Can this be changed? Thanks, Nikunj Jon Ferraiolo wrote: > > Rick Saletta managed to find a block of time late yesterday to > complete a final draft of the white paper. I have merged in his > updates (plus fixed a few editorial problems I discovered), and the > white paper is now complete, clean, and (I believe) ready to send to > the Marketing WG for final review and publishing: > > * http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax > > At the meeting tomorrow, I suggest that we talk about one more final > deadline before turning the white paper over to the Marketing WG. In > my opinion, I think we have created a very good document. > > Therefore, thanks very much to Rick for all of his hard work. > > Last week we were discussing David Pollington's email, and didn't > finish, so I assume we will continue where we left off. Here is his email: > > * http://openajax.org/pipermail/mobile/2008q2/000163.html > > Which will focus our attention on the Requirements page. > > Jon > > -------------------------------- > > *Next Conference Call * > > o Date: each Thursday (starting with March 6, ending with > April 24, but skipping March 20) > o Time: > # Through end of March: 9amPT, noonET, 4pm > London, 5pm Paris > # April and later: 9amPT, noonET, 5pm London, > 6pm Paris > o Agenda > # White paper: > _http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax_ > > o We are hoping for a final, short > discussion on April 1 on the white > paper, followed by final edits > # Device APIs > o Objectives: _Mobile Device APIs > Objectives_ > > > o Use cases: _Mobile Device APIs Use > Cases_ > > > o Requirements: _Mobile Device APIs > Requirements_ > > > o Security: _Mobile Device APIs > Security_ > > > > 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 > > > *IRC channel * > > o IRC channel: irc.freenode.net, #oaa-mobile > o Free online IRC client: _http://java.freenode.net/_ > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From rotan.hanrahan at mobileaware.com Wed Apr 9 12:22:39 2008 From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan) Date: Wed, 9 Apr 2008 15:22:39 -0400 Subject: [OpenAjaxMobile] W3C MWI DDWG DDR API FP/LC TR (plus a few more acronyms...) Message-ID: The W3C has published the First Public (and Last Call) draft of the Device Description Repository Simple API, a deliverable of the Device Description Working Group, and is now visible in the Technical Reports space of the W3C site. This technology is on the track to become a formal W3C Recommendation. http://www.w3.org/TR/2008/WD-DDR-Simple-API-20080404/ The public announcement is here: http://lists.w3.org/Archives/Public/public-ddwg/2008Apr/0000.html Feel free to discuss the API on the public mailing list of the DDWG, or send technical comments on the API to the dedicated comment list (mentioned in the specification). Technical comments will be accepted up to 1 May. Why is this relevant to Ajax? Because of the possibility of using information about the client device/browser to adapt the server's response (including content, style and scripts). For Ajax, a dedicated vocabulary of relevant device properties might be useful, and as anyone can create such vocabularies, the OAA is invited to do so. ---Rotan (chair of DDWG) From jferrai at us.ibm.com Wed Apr 9 13:29:25 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 9 Apr 2008 13:29:25 -0700 Subject: [OpenAjaxMobile] White paper is done, agenda for tomorrow In-Reply-To: <47FD1231.6020404@oracle.com> Message-ID: Hi Nikunj, Oh yeah, that's the thing I forgot to do. Fixed now. Jon Nikunj Mehta To Sent by: OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax enajax.org cc 04/09/2008 12:00 Subject PM Re: [OpenAjaxMobile] White paper is done, agenda for tomorrow Please respond to OpenAjax Alliance discussion list on Mobile Ajax As previously reported, we are still using the word web and not the correct form Web. Can this be changed? Thanks, Nikunj Jon Ferraiolo wrote: > > Rick Saletta managed to find a block of time late yesterday to > complete a final draft of the white paper. I have merged in his > updates (plus fixed a few editorial problems I discovered), and the > white paper is now complete, clean, and (I believe) ready to send to > the Marketing WG for final review and publishing: > > * http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax > > At the meeting tomorrow, I suggest that we talk about one more final > deadline before turning the white paper over to the Marketing WG. In > my opinion, I think we have created a very good document. > > Therefore, thanks very much to Rick for all of his hard work. > > Last week we were discussing David Pollington's email, and didn't > finish, so I assume we will continue where we left off. Here is his email: > > * http://openajax.org/pipermail/mobile/2008q2/000163.html > > Which will focus our attention on the Requirements page. > > Jon > > -------------------------------- > > *Next Conference Call * > > o Date: each Thursday (starting with March 6, ending with > April 24, but skipping March 20) > o Time: > # Through end of March: 9amPT, noonET, 4pm > London, 5pm Paris > # April and later: 9amPT, noonET, 5pm London, > 6pm Paris > o Agenda > # White paper: > _http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax_ > > o We are hoping for a final, short > discussion on April 1 on the white > paper, followed by final edits > # Device APIs > o Objectives: _Mobile Device APIs > Objectives_ > < http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives> > > o Use cases: _Mobile Device APIs Use > Cases_ > < http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases> > > o Requirements: _Mobile Device APIs > Requirements_ > < http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements> > > o Security: _Mobile Device APIs > Security_ > < http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security> > > > 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 > > > *IRC channel * > > o IRC channel: irc.freenode.net, #oaa-mobile > o Free online IRC client: _http://java.freenode.net/_ > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ 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/20080409/c81a0502/attachment-0001.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/20080409/c81a0502/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic26124.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/c81a0502/attachment-0004.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/20080409/c81a0502/attachment-0005.gif From jferrai at us.ibm.com Wed Apr 9 16:35:35 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 9 Apr 2008 16:35:35 -0700 Subject: [OpenAjaxMobile] Comments for the call tomorrow In-Reply-To: Message-ID: Hi David, I'm not sure if this addresses the full extent of your comment below, but I have now added the following bullet to our Objectives page (http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives): ----------------- We want to promote innovation, not stifle it. Therefore: Interoperability but extensible - We want to address the interoperability issues such that the 90/10 set of application scenarios (i.e., where 90% of the applications use a common 10% of features) can benefit from a write-once, run-anywhere benefit, but we also need to make sure that we do not prevent applications from bypassing the OpenAjax APIs and going to the platform APIs directly. (THIS IS WHAT'S NEW) JavaScript friendly - Much innovation is possible at the JavaScript level, where developers can develop wrapper JavaScript to provide alternate convenience APIs that provide simple ability to use a particular device service or that combine multiple device services together. Therefore, we need to architect our technologies that are friendly to such JavaScript customization. ----------------- If you see other places within our various wiki pages that we need to add text to capture your point, please add that text, or recommend what sort of text needs to be added to a particular page so I can take a stab it. Thanks. Jon "Pollington, David, VF-Group" Jon Ferraiolo/Menlo Park/IBM at IBMUS cc 04/06/2008 12:45 PM Subject RE: [OpenAjaxMobile] Comments for the call tomorrow Hi Jon, Yes, just been through the minutes and noted some of the confusion which certainly wasn't intended on my part. In terms of the specific item around the device APIs I just wanted to ensure that it was clear for anyone reading the wiki that the app developer was able to define and use their own JavaScript wrappers. I appreciate that this may be out of scope but it marks a clear distinction (at least in my understanding) from the definition of JSRs in the JCP and in the past some of the Expert Groups have been known to agonise over the exact semantics of the APIs for a long time to ensure they addressed the varied needs of the target Java developers - this issue presumably doesn't arise to such a degree for JavaScript (?). Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 From: Jon Ferraiolo [mailto:jferrai at us.ibm.com] Sent: 04 April 2008 22:48 To: Pollington, David, VF-Group Cc: mobile at openajax.org Subject: Re: [OpenAjaxMobile] Comments for the call tomorrow Hi David, I don't know if you have had a chance to review the minutes from yesterday's phone call yet, but we had questions about some of the things from your email, in particular what you mean by the term "developer". Are you referring to a system developer (e.g., someone who implements an operating system), a browser developer, an Ajax library developer, or a JavaScript application developer (who might use an Ajax library)? Our guess was that you were using the term "developer" to mean someone who is coding in JavaScript and attempting to access device services via JavaScript APIs. Is that correct? If so, then Paddy and I (and perhaps others) pointed out that JavaScript developers are not only free to create custom wrapper JavaScript functions, but in fact this would be a recommended programming practice in many scenarios. But Paddy and I think that's outside of the scope of what we need to do. Instead, our job is to define lower-level JavaScript APIs that provide more raw access to device services, on top of which Ajax libraries or individual programmers can build whatever wrapper functions they feel are desirable. Or perhaps we misunderstood. Thanks. Jon mobile-bounces at openajax.org wrote on 04/02/2008 12:11:15 PM: > Hi all, > > Apologies for not being able to make the call tomorrow, but here is > some input to the planned discussion: > > 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > In addition to the 2 options already identified (device APIs > specified, open source code), a third option (which is not mutually > exclusive) is to provide a layered API model whereby the full set of > device APIs may be provided by the underlying platform but the > developer has the freedom of developing his own set of 'working' > APIs through JavaScript wrappers. Such an approach has a number of > benefits including a) enabling the developer to decide whether they > want 10 methods for originating a call or just 1, b) enabling the > community to provide a very simple set of APIs to enable Developers > to get started (the iPhone originally only provided a single API > method for originating a call to keep things simple). > > This point also relates to the notion of providing a modular > architecture (developer deciding to use the location API without > bundling in the others) but also enables a mashup approach to APIs > whereby a developer could create a single API for accessing an > address from the address book and fetching a map (e.g., 'get map for > this contact' method). > > Getting the right balance between consistency/interoperability and > flexibility will be the key hence the suggestion for taking a multi- > tiered approach to API definition and usage. > > 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > - Support for multiple Application deployment models > > 1. conventional websites; MAY? > 2. locally installable widgets; SHOULD > 3. pre-installed widgets. MUST > > The caveat here is the phrase 'subject to security policy'; if an > adequate security mechanism can be defined and deployed then the > answer could be Should or Must to all 3... > > - Support for multi-origin models > > Agree that a developer should be able to combine different modules > to create a new Web app; the question is whether these are then > bound up and signed as a package or whether the Web app is > effectively assembled dynamically. We need to make this clear in > the requirement (whichever way we choose to state the degree of > compliancy required). > > - Support for extensibility > > Absolutely agree that developers should be able to define their own > APIs and this could be effectively managed through a multi-tiered > API model. In terms of API request, I guess it makes sense that the > app has to pre-announce the APIs it intends to use to prevent the > situation where the app loads and some of the functionality is > denied by the underlying platform giving an inconsistent user > experience. Enabling an app to determine underlying API support is > probably a Must rather than a Should to allow apps to react > accordingly and minimise impact on user experience. > > - Specific APIs > > I'll leave more detailed comments to Guillermo to contribute to the > reflector but some general comments: > > By 'Phone events' I guess we mean incoming call alerts, missed call > alerts - probably worth spelling this out. > For the Address Book we need APIs to access particular fields within > a Contact (such as phone number, address or even a Birthday) > For Files we need to add modification/editing (e.g., to save Web app > settings/state if nothing else) > > 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > > Only one comment on this paper and that's in relation to the > assumption that as native apps are able to gain access to all system > APIs (subject to the appropriate signing) then so should pre- > installed Web apps. The big issue I see here is that native apps > are typically deployed as monolithic lumps of code whereas the very > nature of a Web app is that it is connected both to the device APIs > and to the Web at the same time and potentially allows additional > script to be downloaded and executed dynamically. As such it > presents much more risk than a native app. Not sure how we solve > this one but worth pointing out the differences. > > Cheers, > > David > > > > > > > > > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington at vodafone.com > > Web: www.betavine.net > Mobile Web: betavine.mobi > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, > Berkshire RG14 2FN Registered in England No 3802001 > _______________________________________________ > 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/20080409/9d361d53/attachment-0001.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/20080409/9d361d53/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic32618.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/9d361d53/attachment-0004.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/20080409/9d361d53/attachment-0005.gif From jferrai at us.ibm.com Wed Apr 9 17:08:48 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 9 Apr 2008 17:08:48 -0700 Subject: [OpenAjaxMobile] Comments for the call tomorrow In-Reply-To: Message-ID: Follow-up to the previous email. I have made various updates to the Requirements page to reflect discussion from last week's phone call: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Most of the changes are the addition of red-colored comments and questions, but I did update the main body text in a couple of places per discussion at last week's phone call. Check the history tab to see what has changed. Jon Jon Ferraiolo/Menlo Park/IBM at IBMUS To Sent by: "Pollington, David, VF-Group" mobile-bounces at op enajax.org cc mobile at openajax.org Subject 04/09/2008 04:35 Re: [OpenAjaxMobile] Comments for PM the call tomorrow Please respond to OpenAjax Alliance discussion list on Mobile Ajax Hi David, I'm not sure if this addresses the full extent of your comment below, but I have now added the following bullet to our Objectives page ( http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives): ----------------- We want to promote innovation, not stifle it. Therefore: Interoperability but extensible - We want to address the interoperability issues such that the 90/10 set of application scenarios (i.e., where 90% of the applications use a common 10% of features) can benefit from a write-once, run-anywhere benefit, but we also need to make sure that we do not prevent applications from bypassing the OpenAjax APIs and going to the platform APIs directly. (THIS IS WHAT'S NEW) JavaScript friendly - Much innovation is possible at the JavaScript level, where developers can develop wrapper JavaScript to provide alternate convenience APIs that provide simple ability to use a particular device service or that combine multiple device services together. Therefore, we need to architect our technologies that are friendly to such JavaScript customization. ----------------- If you see other places within our various wiki pages that we need to add text to capture your point, please add that text, or recommend what sort of text needs to be added to a particular page so I can take a stab it. Thanks. Jon Inactive hide details for "Pollington, David, VF-Group" "Pollington, David, VF-Group" "Pollington, David, VF-Group" To 04/06/2008 12:45 Jon Ferraiolo/Menlo PM Park/IBM at IBMUS cc Subject RE: [OpenAjaxMobile] Comments for the call tomorrow Hi Jon, Yes, just been through the minutes and noted some of the confusion which certainly wasn't intended on my part. In terms of the specific item around the device APIs I just wanted to ensure that it was clear for anyone reading the wiki that the app developer was able to define and use their own JavaScript wrappers. I appreciate that this may be out of scope but it marks a clear distinction (at least in my understanding) from the definition of JSRs in the JCP and in the past some of the Expert Groups have been known to agonise over the exact semantics of the APIs for a long time to ensure they addressed the varied needs of the target Java developers - this issue presumably doesn't arise to such a degree for JavaScript (?). Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 From: Jon Ferraiolo [mailto:jferrai at us.ibm.com] Sent: 04 April 2008 22:48 To: Pollington, David, VF-Group Cc: mobile at openajax.org Subject: Re: [OpenAjaxMobile] Comments for the call tomorrow Hi David, I don't know if you have had a chance to review the minutes from yesterday's phone call yet, but we had questions about some of the things from your email, in particular what you mean by the term "developer". Are you referring to a system developer (e.g., someone who implements an operating system), a browser developer, an Ajax library developer, or a JavaScript application developer (who might use an Ajax library)? Our guess was that you were using the term "developer" to mean someone who is coding in JavaScript and attempting to access device services via JavaScript APIs. Is that correct? If so, then Paddy and I (and perhaps others) pointed out that JavaScript developers are not only free to create custom wrapper JavaScript functions, but in fact this would be a recommended programming practice in many scenarios. But Paddy and I think that's outside of the scope of what we need to do. Instead, our job is to define lower-level JavaScript APIs that provide more raw access to device services, on top of which Ajax libraries or individual programmers can build whatever wrapper functions they feel are desirable. Or perhaps we misunderstood. Thanks. Jon mobile-bounces at openajax.org wrote on 04/02/2008 12:11:15 PM: > Hi all, > > Apologies for not being able to make the call tomorrow, but here is > some input to the planned discussion: > > 1. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > In addition to the 2 options already identified (device APIs > specified, open source code), a third option (which is not mutually > exclusive) is to provide a layered API model whereby the full set of > device APIs may be provided by the underlying platform but the > developer has the freedom of developing his own set of 'working' > APIs through JavaScript wrappers. Such an approach has a number of > benefits including a) enabling the developer to decide whether they > want 10 methods for originating a call or just 1, b) enabling the > community to provide a very simple set of APIs to enable Developers > to get started (the iPhone originally only provided a single API > method for originating a call to keep things simple). > > This point also relates to the notion of providing a modular > architecture (developer deciding to use the location API without > bundling in the others) but also enables a mashup approach to APIs > whereby a developer could create a single API for accessing an > address from the address book and fetching a map (e.g., 'get map for > this contact' method). > > Getting the right balance between consistency/interoperability and > flexibility will be the key hence the suggestion for taking a multi- > tiered approach to API definition and usage. > > 2. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > - Support for multiple Application deployment models > > 1. conventional websites; MAY? > 2. locally installable widgets; SHOULD > 3. pre-installed widgets. MUST > > The caveat here is the phrase 'subject to security policy'; if an > adequate security mechanism can be defined and deployed then the > answer could be Should or Must to all 3... > > - Support for multi-origin models > > Agree that a developer should be able to combine different modules > to create a new Web app; the question is whether these are then > bound up and signed as a package or whether the Web app is > effectively assembled dynamically. We need to make this clear in > the requirement (whichever way we choose to state the degree of > compliancy required). > > - Support for extensibility > > Absolutely agree that developers should be able to define their own > APIs and this could be effectively managed through a multi-tiered > API model. In terms of API request, I guess it makes sense that the > app has to pre-announce the APIs it intends to use to prevent the > situation where the app loads and some of the functionality is > denied by the underlying platform giving an inconsistent user > experience. Enabling an app to determine underlying API support is > probably a Must rather than a Should to allow apps to react > accordingly and minimise impact on user experience. > > - Specific APIs > > I'll leave more detailed comments to Guillermo to contribute to the > reflector but some general comments: > > By 'Phone events' I guess we mean incoming call alerts, missed call > alerts - probably worth spelling this out. > For the Address Book we need APIs to access particular fields within > a Contact (such as phone number, address or even a Birthday) > For Files we need to add modification/editing (e.g., to save Web app > settings/state if nothing else) > > 3. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > > Only one comment on this paper and that's in relation to the > assumption that as native apps are able to gain access to all system > APIs (subject to the appropriate signing) then so should pre- > installed Web apps. The big issue I see here is that native apps > are typically deployed as monolithic lumps of code whereas the very > nature of a Web app is that it is connected both to the device APIs > and to the Web at the same time and potentially allows additional > script to be downloaded and executed dynamically. As such it > presents much more risk than a native app. Not sure how we solve > this one but worth pointing out the differences. > > Cheers, > > David > > > > > > > > > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington at vodafone.com > > Web: www.betavine.net > Mobile Web: betavine.mobi > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, > Berkshire RG14 2FN Registered in England No 3802001 > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile _______________________________________________ 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/20080409/8a6186bb/attachment-0001.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/20080409/8a6186bb/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic10688.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/8a6186bb/attachment-0007.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/20080409/8a6186bb/attachment-0008.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 2E173485.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/8a6186bb/attachment-0009.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 2E893947.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/8a6186bb/attachment-0010.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: 2E178262.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/8a6186bb/attachment-0011.gif From jferrai at us.ibm.com Wed Apr 9 17:15:31 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 9 Apr 2008 17:15:31 -0700 Subject: [OpenAjaxMobile] W3C MWI DDWG DDR API FP/LC TR (plus a few more acronyms...) In-Reply-To: Message-ID: Hi Rotan, Thanks for pointing this out. I agree that W3C and OpenAjax Alliance should work together towards a vocabulary of device properties, particularly those having to do with mobile device services. On the OpenAjax side, we should keep this in mind as we move forward and try to capture a set of (what I'll call) "feature strings" which are the unique names for particular device services. Both client-side logic and server-side logic will want to know if a particular client supports a particular feature. Jon "Rotan Hanrahan" To Sent by: mobile-bounces at op cc enajax.org Subject [OpenAjaxMobile] W3C MWI DDWG DDR 04/09/2008 12:22 API FP/LC TR (plus a few more PM acronyms...) Please respond to OpenAjax Alliance discussion list on Mobile Ajax The W3C has published the First Public (and Last Call) draft of the Device Description Repository Simple API, a deliverable of the Device Description Working Group, and is now visible in the Technical Reports space of the W3C site. This technology is on the track to become a formal W3C Recommendation. http://www.w3.org/TR/2008/WD-DDR-Simple-API-20080404/ < http://www.w3.org/TR/2008/WD-DDR-Simple-API-20080404/> The public announcement is here: http://lists.w3.org/Archives/Public/public-ddwg/2008Apr/0000.html Feel free to discuss the API on the public mailing list of the DDWG, or send technical comments on the API to the dedicated comment list (mentioned in the specification). Technical comments will be accepted up to 1 May. Why is this relevant to Ajax? Because of the possibility of using information about the client device/browser to adapt the server's response (including content, style and scripts). For Ajax, a dedicated vocabulary of relevant device properties might be useful, and as anyone can create such vocabularies, the OAA is invited to do so. ---Rotan (chair of DDWG) _______________________________________________ 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/20080409/c8c4251c/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/20080409/c8c4251c/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic20081.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080409/c8c4251c/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/20080409/c8c4251c/attachment-0002.gif From paddy.byers at gmail.com Thu Apr 10 07:37:19 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 10 Apr 2008 15:37:19 +0100 Subject: [OpenAjaxMobile] White paper is done, agenda for tomorrow In-Reply-To: References: Message-ID: <59db1b5a0804100737m79db84a5mf9bc511c0acf77d7@mail.gmail.com> Hi, I've written some notes which aim to take us closer to an actual definition of an architecture and security framework. This is largely based on the framework that WebVM currently implements, but I have tried to re-cast it in terms of the terminology we've defined in the security page, and I've tried to describe everything in a way that is implementation-independent. I realise that this definition encapsulates many decisions that we have not discussed explictly, and I'm not proposing that these are accepted without discussion. However, I thought it would be useful to capture it, so we have something to give us an idea of what an abstractly defined framework might look like. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/6aec3f38/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: architecture.mdwn Type: application/octet-stream Size: 10976 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080410/6aec3f38/attachment-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/6aec3f38/attachment-0003.html From jferrai at us.ibm.com Thu Apr 10 08:28:25 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 10 Apr 2008 08:28:25 -0700 Subject: [OpenAjaxMobile] Paddy's submission on security framework for mobile device APIs In-Reply-To: <59db1b5a0804100737m79db84a5mf9bc511c0acf77d7@mail.gmail.com> Message-ID: Paddy, Thanks for this submission! I skimmed it and IMO it is definitely in the right direction, and all details I have read so far look to be on target. I have copied the Security TF so they can review and comment, also. (In fact, maybe the Security TF should schedule a phone call just to talk about your paper.) Whatever, I look forward to going through the document carefully in the near future. Jon "Paddy Byers" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc 04/10/2008 07:37 Subject AM Re: [OpenAjaxMobile] White paper is done, agenda for tomorrow Please respond to OpenAjax Alliance discussion list on Mobile Ajax Hi, I've written some notes which aim to take us closer to an actual definition of an architecture and security framework. This is largely based on the framework that WebVM currently implements, but I have tried to re-cast it in terms of the terminology we've defined in the security page, and I've tried to describe everything in a way that is implementation-independent. I realise that this definition encapsulates many decisions that we have not discussed explictly, and I'm not proposing that these are accepted without discussion. However, I thought it would be useful to capture it, so we have something to give us an idea of what an abstractly defined framework might look like. Thanks - Paddy[attachment "architecture.mdwn" deleted by Jon Ferraiolo/Menlo Park/IBM] (See attached file: architecture.html) _______________________________________________ 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/20080410/3c583874/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/20080410/3c583874/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic09744.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080410/3c583874/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/20080410/3c583874/attachment-0002.gif -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/3c583874/attachment-0001.html From jferrai at us.ibm.com Thu Apr 10 09:13:02 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 10 Apr 2008 09:13:02 -0700 Subject: [OpenAjaxMobile] David's email Message-ID: http://openajax.org/pipermail/mobile/2008q2/000163.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/f647c05d/attachment-0001.html From nikunj.mehta at oracle.com Thu Apr 10 15:36:20 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Thu, 10 Apr 2008 15:36:20 -0700 Subject: [OpenAjaxMobile] We need better API objectives Message-ID: <47FE9664.4000605@oracle.com> An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/ab37d9fa/attachment.html From jferrai at us.ibm.com Thu Apr 10 16:15:20 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 10 Apr 2008 16:15:20 -0700 Subject: [OpenAjaxMobile] Minutes 2008-04-10 Message-ID: Jon Ferraiolo Web Architect, Emerging Technologies IBM, San Jose, CA Mobile: +1-408-956-2413 Mobile Minutes 2008-04-10 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-10 Attendees Nikunj Mehta, Oracle Jon Ferraiolo, IBM Paddy Byers, Aplix Andrew Sledd, Ikivo (co-chair) Guillermo Caudevilla, Vodafone David Pollington, Vodafone Minutes White paper http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax Jon: Any final comments? Do we want to set a final, final date for feedback? Nikunj: Should we say something about Flash cards for local storage? Jon: Is this widely used with Ajax? Nikunj: Not sure. Might be used by widgets. Andrew: Today I don't think they are available to Ajax. Paddy: Only local storage access today is file upload via HTML forms. Nikunj: SQL based storage is becoming available, such as in HTML5. Paddy: The white paper is mainly about what exists today. Nikunj: OK to leave it out for now. Jon: In terms of the final, final date for feedback, we have been working on this white paper for months. How about saying it's done today and immediately turn it over to the Marketing WG for editorial review and publishing? DavidP: I say yes, let's press ahead. Andrew: I agree. We set a deadline twice. Today we have a quorum of active attendees. Going once, going twice, gone. RESOLUTION: Send the white paper to the Marketing WG for editorial review and publishing Continued discussion of DavidP's email (from last week) http://openajax.org/pipermail/mobile/2008q2/000163.html Jon: Let's start at the top and quickly review discussion from last week, but with David present. First thing is about extensibility. We had discussion last week with follow-on email, where we are all agreeing that JavaScript offers easy ability for toolkit developers and application developers to create custom JavaScript APIs to allow convenient functions to access a service or convenient functions to join together services. I promised to update the wiki pages to reflect this, but so far all I have added are red-colored comments that describe what we need to say. Andrew: Does JavaScript flexibility allow us to pursue a more granular approach to APIs, but without making them too hard to use. Jon: I agree that we can consider more granular APIs due to JavaScript's ease to create custom wrapper functions. Andrew: Can we capture this, where we say that we want granular and flexible while still trying to be consise? Jon: Yes, probably should capture this. Nikunj: Someone recently had an article that talked about API design. Could reference this. Nikunj: First order is to have comprehensive but independent modular approach. Second order is convenient to use. Jon: As a general guideline, I agree. Should this be under objectives or requirements? Andrew: My rule: can it be tested? If yes, then it's a requirement. Jon: Probably can't be tested, so that means objective. Nikunj: Fine as an objective. We pretty much already have it. The main part that is missing is comprehensive. We can't dismiss a use case because it translates into an inconvenient API. Paddy: Our first objective is a general framework that can define any API. But for those APIs, we can have an aspiration to find a balance between functional scope and usability. Could say that our objective is more limited to make it more convenient and accelerate time-to-market and therefore might omit a use case. Jon: Yes, the 80/20 or 90/10 rule. We will architect things for extensibility so that the remaining 20% or 10% can be added by the market. Our goal is to drive interoperability for the most common things. Paddy: The Java community tried to address every possible case. Takes a long time. DavidP: I agree with Paddy. Need to look at 80/20 and the first 80%. Nikunj: Then what we need is to be comprehensive about the top use cases. But if you have 2 options, of course choose the most convenient API. Paddy/Jon: Agreed. Andrew: Now let's move to the section on application development model. David: Question to consider: are preinstalled widgets and applications safer from a security perspective, or do we need to cover all three use cases? The Web Runtime is different because it contains network features as a core feature. Jon: Yes and no. On the yes side, Paddy has submitted a general security model that can cover all of the cases. The preinstalled widgets and applications can be considered as coming from a trusted agent and therefore fit into the security model as someone who can have access to any API because they are trusted. DavidP: But sometimes the preinstalled software comes from a 3rd party and you don't fully understand or trust it. Jon: That's the no side. Still fits into Paddy's model. Some pre-installed software comes from trusted agents. Other pre-installed software comes from untrusted agents. DavidP: The documents should reflect this. ACTION Jon to update the wiki pages to show that we should try to address all 3 scenarios Andrew: Anyone disagree with David? Paddy: All depends. There are all shades of gray. You could lock things down entirely to prevent access and feel secure, but will that be useful for the kinds of things we want to enable? Andrew: Of course, the answer is no. Paddy: It's easy to make a secure building that has no windows or doors. DavidP: Going up a level. Do we need to support all 3 scenarios? I think yes. Are they equally relevant? I think yes. Then the question is whether we can tackle all 3. That's the hard question. Andrew: We need to highlight the technology similarities. DavidP: We seem to be in accordance. Let's move on. Jon: I suggest skipping the multi-origin area as that's another security rathole and move onto the specific API section. Jon: David's email asks about detailed apis for particular areas, such as getting phone numbers from address book. I suggest that we outline the next level below what is on the requirements list so far. For address book, maybe a single bullet that identifies the sorts of APIs that we think we need, such as query and set. But that's it. DavidP: OK DavidP: Guillermo and I can help out and provide more detail. Do you want to link to use cases? Goal for next week is for everyone to flesh out details of requirements and add appropriate use cases. Is it feasible by next week? Nikunj: I wil try. Jon: How strict are we going to be about requiring use cases for each requirement? Paddy: I would vote for allowing common sense extrapolation. Jon: Do we need a comparison matrix between the features that everyone supports? Paddy: We are shooting for the common 80% case. For a long list of features, we can look at Java. Nikunj: Oracle is working on an internal spec for offline with Mobile Ajax, using Gears or equivalent technology. This is future oriented. Can we pursue something in this area. Jon: OK to do this even if future oriented so long as someone does the work. But of course we need to also finish the common 80% DavidP: We are also trying to influence the future so future-looking things can be appropriate. Nikunj: A top request for Enterprises is how to get my app to work when not connected. How do we decide what is in the 80%? DavidP: Let's see what everyone comes up with. We don't want a process that excludes things. Persistence is likely to be an important requirement for many. Paddy: Persistence is of interest everywhere, including mobile. Merits discussion. Jon: One question is whether everyone is just going to implement the features from the HTML5 spec. Will that be the one and only API for the industry? Nikunj: If you think about it, Gears hasn't caught on much, even with Google's apps. I'll describe an approach where you don't have to agree on persistence or syncing, can instead us existing IETF standards. Next week Andrew: API requirements and use cases -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080410/bf037b0d/attachment-0001.html From jferrai at us.ibm.com Fri Apr 11 09:45:50 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 11 Apr 2008 09:45:50 -0700 Subject: [OpenAjaxMobile] We need better API objectives In-Reply-To: <47FE9664.4000605@oracle.com> Message-ID: Hi Nikunj, I suggest we attempt to hammer through our Objectives via email since next week's call will focus on Requirements. I have comments below. Jon mobile-bounces at openajax.org wrote on 04/10/2008 03:36:20 PM: > We have talked about the objectives for mobile Ajax APIs. Even after > three sessions, I think we have still not adequately addressed this > issue and I have seen it overhang our discussions. IMHO this issue > has arisen because, as described, we haven't correctly/completely > identified our stakeholders, and the objectives are not clear as to > what benefits are accrued to the various stakeholders and what is > the relative importance of those benefits. > > In my attempt to address this issue, I think it will help to > separate the objectives from the principles. Both need to be borne > in mind when we develop the APIs for mobile Ajax, with objectives > trumping the principles wherever a clash occurs. I'm fine with separating objectives and principles. > > Objectives - why would developers of applications, manufacturers of > systems, and the consuming public care for this effort > > Faster innovation > First and foremost, the APIs will benefit the mobile consumer. Ajax > applications speed the delivery of innovation in mobile software. We > are interested in increasing the rate at which consumers are able to > get their hands on interesting and useful applications. To me, the two words above represent two different objectives. "Faster" reflects our short time-to-market objective for our initiative. "Innovation" reflects our desire to unleash new classes of applications. That's why the current wiki page has separate objectives titled "Unleashing innovation" and "Fast time-to-market". Also, see comment below on "Device accessibility to Ajax applications" > Interoperability > Secondly, the cost of developing and consuming such applications can > be kept down by the APIs that are made available in a non- > preferential manner to all platforms and vendors without requiring > licensing agreements. To me, interoperability is a means to an end. The primary objective is to reduce developer cost for supporting multiple mobile devices. Interoperability is one way to reduce costs. I actually prefer the existing wording, where it says "Reducing costs due to write-once, run-anywhere", which we could re-express as "Reducing costs > Device accessibility to Ajax applications > Thirdly, these APIs provide greater accessibility to device > features, thus improving the richness of experience afforded to the > mobile software consumer. I'm not sure what meaning you intend for the word "accessibility". For lots of people, the word "accessibility" (in the words of Wikipedia) "is primarily intended to assist those with disabilities". I think you mean a different definition, where applications can access device features. Many people will be confused if we use the word "accessibility" outside of the area of dealing with people with disabilities. But more importantly, I think we need to combine this objective (i.e., ability to invoke device services) with the first objective (i.e., faster innovation) because what we want to enable is faster innovation specifically around making it possible to create new types of applications that are able to invoke device-resident capabilities. One recommendation is to change the merge under the title "Promote innovation around new classes of mobile applications". > Lightweight > Finally, these APIs do not become a burden for either the developer > or the consumer. Devices don't perform substantially worse because > of the presence of these APIs. I think it is better to have separate objectives for developers vs consumers, versus a combined general notion of "lightweight". Also, isn't the term "lightweight" more suited to the principles section? Conspicuously absent from your list of objectives: (a) Any mention of security. Security concerns have been a top issue among all of the early participants in this effort. In fact, at Barcelona, some people claimed that the security issues were really the important area for potential value-add. (b) Some mention of the 80/20, 90/10 objective. In my mind, this isn't just a design principle, it is a key objective of our effort. (c) Modularity. Again, this isn't just a principle, it's an objective. (d) Extensibility. Also an objective, not just a principle. There are two areas for extensibility: (a) JavaScript programmers can create custom wrapper APIs, (b) device manufacturers can innovate under the hood and provide features beyond the APIs that we expose. > Principles - how should the APIs be developed so that the above > objectives can be satisfied. These apply first and foremost to the > designers of OpenAjax APIs and then to anyone who builds upon them. > > Make, don't break > Don't take away things that work on existing Ajax platforms. > Therefore, don't introduce mechanisms or abstractions that make it > impossible or very hard to write Ajax applications that can work on, > say desktop Web browsers. I'm fine with a make, don't break principle. > An example is the notion of multi-origin > being introduced in the security framework that doesn't exist at all > in the conventional Web. Oh, but the multi-origin model very much exists on the desktop Web. In fact, I'm not aware of any multi-origin issues that are unique to mobile devices. The only possible thing that is different with mobile is that the some multi-origin scenarios might occur at a greater percentage due to typical usage patterns, but the technology issues overall are the same. > If we do things that only work on mobile > devices or work very different on mobile devices than on desktop, it > will incur the same wrath that J2ME incurred, where the cost of > developing applications was not adequately amortizable across mobile > and non-mobile platforms. We can't say negative things about the valiant efforts of other groups and shouldn't cast any judgments about marketplace viabilities of those efforts. > User-understandable security implications Actually, I don't think it's our job to address the issue of user-understandable security implications. My thinking is that we help frame the architectural discussion within a white paper in order to help the system developers (i.e., device manufacturers, browser vendors, and other people who create runtimes) understand the issues and tradeoffs. But it is the systems developers who have to execute on delivering things that can be understood by users. > If a feature introduces a vulnerability, then make sure that the > vulnerability can be explained to an average person. My thinking is that our security framework doesn't need to be understandable to average persons, or even average developers. Our security framework documents will be read by the security specialists at the device manufacturers and browser vendors. We don't have to simplify for them, although clearly we want to express things as clearly and simply as we can in order to make it a more effective set of documents. > This is > necessary if we are to empower an average person to make the right > security decision for themself. If they can't understand it, they > won't make the right calls and end up blaming OpenAjax. If we > entrust the decision to a third-party, such as a system vendor, then > it would be detrimental to innovation as we have seen so far. Again, it's not our job to make security understandable to the average person. > Modular As I mentioned previously, I would promote modularity to an objective. > Good separation of concerns can be considered a reason why the > conventional Web has succeeded till now. We want to avoid casting judgments about why things succeeded or didn't succeed as different people have different versions of history. > With different parts of the > mobile Ajax technologies evolving at different rates and becoming > ready for mass market at different times, it is even more important > to carry over this success-inducing trait to mobile Ajax. Only load > portions of the API when an application cares for it. Paddy Byerss > comments for employing bootstrapping loaders for APIs is germane to > this issue. > Forward looking > If we are to become an engine for innovation, we have to be forward > looking. If innovation is only to make existing device capabilities > available to browser applications, then innovation is going to end > not too far from now. Although its hard to predict the future, don't > preclude possibilities that can't be proven right now. For example, > today feed readers have nothing to do with a Web browser except the > former can be used in the latter. That shouldn't mean it will always > stay that way. Just because today we are looking at mobile devices > doesn't mean that one day these same technologies wouldn't apply to > non-phone/non-mobile platforms such as laptops and set top boxes. > Also, some innovations in mobile could flow over to conventional Web > - for example access to the inbuilt camera on a laptop. The more > mobile Ajax techniques become available on desktops, the easier it > will be for people to write applications for mobile devices. I'm fine with a forward-looking principle > Extensible > Application developers and system manufacturers can extend these > APIs for incremental evolution and niche solutions. It is possible > for vendors to experiment with new features without creating an > unwanted burden for anyone not interested in these extensions. As I said above, I vote for promoting "Extensible" to an objective, not just a principle. > Ergonomic > This is probably one of the hardest principle to follow because - in > the words of Michi Henning - "it raises complex cognitive and > psychological issues." Make consistency a regression testing tool so > that it makes things easier to memorize and use. "Ergonomic" isn't the right word here as it generally connotes how people interact with machines, and our main focus is how to help developers write innovative cross-platform programs in an efficient manner. How about "ease of use" instead? > _______________________________________________ > 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/20080411/a431ef8e/attachment.html From nikunj.mehta at oracle.com Fri Apr 11 12:17:18 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Fri, 11 Apr 2008 12:17:18 -0700 Subject: [OpenAjaxMobile] We need better API objectives In-Reply-To: References: Message-ID: <47FFB93E.5000403@oracle.com> Jon Ferraiolo wrote: > > > Make, don't break > > Don't take away things that work on existing Ajax platforms. > > Therefore, don't introduce mechanisms or abstractions that make it > > impossible or very hard to write Ajax applications that can work on, > > say desktop Web browsers. > > I'm fine with a make, don't break principle. > > > An example is the notion of multi-origin > > being introduced in the security framework that doesn't exist at all > > in the conventional Web. > > Oh, but the multi-origin model very much exists on the desktop Web. In > fact, I'm not aware of any multi-origin issues that are unique to > mobile devices. The only possible thing that is different with mobile > is that the some multi-origin scenarios might occur at a greater > percentage due to typical usage patterns, but the technology issues > overall are the same. > I paraphrase from http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security#Identity_in_multiple-origin_applications The conventional browser security model makes no distinction between the rights or capabilities of scripts from different origins once they have become within scope within a given page, so it is not possible in practice to rely on any identity in this case other than the identity (ie domain) of the containing page. I am worried by the previous statement in the framework that it is necessary to decide whether it is the identity (ie domain) of the containing page, or the domain of origin of the script (or both) that is relevant to deciding whether or not to permit the action. Desktop Web browsers, AFAICT, don't restrict sites that draw upon images or JavaScript fetched from domains other than that of the root browsing context. Of course, I and others still use NoScript (tm) and other browser extensions that allow users to exercise fine-grained control over the scripts on the basis of the domain where these scripts originate. I am interested in understanding how this framework makes and doesn't break Ajax for mobile. Nikunj From nikunj.mehta at oracle.com Fri Apr 11 12:51:43 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Fri, 11 Apr 2008 12:51:43 -0700 Subject: [OpenAjaxMobile] We need better API objectives In-Reply-To: References: Message-ID: <47FFC14F.9000207@oracle.com> An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080411/6455eb8d/attachment.html From nikunj.mehta at oracle.com Fri Apr 11 17:34:45 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Fri, 11 Apr 2008 17:34:45 -0700 Subject: [OpenAjaxMobile] Mobile Ajax API requirements Message-ID: <480003A5.4040105@oracle.com> I have taken a pass at the API requirements document and put in my comments directly in to the Wiki topic. Nikunj From Andrew.Sledd at ikivo.com Tue Apr 15 23:49:45 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Wed, 16 Apr 2008 08:49:45 +0200 Subject: [OpenAjaxMobile] Mobile Ajax API requirements In-Reply-To: <480003A5.4040105@oracle.com> Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDC8C7CD@SESTHSRV10.zoomon.local> Hi Nikunj, I've just read thru the comments and sugestions you made to the requirements page. I have one immediate personal request for further clairfication. Can you further describe what you mean by the four(th) deployment models? Your wording, as pasted in below, is not unclear yet it does leave room for interpretation. "...deployment model involving single-source browser type of applications that are not widgets or conventional websites. We are also missing the likelihood of applications employing full-fledged Web controls embedded inside native applications being adequately supported." It seems that the deployment models are at the heart of many of our discussions and I'd like to better understand your points. Thanks, Andy -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: den 12 april 2008 02:35 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] Mobile Ajax API requirements I have taken a pass at the API requirements document and put in my comments directly in to the Wiki topic. Nikunj _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From Andrew.Sledd at ikivo.com Wed Apr 16 01:08:10 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Wed, 16 Apr 2008 10:08:10 +0200 Subject: [OpenAjaxMobile] Reminder: phone call tomorrow Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDC8C801@SESTHSRV10.zoomon.local> Hi everyone, As agreed earlier we have the goal of completing the Use Cases and Requirements by 30 April. We have two conference calls to complete these in a first consolidated version. We will need the contributions of each and everyone to review, comment and propose changes to the existing texts. Agenda for Thursday April 17 : Mobile Device API Requirements - review of requirements comments and new inputs http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Regards, Andy ________________________________________________ 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 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/20080416/b23dd1c4/attachment.html From nikunj.mehta at oracle.com Wed Apr 16 07:34:58 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Wed, 16 Apr 2008 07:34:58 -0700 Subject: [OpenAjaxMobile] Mobile Ajax API requirements In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDC8C7CD@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDC8C7CD@SESTHSRV10.zoomon.local> Message-ID: <48060E92.5020806@oracle.com> I presume from your question that the question is about the last two categories of deployment models: * Web controls embedded inside native applications MAY * Site-specific browser applications MAY WebKit and Internet Explorer are both available as controls that can be embedded inside other applications. For example, IE can be embedded inside help viewer. This mode is very useful for applications that can't be converted to Ajax cold turkey, but instead can embed parts of the function in a browser. For the last model, see recent work of Matthew Gertner at Mozilla. I had the name wrong previously, but in the above text the correct name appears. This category covers the use cases covered by technologies such as Bubbles , Fluid , and Prism . It is also different from general purpose Web browser replacement technologies such as Microsoft Silverlight, Adobe AIR, and JavaFX. Nikunj Andrew Sledd wrote: > Hi Nikunj, > > I've just read thru the comments and sugestions you made to the > requirements page. I have one immediate personal request for further > clairfication. > > Can you further describe what you mean by the four(th) deployment > models? > > Your wording, as pasted in below, is not unclear yet it does leave room > for interpretation. > > "...deployment model involving single-source browser type of > applications that are not widgets or conventional websites. We are also > missing the likelihood of applications employing full-fledged Web > controls embedded inside native applications being adequately > supported." > > It seems that the deployment models are at the heart of many of our > discussions and I'd like to better understand your points. > > Thanks, > Andy > > -----Original Message----- > From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] > On Behalf Of Nikunj Mehta > Sent: den 12 april 2008 02:35 > To: OpenAjax Alliance discussion list on Mobile Ajax > Subject: [OpenAjaxMobile] Mobile Ajax API requirements > > I have taken a pass at the API requirements document and put in my > comments directly in to the Wiki topic. > > Nikunj > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From paddy.byers at gmail.com Thu Apr 17 07:05:33 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 17 Apr 2008 15:05:33 +0100 Subject: [OpenAjaxMobile] Reminder: phone call tomorrow In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDC8C801@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDC8C801@SESTHSRV10.zoomon.local> Message-ID: <59db1b5a0804170705h250ab62fsda83306d5d03e083@mail.gmail.com> Apologies but I won't be able to join today's call. I realise we have a lot to do in the coming 2 weeks so feel free to give me some actions but I reserve to right to decline them :) Paddy On Wed, Apr 16, 2008 at 9:08 AM, Andrew Sledd wrote: > Hi everyone, > > As agreed earlier we have the goal of completing the Use Cases and > Requirements by 30 April. We have two conference calls to complete these in > a first consolidated version. We will need the contributions of each and > everyone to review, comment and propose changes to the existing texts. > > Agenda for Thursday April 17 : > > Mobile Device API Requirements - review of requirements comments and new > inputs > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > > > Regards, > > Andy > ________________________________________________ > 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* > > ** > > > 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. > > > _______________________________________________ > 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/20080417/d6cbe3b3/attachment.html From guillermo.caudevilla at vodafone.com Thu Apr 17 06:26:39 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Thu, 17 Apr 2008 15:26:39 +0200 Subject: [OpenAjaxMobile] Vodafone contribution to the use cases In-Reply-To: <59db1b5a0804100737m79db84a5mf9bc511c0acf77d7@mail.gmail.com> Message-ID: <5D15570EE5B94A419F79FD3A2ABF223FF75D8E@ESM9-MXMB05.vf-es.internal.vodafone.com> Hi all, See attached a Vodafone contribution to the use cases. Hope it is useful. 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 Paddy Byers Sent: jueves, 10 de abril de 2008 15:37 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] White paper is done, agenda for tomorrow Hi, I've written some notes which aim to take us closer to an actual definition of an architecture and security framework. This is largely based on the framework that WebVM currently implements, but I have tried to re-cast it in terms of the terminology we've defined in the security page, and I've tried to describe everything in a way that is implementation-independent. I realise that this definition encapsulates many decisions that we have not discussed explictly, and I'm not proposing that these are accepted without discussion. However, I thought it would be useful to capture it, so we have something to give us an idea of what an abstractly defined framework might look like. Thanks - Paddy 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/20080417/b1abdd18/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: OAA - Vodafone Use Cases Proposal.doc Type: application/msword Size: 189440 bytes Desc: OAA - Vodafone Use Cases Proposal.doc Url : http://openajax.org/pipermail/mobile/attachments/20080417/b1abdd18/attachment-0001.doc From jferrai at us.ibm.com Thu Apr 17 17:03:54 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 17 Apr 2008 17:03:54 -0700 Subject: [OpenAjaxMobile] VF use cases transferred to our use cases wiki page Message-ID: Using lots of regexp magic, I have transferred Guillermo's document onto the bottom of the use cases wiki page: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases#Vodafone-contributed_use_cases -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080417/d7203d13/attachment.html From jferrai at us.ibm.com Thu Apr 17 17:02:52 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 17 Apr 2008 17:02:52 -0700 Subject: [OpenAjaxMobile] Minutes 2008-04-17 Message-ID: Mobile Minutes 2008-04-17 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-17 Attendees Nikunj Mehta, Oracle Jon Ferraiolo, IBM Andrew Sledd, Ikivo (co-chair) Guillermo Caudevilla, Vodafone David Pollington, Vodafone Guillermo Caudevilla, Vodafone Regrets: Paddy Byers, Aplix Minutes White paper Andrew: Jon, do you have an update on the white paper? Jon: I submitted it to the Marketing WG. No email feedback so far, but I got private feedback from ILOG that they will assume a professional writer to do an editorial pass sometime this week. That's the main value-add we need from the Mktg WG. If ILOG doesn't come through, I have others who have done similar things in the past. There will be a Mktg WG phone call in the next couple of weeks where we will discuss the white paper. After that, email +1 voting within Mktg WG and then email +1 voting by Steering Committee. Then I am proposing that the Mktg WG find volunteers to condense into about 2000 words by June for the Sept. publication of AJAXWorld. Minute takers Andrew: Can people volunteer to take minutes? Nikunj: Is it possible to have audio recordings of the minutes Jon: I'll check into that. Andrew: For next week. Vodafone use cases document (sent by Guillermo via email before the meeting) Nikunj: We should reconcile and merge into the requirements document first before discussing (Jon agrees) (Jon realizes that the document is a set of use cases with requirements necessary to fulfill the use cases) Jon: Let's add the Vodafone use cases to the end of our use cases wiki page Andrew: Add add requirements from those use cases that aren't listed on requirements page Jon: Yes Guillermo: This was an exercise to describe some use cases to help us identify and prioritize APIs that are interesting and see which APIs appear most frequently. We hope others in the alliance will do the same. And maybe then discard or postpone some APIs until a second phase. It becomes clear that a popular API is location. Andrew: We have found that lots of applications are embedded and use location, camera, and mapping. Your travel blog for example. (DavidP joins) (Jon summarizes previous discussion) Andrew: And one we have a list of requirements, we prioritize them as a second step. DavidP: Yes, this was an exercise to see what APIs are most important. Yes, camera is important. But we are looking at a more detailed level to see how much complexity is needed for each API. Jon: Going up to a higher level, what I have been thinking is that in April we aren't going to get anywhere near finishing up the use cases and requirements, but we are trying to get far enough that we have a view of the landscape such that we can make decisions in May about ways to go forward. Nikunj: I suggest keeping Guillermo's use cases structure Jon: Yes, I'll merge them in and I'll preserve his structure. Andrew: Also, add header saying where the use cases came from and that we are moving some of the requirements onto the requirements page. Nikunj: Need to link use cases with requirements. Andrew: Yes, but maybe later. Do people agree with what Jon has proposed? Let's get down our thoughts in APril and then make a proposed way forward in May. As part of that future work, maybe we clean up the wiki and add cross-links. Nikunj: My concern. I would like to make sure everything is in the requirements. Andrew: Will you take an action? Nikunj: Yes, I'll do that. Andrew: Ok with you, Guillermo? Guillermo: Yes ACTION Nikunj to study the VF use cases and make sure all of them are captured within the requirements page Jon: We also need ultimately to do careful study of Java MSA and OMA's lists of APIs to make sure we have a complete list of candidate APIs. But right now we only need to skim things and make sure we aren't missing a major category. Andrew: Yes, good idea. But maybe going beyond skimming we would balance against time to market goals. Nikunj: I have already done a first pass on the OMA document and added those to our requirements page. Jon: Great! Andrew: (Talking to VF) Anything in particular from the use cases document that you want to highlight? DavidP: Nothing in particular. Just some input that we have provided. Andrew: I see that you tactfully avoided security (DP laughs) Andrew: Security should impact usage, but not the APIs themselves Nikunj: Security is a runtime issue, APIs are design time. Should be orthogonal. Have to keep them separate. Andrew: Exactly. Deployment models (from requirements page) Andrew: Let's just to the requirements page and go to the deployment model section Andrew: Nikunj could you go through the 4 deployment models? Nikunj: Based on the kinds of apps that people would want to build. Draws from desktop deployment but adds some mobile. First, browser. Is that a top goal of OpenAjax? Is so, it should be a MUST. Do we need additional text to mention this as a top goal? Jon: Agree. No need for additional text. Fine as is. Nikunj: Second, widgets. Variations of pre-installed and user-installed. I said SHOULD to promote the model for widgets, but we should do this only if widgets are going to be key to developers. Jon (and someone else): Lots of emphasis on mobile widgets, more than on the desktop Nikunj: If so, it should be a preferred model. Jon: I agree with SHOULD for widgets. Nikunj: Third. Browser control in native application such as help system. Or news feed about a particular company. I say MAY because we don't need to promote this because Ajax isn't the full model. Jon: I agree with MAY. Nikunj: 4th is site-specific browser. Instead of a general browser that can navigate to the full web, only used for a specific app scenario within one web page or a set of web pages. Also, there is some desktop integration usually. Depends on various things, such as packaging. Firefox has Prism. At the very least I wanted to highlight this emerging category. Andrew: Dynamically deployed web content with a dedicated server with a particular deployment scenario. Correct? Nikunj: Difference between 2 and 4: with 2, different widgets use the same process, with 4, each app has a different process. 4 also acts as a native application. Andrew: I support 4 DavidP: There is always a gray area between web pages and deploying and executing locally. With browsers and then widgets and then Gears in between. Often about user perception and technology used, such as Ajax or Silverlight. Andrew: It's complex. We will have a better idea as we work through use cases and requirements. Nikunj: One more thing. #4 allows Ajax to be used as a replacement for what Oracle is doing now with Java. Jon: How about changing the title for #4 to "hybrid browser application". Nikunj: That's fine. Would need to explain. Jon: Have the first sentence talk about site-specific Nikunj: Fine. Nikunj: Need use cases for this. Andrew: Guillermo and David, which deployment models are you using in your use cases? DavidP: We could easily create use cases for each deployment model. It boils down to which service you are trying to deliver and how much is dynamic. ACTION to all to add use cases for each deployment model Jon: Can we take these 4 deployment models and put onto the use cases page so they match? Andrew: Yes Nikunj: I'll do that ACTION Nikunj to update use cases page with the 4 piece deployment model Titles Andrew: Nikunj has proposed changes to the section titles on the requirements page. I think his changes are fine. Jon: Nikunj is right Andrew: OK, let's accept his title changes DavidP: Regarding "device service API requirements", programmers usually think only about device apis Andrew: We have heard that device manufacturers consider device apis to be broader than this Nikunj: I'll take a second pass and will clean up titles and the deployment model section ACTION Nikunj to clean up titles and the deployment model section -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080417/adbc8da5/attachment.html From Guenter.Klas at vodafone.com Fri Apr 18 03:51:54 2008 From: Guenter.Klas at vodafone.com (Klas, Guenter, VF-Group) Date: Fri, 18 Apr 2008 12:51:54 +0200 Subject: [OpenAjaxMobile] Minutes 2008-04-17 In-Reply-To: Message-ID: <35A49C95DFAC164C8CB1F1A99415E3CD01DDB124@EITO-MBX02.internal.vodafone.com> Hi, I spotted the line on MSA, and study of their APIs. Here the list as I have it for MSA 1.1, the maintenance release of MSA 1. Note, MSA 2 is in development in the JCP, I expect more will timely be released to the public at JavaOne, which is early May. The *s in the picture indicate conditionally mandatory APIs, e.g. doesn't make sense to demand a bluetooth API, if the device has no bluetooth capability. Guenter ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: 18 April 2008 01:03 To: mobile at openajax.org Subject: [OpenAjaxMobile] Minutes 2008-04-17 Mobile Minutes 2008-04-17 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-17 Attendees * Nikunj Mehta, Oracle * Jon Ferraiolo, IBM * Andrew Sledd, Ikivo (co-chair) * Guillermo Caudevilla, Vodafone * David Pollington, Vodafone * Guillermo Caudevilla, Vodafone Regrets: * Paddy Byers, Aplix Minutes White paper Andrew: Jon, do you have an update on the white paper? Jon: I submitted it to the Marketing WG. No email feedback so far, but I got private feedback from ILOG that they will assume a professional writer to do an editorial pass sometime this week. That's the main value-add we need from the Mktg WG. If ILOG doesn't come through, I have others who have done similar things in the past. There will be a Mktg WG phone call in the next couple of weeks where we will discuss the white paper. After that, email +1 voting within Mktg WG and then email +1 voting by Steering Committee. Then I am proposing that the Mktg WG find volunteers to condense into about 2000 words by June for the Sept. publication of AJAXWorld. Minute takers Andrew: Can people volunteer to take minutes? Nikunj: Is it possible to have audio recordings of the minutes Jon: I'll check into that. Andrew: For next week. Vodafone use cases document (sent by Guillermo via email before the meeting) Nikunj: We should reconcile and merge into the requirements document first before discussing (Jon agrees) (Jon realizes that the document is a set of use cases with requirements necessary to fulfill the use cases) Jon: Let's add the Vodafone use cases to the end of our use cases wiki page Andrew: Add add requirements from those use cases that aren't listed on requirements page Jon: Yes Guillermo: This was an exercise to describe some use cases to help us identify and prioritize APIs that are interesting and see which APIs appear most frequently. We hope others in the alliance will do the same. And maybe then discard or postpone some APIs until a second phase. It becomes clear that a popular API is location. Andrew: We have found that lots of applications are embedded and use location, camera, and mapping. Your travel blog for example. (DavidP joins) (Jon summarizes previous discussion) Andrew: And one we have a list of requirements, we prioritize them as a second step. DavidP: Yes, this was an exercise to see what APIs are most important. Yes, camera is important. But we are looking at a more detailed level to see how much complexity is needed for each API. Jon: Going up to a higher level, what I have been thinking is that in April we aren't going to get anywhere near finishing up the use cases and requirements, but we are trying to get far enough that we have a view of the landscape such that we can make decisions in May about ways to go forward. Nikunj: I suggest keeping Guillermo's use cases structure Jon: Yes, I'll merge them in and I'll preserve his structure. Andrew: Also, add header saying where the use cases came from and that we are moving some of the requirements onto the requirements page. Nikunj: Need to link use cases with requirements. Andrew: Yes, but maybe later. Do people agree with what Jon has proposed? Let's get down our thoughts in APril and then make a proposed way forward in May. As part of that future work, maybe we clean up the wiki and add cross-links. Nikunj: My concern. I would like to make sure everything is in the requirements. Andrew: Will you take an action? Nikunj: Yes, I'll do that. Andrew: Ok with you, Guillermo? Guillermo: Yes ACTION Nikunj to study the VF use cases and make sure all of them are captured within the requirements page Jon: We also need ultimately to do careful study of Java MSA and OMA's lists of APIs to make sure we have a complete list of candidate APIs. But right now we only need to skim things and make sure we aren't missing a major category. Andrew: Yes, good idea. But maybe going beyond skimming we would balance against time to market goals. Nikunj: I have already done a first pass on the OMA document and added those to our requirements page. Jon: Great! Andrew: (Talking to VF) Anything in particular from the use cases document that you want to highlight? DavidP: Nothing in particular. Just some input that we have provided. Andrew: I see that you tactfully avoided security (DP laughs) Andrew: Security should impact usage, but not the APIs themselves Nikunj: Security is a runtime issue, APIs are design time. Should be orthogonal. Have to keep them separate. Andrew: Exactly. Deployment models (from requirements page) Andrew: Let's just to the requirements page and go to the deployment model section Andrew: Nikunj could you go through the 4 deployment models? Nikunj: Based on the kinds of apps that people would want to build. Draws from desktop deployment but adds some mobile. First, browser. Is that a top goal of OpenAjax? Is so, it should be a MUST. Do we need additional text to mention this as a top goal? Jon: Agree. No need for additional text. Fine as is. Nikunj: Second, widgets. Variations of pre-installed and user-installed. I said SHOULD to promote the model for widgets, but we should do this only if widgets are going to be key to developers. Jon (and someone else): Lots of emphasis on mobile widgets, more than on the desktop Nikunj: If so, it should be a preferred model. Jon: I agree with SHOULD for widgets. Nikunj: Third. Browser control in native application such as help system. Or news feed about a particular company. I say MAY because we don't need to promote this because Ajax isn't the full model. Jon: I agree with MAY. Nikunj: 4th is site-specific browser. Instead of a general browser that can navigate to the full web, only used for a specific app scenario within one web page or a set of web pages. Also, there is some desktop integration usually. Depends on various things, such as packaging. Firefox has Prism. At the very least I wanted to highlight this emerging category. Andrew: Dynamically deployed web content with a dedicated server with a particular deployment scenario. Correct? Nikunj: Difference between 2 and 4: with 2, different widgets use the same process, with 4, each app has a different process. 4 also acts as a native application. Andrew: I support 4 DavidP: There is always a gray area between web pages and deploying and executing locally. With browsers and then widgets and then Gears in between. Often about user perception and technology used, such as Ajax or Silverlight. Andrew: It's complex. We will have a better idea as we work through use cases and requirements. Nikunj: One more thing. #4 allows Ajax to be used as a replacement for what Oracle is doing now with Java. Jon: How about changing the title for #4 to "hybrid browser application". Nikunj: That's fine. Would need to explain. Jon: Have the first sentence talk about site-specific Nikunj: Fine. Nikunj: Need use cases for this. Andrew: Guillermo and David, which deployment models are you using in your use cases? DavidP: We could easily create use cases for each deployment model. It boils down to which service you are trying to deliver and how much is dynamic. ACTION to all to add use cases for each deployment model Jon: Can we take these 4 deployment models and put onto the use cases page so they match? Andrew: Yes Nikunj: I'll do that ACTION Nikunj to update use cases page with the 4 piece deployment model Titles Andrew: Nikunj has proposed changes to the section titles on the requirements page. I think his changes are fine. Jon: Nikunj is right Andrew: OK, let's accept his title changes DavidP: Regarding "device service API requirements", programmers usually think only about device apis Andrew: We have heard that device manufacturers consider device apis to be broader than this Nikunj: I'll take a second pass and will clean up titles and the deployment model section ACTION Nikunj to clean up titles and the deployment model section -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080418/6ceaa833/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41509 bytes Desc: Outlook.jpg Url : http://openajax.org/pipermail/mobile/attachments/20080418/6ceaa833/attachment-0001.jpe From jferrai at us.ibm.com Fri Apr 18 09:18:22 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 18 Apr 2008 09:18:22 -0700 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <35A49C95DFAC164C8CB1F1A99415E3CD01DDB124@EITO-MBX02.internal.vodafone.com> Message-ID: Hi Klas, Thanks for sending the list of J2ME technologies. I have moved the list into this email for discussion. Below is the list of JSRs along with my thinking (to launch discussion) about whether we need to factor that JSR into our requirements or whether we should ignore that JSR. I haven't yet adjusted the requirements to take this list of JSRs into account. I wanted to see if there was any email discussion before messing with the requirements page. Jon ----------------------------- (-) JSR-180 - SIP (Session Initiation Protocol) For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ I'm not a networking guy, but the writeups seem to say that SIP is a request/response protocol alternative to HTTP. I don't think we should include SIP on our list of Mobile Device APIs for our initial effort. We should instead focus on higher-level APIs that sit on top of things like HTTP and SIP. What do others think? (-) JSR 177 - SATSA (Security and Trust Services API) PKI, CRYPTO, APDU As we discussed in the phone call yesterday (and at other phone calls), we are thinking that the device service APIs themselves are orthogonal to the security system. Therefore, the features from JSR 177 should server as input into our the security framework efforts, but we don't need to add any specific APIs that correspond to JSR 177. (-) JSR 172 - Web Services When it comes to Web Services, Mobile Ajax can get by with the same feature set that Desktop Ajax has. We don't need additional mobile device APIs for this. J2ME needs it because it doesn't have a browser engine to leverage. (+) JSR 234 - Multimedia Suppl. Features supported by this JSR: - Access for camera specific controls like visual settings (brightness, contrast), flashlights, lighting modes and zooming. - Proper access to radio and other channel/frequency based media sources including RDS (radio data system) - Access to advanced audio processing capabilities like equalizer, audio effects, artificial reverberation and positional 3D audio. Dynamically changing audio resources are adressed as well. - Media output direction. For example, the ability to choose whether the audio is played out from speaker of from headset. We certainly need basic ability to work with the camera and to play audio. These should be added. However, most of the features here are advanced and will be interesting to only a small subset of Ajax applications, and therefore we shouldn't clutter our requirements list with these advanced features. (+) JSR 293 - Location API 2.0 We certainly need basic ability to access current location. (-) JSR 211 - Content Handler Appears to be about asociating MIME types with particular handlers. Browser engine takes care of this already. (-) JSR 238 - Internationalization Ajax applications just have to deal with whatever i18n features are available within the browser and from JavaScript. We don't need any additional device APIs in this area. (-) JSR 287 - Vector Graphics 2.0 Ajax applications just have to deal with whatever vector graphics features are available within the browser. We don't need any additional device APIs in this area. (-) JSR 284 - 3D Graphics 3D graphics isn't a priority for mobile any more than desktop. Ajax applications just have to deal with whatever 3D features are available within the browser, which at the present is pretty much zero. We don't need any additional device APIs in this area. (+) JSR 082 - Bluetooth We certainly need basic ability to work with bluetooth. (+) JSR 075 - File and PIM We certainly need basic ability to work with the file system and the PIM . (+) JSR 205 - Messaging 2.0 We certainly need basic ability to work with SMS and MMS. (-)(?) JSR 135 - Mobile Media This JSR is about accessing "audio and multimedia resources" (presumably video). My first guess is that we should just rely on what the browser gives us in this area (which isn't so great right now without going to plugins). (-) JSR 271 - MIDP 2.1 This is about the levels of Java that need to be supported. Don't need this. We have something that is six letters better than Java, JavaScript. (-) JSR 139 - CDLC/CDC This is about minimum system levels, such as memory and processor speed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080418/d65e531c/attachment.html From nikunj.mehta at oracle.com Fri Apr 18 09:28:42 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Fri, 18 Apr 2008 09:28:42 -0700 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: References: Message-ID: <4808CC3A.2040003@oracle.com> I second this proposal. For speed readers, here arethe JSRs that are being considered for inclusion in the mobile Ajax APIs: 1. *JSR 234 - Multimedia Suppl.* 2. *JSR 293 - Location API 2.0* 3. *JSR 082 - Bluetooth* 4. *JSR 075 - File and PIM* 5. *JSR 205 - Messaging 2.0* It feels good to whittle down the requirements to this list. Nikunj Jon Ferraiolo wrote: > > Hi Klas, > Thanks for sending the list of J2ME technologies. I have moved the > list into this email for discussion. Below is the list of JSRs along > with my thinking (to launch discussion) about whether we need to > factor that JSR into our requirements or whether we should ignore that > JSR. > > I haven't yet adjusted the requirements to take this list of JSRs into > account. I wanted to see if there was any email discussion before > messing with the requirements page. > > Jon > > ----------------------------- > > > *(-) **JSR-180 - SI**P** (Session Initiation Protocol)* > > For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ > > I'm not a networking guy, but the writeups seem to say that SIP is a > request/response protocol alternative to HTTP. I don't think we should > include SIP on our list of Mobile Device APIs for our initial effort. > We should instead focus on higher-level APIs that sit on top of things > like HTTP and SIP. What do others think? > > *(-) **JSR 177 - SATSA **(Security and Trust Services API)* > * PKI, CRYPTO, APDU* > > As we discussed in the phone call yesterday (and at other phone > calls), we are thinking that the device service APIs themselves are > orthogonal to the security system. Therefore, the features from JSR > 177 should server as input into our the security framework efforts, > but we don't need to add any specific APIs that correspond to JSR 177. > > *(-) **JSR 172 - Web Services* > > When it comes to Web Services, Mobile Ajax can get by with the same > feature set that Desktop Ajax has. We don't need additional mobile > device APIs for this. J2ME needs it because it doesn't have a browser > engine to leverage. > > *(+) **JSR 234 - Multimedia Suppl.* > > Features supported by this JSR: > - Access for camera specific controls like visual settings > (brightness, contrast), flashlights, lighting modes and zooming. > - Proper access to radio and other channel/frequency based media > sources including RDS (radio data system) > - Access to advanced audio processing capabilities like equalizer, > audio effects, artificial reverberation and positional 3D audio. > Dynamically changing audio resources are adressed as well. > - Media output direction. For example, the ability to choose whether > the audio is played out from speaker of from headset. > > We certainly need basic ability to work with the camera and to play > audio. These should be added. > > However, most of the features here are advanced and will be > interesting to only a small subset of Ajax applications, and therefore > we shouldn't clutter our requirements list with these advanced features. > > *(+) **JSR 293 - Location API 2.0* > > We certainly need basic ability to access current location. > > *(-) **JSR 211 - Content Handler* > > Appears to be about asociating MIME types with particular handlers. > Browser engine takes care of this already. > > *(-) **JSR 238 - Internationalization* > > Ajax applications just have to deal with whatever i18n features are > available within the browser and from JavaScript. We don't need any > additional device APIs in this area. > > *(-) **JSR 287 - Vector Graphics 2.0* > > Ajax applications just have to deal with whatever vector graphics > features are available within the browser. We don't need any > additional device APIs in this area. > > *(-) **JSR 284 - 3D Graphics* > > 3D graphics isn't a priority for mobile any more than desktop. Ajax > applications just have to deal with whatever 3D features are available > within the browser, which at the present is pretty much zero. We don't > need any additional device APIs in this area. > > *(+) **JSR 082 - Bluetooth* > > We certainly need basic ability to work with bluetooth. > > *(+) **JSR 075 - File and PIM* > > We certainly need basic ability to work with the file system and the PIM > . > *(+) **JSR 205 - Messaging 2.0* > > We certainly need basic ability to work with SMS and MMS. > > *(-)**(?)** **JSR 135 - Mobile Media* > > This JSR is about accessing "audio and multimedia resources" > (presumably video). My first guess is that we should just rely on what > the browser gives us in this area (which isn't so great right now > without going to plugins). > > *(-) **JSR 271 - MIDP 2.1* > > This is about the levels of Java that need to be supported. Don't need > this. We have something that is six letters better than Java, JavaScript. > > *(-) **JSR 139 - CDLC/CDC* > > This is about minimum system levels, such as memory and processor speed. > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From guillermo.caudevilla at vodafone.com Fri Apr 18 09:51:02 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Fri, 18 Apr 2008 18:51:02 +0200 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <4808CC3A.2040003@oracle.com> Message-ID: <5D15570EE5B94A419F79FD3A2ABF223FF75E74@ESM9-MXMB05.vf-es.internal.vodafone.com> Yes, I also second that proposal. From the given list these are the JSR that should be included within the Scriptable API. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: viernes, 18 de abril de 2008 17:29 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second this proposal. For speed readers, here arethe JSRs that are being considered for inclusion in the mobile Ajax APIs: 1. *JSR 234 - Multimedia Suppl.* 2. *JSR 293 - Location API 2.0* 3. *JSR 082 - Bluetooth* 4. *JSR 075 - File and PIM* 5. *JSR 205 - Messaging 2.0* It feels good to whittle down the requirements to this list. Nikunj Jon Ferraiolo wrote: > > Hi Klas, > Thanks for sending the list of J2ME technologies. I have moved the > list into this email for discussion. Below is the list of JSRs along > with my thinking (to launch discussion) about whether we need to > factor that JSR into our requirements or whether we should ignore that > JSR. > > I haven't yet adjusted the requirements to take this list of JSRs into > account. I wanted to see if there was any email discussion before > messing with the requirements page. > > Jon > > ----------------------------- > > > *(-) **JSR-180 - SI**P** (Session Initiation Protocol)* > > For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ > > I'm not a networking guy, but the writeups seem to say that SIP is a > request/response protocol alternative to HTTP. I don't think we should > include SIP on our list of Mobile Device APIs for our initial effort. > We should instead focus on higher-level APIs that sit on top of things > like HTTP and SIP. What do others think? > > *(-) **JSR 177 - SATSA **(Security and Trust Services API)* > * PKI, CRYPTO, APDU* > > As we discussed in the phone call yesterday (and at other phone > calls), we are thinking that the device service APIs themselves are > orthogonal to the security system. Therefore, the features from JSR > 177 should server as input into our the security framework efforts, > but we don't need to add any specific APIs that correspond to JSR 177. > > *(-) **JSR 172 - Web Services* > > When it comes to Web Services, Mobile Ajax can get by with the same > feature set that Desktop Ajax has. We don't need additional mobile > device APIs for this. J2ME needs it because it doesn't have a browser > engine to leverage. > > *(+) **JSR 234 - Multimedia Suppl.* > > Features supported by this JSR: > - Access for camera specific controls like visual settings > (brightness, contrast), flashlights, lighting modes and zooming. > - Proper access to radio and other channel/frequency based media > sources including RDS (radio data system) > - Access to advanced audio processing capabilities like equalizer, > audio effects, artificial reverberation and positional 3D audio. > Dynamically changing audio resources are adressed as well. > - Media output direction. For example, the ability to choose whether > the audio is played out from speaker of from headset. > > We certainly need basic ability to work with the camera and to play > audio. These should be added. > > However, most of the features here are advanced and will be > interesting to only a small subset of Ajax applications, and therefore > we shouldn't clutter our requirements list with these advanced features. > > *(+) **JSR 293 - Location API 2.0* > > We certainly need basic ability to access current location. > > *(-) **JSR 211 - Content Handler* > > Appears to be about asociating MIME types with particular handlers. > Browser engine takes care of this already. > > *(-) **JSR 238 - Internationalization* > > Ajax applications just have to deal with whatever i18n features are > available within the browser and from JavaScript. We don't need any > additional device APIs in this area. > > *(-) **JSR 287 - Vector Graphics 2.0* > > Ajax applications just have to deal with whatever vector graphics > features are available within the browser. We don't need any > additional device APIs in this area. > > *(-) **JSR 284 - 3D Graphics* > > 3D graphics isn't a priority for mobile any more than desktop. Ajax > applications just have to deal with whatever 3D features are available > within the browser, which at the present is pretty much zero. We don't > need any additional device APIs in this area. > > *(+) **JSR 082 - Bluetooth* > > We certainly need basic ability to work with bluetooth. > > *(+) **JSR 075 - File and PIM* > > We certainly need basic ability to work with the file system and the > PIM . > *(+) **JSR 205 - Messaging 2.0* > > We certainly need basic ability to work with SMS and MMS. > > *(-)**(?)** **JSR 135 - Mobile Media* > > This JSR is about accessing "audio and multimedia resources" > (presumably video). My first guess is that we should just rely on what > the browser gives us in this area (which isn't so great right now > without going to plugins). > > *(-) **JSR 271 - MIDP 2.1* > > This is about the levels of Java that need to be supported. Don't need > this. We have something that is six letters better than Java, JavaScript. > > *(-) **JSR 139 - CDLC/CDC* > > This is about minimum system levels, such as memory and processor speed. > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. From Andrew.Sledd at ikivo.com Sun Apr 20 23:35:25 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Mon, 21 Apr 2008 08:35:25 +0200 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <5D15570EE5B94A419F79FD3A2ABF223FF75E74@ESM9-MXMB05.vf-es.internal.vodafone.com> Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDC8CBFB@SESTHSRV10.zoomon.local> I second that second.... The capabilities of these JSRs provide a good review of the capabilities that we need to be providing in the Device API. As an aside and for information may I point out that the JSRs from Klaus' list are from the Mobile Service Architecture 2 (MSA 2 aka JSR-249 still in Early Draft Review) and not MSA 1 (JSR-248 Final and released). Most of the JSRs in MSA 2 are second versions of those in the MSA 1, some of which are still in development. Andy -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Caudevilla, Guillermo,VF-ES (gcaudev) Sent: den 18 april 2008 18:51 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies Yes, I also second that proposal. From the given list these are the JSR that should be included within the Scriptable API. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: viernes, 18 de abril de 2008 17:29 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second this proposal. For speed readers, here arethe JSRs that are being considered for inclusion in the mobile Ajax APIs: 1. *JSR 234 - Multimedia Suppl.* 2. *JSR 293 - Location API 2.0* 3. *JSR 082 - Bluetooth* 4. *JSR 075 - File and PIM* 5. *JSR 205 - Messaging 2.0* It feels good to whittle down the requirements to this list. Nikunj Jon Ferraiolo wrote: > > Hi Klas, > Thanks for sending the list of J2ME technologies. I have moved the > list into this email for discussion. Below is the list of JSRs along > with my thinking (to launch discussion) about whether we need to > factor that JSR into our requirements or whether we should ignore that > JSR. > > I haven't yet adjusted the requirements to take this list of JSRs into > account. I wanted to see if there was any email discussion before > messing with the requirements page. > > Jon > > ----------------------------- > > > *(-) **JSR-180 - SI**P** (Session Initiation Protocol)* > > For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ > > I'm not a networking guy, but the writeups seem to say that SIP is a > request/response protocol alternative to HTTP. I don't think we should > include SIP on our list of Mobile Device APIs for our initial effort. > We should instead focus on higher-level APIs that sit on top of things > like HTTP and SIP. What do others think? > > *(-) **JSR 177 - SATSA **(Security and Trust Services API)* > * PKI, CRYPTO, APDU* > > As we discussed in the phone call yesterday (and at other phone > calls), we are thinking that the device service APIs themselves are > orthogonal to the security system. Therefore, the features from JSR > 177 should server as input into our the security framework efforts, > but we don't need to add any specific APIs that correspond to JSR 177. > > *(-) **JSR 172 - Web Services* > > When it comes to Web Services, Mobile Ajax can get by with the same > feature set that Desktop Ajax has. We don't need additional mobile > device APIs for this. J2ME needs it because it doesn't have a browser > engine to leverage. > > *(+) **JSR 234 - Multimedia Suppl.* > > Features supported by this JSR: > - Access for camera specific controls like visual settings > (brightness, contrast), flashlights, lighting modes and zooming. > - Proper access to radio and other channel/frequency based media > sources including RDS (radio data system) > - Access to advanced audio processing capabilities like equalizer, > audio effects, artificial reverberation and positional 3D audio. > Dynamically changing audio resources are adressed as well. > - Media output direction. For example, the ability to choose whether > the audio is played out from speaker of from headset. > > We certainly need basic ability to work with the camera and to play > audio. These should be added. > > However, most of the features here are advanced and will be > interesting to only a small subset of Ajax applications, and therefore > we shouldn't clutter our requirements list with these advanced features. > > *(+) **JSR 293 - Location API 2.0* > > We certainly need basic ability to access current location. > > *(-) **JSR 211 - Content Handler* > > Appears to be about asociating MIME types with particular handlers. > Browser engine takes care of this already. > > *(-) **JSR 238 - Internationalization* > > Ajax applications just have to deal with whatever i18n features are > available within the browser and from JavaScript. We don't need any > additional device APIs in this area. > > *(-) **JSR 287 - Vector Graphics 2.0* > > Ajax applications just have to deal with whatever vector graphics > features are available within the browser. We don't need any > additional device APIs in this area. > > *(-) **JSR 284 - 3D Graphics* > > 3D graphics isn't a priority for mobile any more than desktop. Ajax > applications just have to deal with whatever 3D features are available > within the browser, which at the present is pretty much zero. We don't > need any additional device APIs in this area. > > *(+) **JSR 082 - Bluetooth* > > We certainly need basic ability to work with bluetooth. > > *(+) **JSR 075 - File and PIM* > > We certainly need basic ability to work with the file system and the > PIM . > *(+) **JSR 205 - Messaging 2.0* > > We certainly need basic ability to work with SMS and MMS. > > *(-)**(?)** **JSR 135 - Mobile Media* > > This JSR is about accessing "audio and multimedia resources" > (presumably video). My first guess is that we should just rely on what > the browser gives us in this area (which isn't so great right now > without going to plugins). > > *(-) **JSR 271 - MIDP 2.1* > > This is about the levels of Java that need to be supported. Don't need > this. We have something that is six letters better than Java, JavaScript. > > *(-) **JSR 139 - CDLC/CDC* > > This is about minimum system levels, such as memory and processor speed. > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From rotan.hanrahan at mobileaware.com Mon Apr 21 00:36:26 2008 From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan) Date: Mon, 21 Apr 2008 03:36:26 -0400 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDC8CBFB@SESTHSRV10.zoomon.local> References: <5D15570EE5B94A419F79FD3A2ABF223FF75E74@ESM9-MXMB05.vf-es.internal.vodafone.com> <234EB4699C751A4A95DF4FD8D041BBFDC8CBFB@SESTHSRV10.zoomon.local> Message-ID: A good set of technologies, yes. Note that the MSA2 review is due for completion by the end of next month, it doesn't define any new APIs (just references those that already exist, or are at an advanced stage of update), is expected to be backward compatible with MSA1 (JSR-248) and once it is released will be the main focus for specification conformance by manufacturers that employ JME in their products. How long it would take for the industry to take notice, I could not possibly say... ---Rotan. -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Andrew Sledd Sent: 21 April 2008 07:35 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second that second.... The capabilities of these JSRs provide a good review of the capabilities that we need to be providing in the Device API. As an aside and for information may I point out that the JSRs from Klaus' list are from the Mobile Service Architecture 2 (MSA 2 aka JSR-249 still in Early Draft Review) and not MSA 1 (JSR-248 Final and released). Most of the JSRs in MSA 2 are second versions of those in the MSA 1, some of which are still in development. Andy -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Caudevilla, Guillermo,VF-ES (gcaudev) Sent: den 18 april 2008 18:51 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies Yes, I also second that proposal. From the given list these are the JSR that should be included within the Scriptable API. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: viernes, 18 de abril de 2008 17:29 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second this proposal. For speed readers, here arethe JSRs that are being considered for inclusion in the mobile Ajax APIs: 1. *JSR 234 - Multimedia Suppl.* 2. *JSR 293 - Location API 2.0* 3. *JSR 082 - Bluetooth* 4. *JSR 075 - File and PIM* 5. *JSR 205 - Messaging 2.0* It feels good to whittle down the requirements to this list. Nikunj Jon Ferraiolo wrote: > > Hi Klas, > Thanks for sending the list of J2ME technologies. I have moved the > list into this email for discussion. Below is the list of JSRs along > with my thinking (to launch discussion) about whether we need to > factor that JSR into our requirements or whether we should ignore that > JSR. > > I haven't yet adjusted the requirements to take this list of JSRs into > account. I wanted to see if there was any email discussion before > messing with the requirements page. > > Jon > > ----------------------------- > > > *(-) **JSR-180 - SI**P** (Session Initiation Protocol)* > > For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ > > I'm not a networking guy, but the writeups seem to say that SIP is a > request/response protocol alternative to HTTP. I don't think we should > include SIP on our list of Mobile Device APIs for our initial effort. > We should instead focus on higher-level APIs that sit on top of things > like HTTP and SIP. What do others think? > > *(-) **JSR 177 - SATSA **(Security and Trust Services API)* > * PKI, CRYPTO, APDU* > > As we discussed in the phone call yesterday (and at other phone > calls), we are thinking that the device service APIs themselves are > orthogonal to the security system. Therefore, the features from JSR > 177 should server as input into our the security framework efforts, > but we don't need to add any specific APIs that correspond to JSR 177. > > *(-) **JSR 172 - Web Services* > > When it comes to Web Services, Mobile Ajax can get by with the same > feature set that Desktop Ajax has. We don't need additional mobile > device APIs for this. J2ME needs it because it doesn't have a browser > engine to leverage. > > *(+) **JSR 234 - Multimedia Suppl.* > > Features supported by this JSR: > - Access for camera specific controls like visual settings > (brightness, contrast), flashlights, lighting modes and zooming. > - Proper access to radio and other channel/frequency based media > sources including RDS (radio data system) > - Access to advanced audio processing capabilities like equalizer, > audio effects, artificial reverberation and positional 3D audio. > Dynamically changing audio resources are adressed as well. > - Media output direction. For example, the ability to choose whether > the audio is played out from speaker of from headset. > > We certainly need basic ability to work with the camera and to play > audio. These should be added. > > However, most of the features here are advanced and will be > interesting to only a small subset of Ajax applications, and therefore > we shouldn't clutter our requirements list with these advanced features. > > *(+) **JSR 293 - Location API 2.0* > > We certainly need basic ability to access current location. > > *(-) **JSR 211 - Content Handler* > > Appears to be about asociating MIME types with particular handlers. > Browser engine takes care of this already. > > *(-) **JSR 238 - Internationalization* > > Ajax applications just have to deal with whatever i18n features are > available within the browser and from JavaScript. We don't need any > additional device APIs in this area. > > *(-) **JSR 287 - Vector Graphics 2.0* > > Ajax applications just have to deal with whatever vector graphics > features are available within the browser. We don't need any > additional device APIs in this area. > > *(-) **JSR 284 - 3D Graphics* > > 3D graphics isn't a priority for mobile any more than desktop. Ajax > applications just have to deal with whatever 3D features are available > within the browser, which at the present is pretty much zero. We don't > need any additional device APIs in this area. > > *(+) **JSR 082 - Bluetooth* > > We certainly need basic ability to work with bluetooth. > > *(+) **JSR 075 - File and PIM* > > We certainly need basic ability to work with the file system and the > PIM . > *(+) **JSR 205 - Messaging 2.0* > > We certainly need basic ability to work with SMS and MMS. > > *(-)**(?)** **JSR 135 - Mobile Media* > > This JSR is about accessing "audio and multimedia resources" > (presumably video). My first guess is that we should just rely on what > the browser gives us in this area (which isn't so great right now > without going to plugins). > > *(-) **JSR 271 - MIDP 2.1* > > This is about the levels of Java that need to be supported. Don't need > this. We have something that is six letters better than Java, JavaScript. > > *(-) **JSR 139 - CDLC/CDC* > > This is about minimum system levels, such as memory and processor speed. > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From jferrai at us.ibm.com Mon Apr 21 10:51:11 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 21 Apr 2008 10:51:11 -0700 Subject: [OpenAjaxMobile] Editorial review completed on Mobile Ajax white paper Message-ID: Erwan Paccard of ILOG came through as promised and performed a complete editorial review of the white paper. There were quite a large number of minor grammar and editorial fixes. I have now merged in their fixes. To see what changed, use the history tab. If anyone notices problems, please speak up before the end of this week. My assumption is that the document is now ready for publishing on our Web site, and is only awaiting +1 voting from the Marketing WG and the Steering Committee. * http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080421/a675673c/attachment.html From ksankar at cisco.com Mon Apr 21 11:34:37 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 21 Apr 2008 11:34:37 -0700 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: References: <35A49C95DFAC164C8CB1F1A99415E3CD01DDB124@EITO-MBX02.internal.vodafone.com> Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A049B8AC7@xmb-sjc-219.amer.cisco.com> Initially we had a list and some thoughts at http://www.openajax.org/member/wiki/Mobile_Device_APIs#Other_JSRs_and_Re levance_to_OpenAJAX_Mobile_Device_API . Should we separate the table and work on elaborating on the APIs ? Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Friday, April 18, 2008 9:18 AM To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] J2ME technologies Hi Klas, Thanks for sending the list of J2ME technologies. I have moved the list into this email for discussion. Below is the list of JSRs along with my thinking (to launch discussion) about whether we need to factor that JSR into our requirements or whether we should ignore that JSR. I haven't yet adjusted the requirements to take this list of JSRs into account. I wanted to see if there was any email discussion before messing with the requirements page. Jon ----------------------------- (-) JSR-180 - SIP (Session Initiation Protocol) For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ I'm not a networking guy, but the writeups seem to say that SIP is a request/response protocol alternative to HTTP. I don't think we should include SIP on our list of Mobile Device APIs for our initial effort. We should instead focus on higher-level APIs that sit on top of things like HTTP and SIP. What do others think? (-) JSR 177 - SATSA (Security and Trust Services API) PKI, CRYPTO, APDU As we discussed in the phone call yesterday (and at other phone calls), we are thinking that the device service APIs themselves are orthogonal to the security system. Therefore, the features from JSR 177 should server as input into our the security framework efforts, but we don't need to add any specific APIs that correspond to JSR 177. (-) JSR 172 - Web Services When it comes to Web Services, Mobile Ajax can get by with the same feature set that Desktop Ajax has. We don't need additional mobile device APIs for this. J2ME needs it because it doesn't have a browser engine to leverage. (+) JSR 234 - Multimedia Suppl. Features supported by this JSR: - Access for camera specific controls like visual settings (brightness, contrast), flashlights, lighting modes and zooming. - Proper access to radio and other channel/frequency based media sources including RDS (radio data system) - Access to advanced audio processing capabilities like equalizer, audio effects, artificial reverberation and positional 3D audio. Dynamically changing audio resources are adressed as well. - Media output direction. For example, the ability to choose whether the audio is played out from speaker of from headset. We certainly need basic ability to work with the camera and to play audio. These should be added. However, most of the features here are advanced and will be interesting to only a small subset of Ajax applications, and therefore we shouldn't clutter our requirements list with these advanced features. (+) JSR 293 - Location API 2.0 We certainly need basic ability to access current location. (-) JSR 211 - Content Handler Appears to be about asociating MIME types with particular handlers. Browser engine takes care of this already. (-) JSR 238 - Internationalization Ajax applications just have to deal with whatever i18n features are available within the browser and from JavaScript. We don't need any additional device APIs in this area. (-) JSR 287 - Vector Graphics 2.0 Ajax applications just have to deal with whatever vector graphics features are available within the browser. We don't need any additional device APIs in this area. (-) JSR 284 - 3D Graphics 3D graphics isn't a priority for mobile any more than desktop. Ajax applications just have to deal with whatever 3D features are available within the browser, which at the present is pretty much zero. We don't need any additional device APIs in this area. (+) JSR 082 - Bluetooth We certainly need basic ability to work with bluetooth. (+) JSR 075 - File and PIM We certainly need basic ability to work with the file system and the PIM . (+) JSR 205 - Messaging 2.0 We certainly need basic ability to work with SMS and MMS. (-)(?) JSR 135 - Mobile Media This JSR is about accessing "audio and multimedia resources" (presumably video). My first guess is that we should just rely on what the browser gives us in this area (which isn't so great right now without going to plugins). (-) JSR 271 - MIDP 2.1 This is about the levels of Java that need to be supported. Don't need this. We have something that is six letters better than Java, JavaScript. (-) JSR 139 - CDLC/CDC This is about minimum system levels, such as memory and processor speed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080421/66f37905/attachment-0001.html From jferrai at us.ibm.com Mon Apr 21 13:41:24 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 21 Apr 2008 13:41:24 -0700 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A049B8AC7@xmb-sjc-219.amer.cisco.com> Message-ID: Hi Krishna, Here is what I propose (which is starting to move into proposals about what OpenAjax Alliance should do after the exploratory phase ends in April): (1) Update the table where it is now [1] to reflect our latest thinking. (I haven't looked yet to see what updates are needed.) (2) Update the requirements wiki page [2] to make sure that we have line items for everything from the table that we feel is relevant (3) But only go to a highly coarse grain level regarding details for the requirements wiki page [2]. My guess is that there are lots and lots of detailed issues within each feature area that require research and work, along with figuring out what features belong in the 80 side of the 80/20 split. My thinking is that the most efficient way to sweat out the details is to do so as part of an open source project which maps a platform independent set of APIs to platform implementations, such as J2ME or MobileScript or Windows Mobile or whatever. Jon "Krishna Sankar (ksankar)" "OpenAjax Alliance discussion list Sent by: on Mobile Ajax" mobile-bounces at op enajax.org cc Subject 04/21/2008 11:34 Re: [OpenAjaxMobile] J2ME AM technologies Please respond to OpenAjax Alliance discussion list on Mobile Ajax Initially we had a list and some thoughts at http://www.openajax.org/member/wiki/Mobile_Device_APIs#Other_JSRs_and_Relevance_to_OpenAJAX_Mobile_Device_API . Should we separate the table and work on elaborating on the APIs ? Cheers From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Friday, April 18, 2008 9:18 AM To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] J2ME technologies Hi Klas, Thanks for sending the list of J2ME technologies. I have moved the list into this email for discussion. Below is the list of JSRs along with my thinking (to launch discussion) about whether we need to factor that JSR into our requirements or whether we should ignore that JSR. I haven't yet adjusted the requirements to take this list of JSRs into account. I wanted to see if there was any email discussion before messing with the requirements page. Jon ----------------------------- (-) JSR-180 - SIP (Session Initiation Protocol) For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ I'm not a networking guy, but the writeups seem to say that SIP is a request/response protocol alternative to HTTP. I don't think we should include SIP on our list of Mobile Device APIs for our initial effort. We should instead focus on higher-level APIs that sit on top of things like HTTP and SIP. What do others think? (-) JSR 177 - SATSA (Security and Trust Services API) PKI, CRYPTO, APDU As we discussed in the phone call yesterday (and at other phone calls), we are thinking that the device service APIs themselves are orthogonal to the security system. Therefore, the features from JSR 177 should server as input into our the security framework efforts, but we don't need to add any specific APIs that correspond to JSR 177. (-) JSR 172 - Web Services When it comes to Web Services, Mobile Ajax can get by with the same feature set that Desktop Ajax has. We don't need additional mobile device APIs for this. J2ME needs it because it doesn't have a browser engine to leverage. (+) JSR 234 - Multimedia Suppl. Features supported by this JSR: - Access for camera specific controls like visual settings (brightness, contrast), flashlights, lighting modes and zooming. - Proper access to radio and other channel/frequency based media sources including RDS (radio data system) - Access to advanced audio processing capabilities like equalizer, audio effects, artificial reverberation and positional 3D audio. Dynamically changing audio resources are adressed as well. - Media output direction. For example, the ability to choose whether the audio is played out from speaker of from headset. We certainly need basic ability to work with the camera and to play audio. These should be added. However, most of the features here are advanced and will be interesting to only a small subset of Ajax applications, and therefore we shouldn't clutter our requirements list with these advanced features. (+) JSR 293 - Location API 2.0 We certainly need basic ability to access current location. (-) JSR 211 - Content Handler Appears to be about asociating MIME types with particular handlers. Browser engine takes care of this already. (-) JSR 238 - Internationalization Ajax applications just have to deal with whatever i18n features are available within the browser and from JavaScript. We don't need any additional device APIs in this area. (-) JSR 287 - Vector Graphics 2.0 Ajax applications just have to deal with whatever vector graphics features are available within the browser. We don't need any additional device APIs in this area. (-) JSR 284 - 3D Graphics 3D graphics isn't a priority for mobile any more than desktop. Ajax applications just have to deal with whatever 3D features are available within the browser, which at the present is pretty much zero. We don't need any additional device APIs in this area. (+) JSR 082 - Bluetooth We certainly need basic ability to work with bluetooth. (+) JSR 075 - File and PIM We certainly need basic ability to work with the file system and the PIM . (+) JSR 205 - Messaging 2.0 We certainly need basic ability to work with SMS and MMS. (-)(?) JSR 135 - Mobile Media This JSR is about accessing "audio and multimedia resources" (presumably video). My first guess is that we should just rely on what the browser gives us in this area (which isn't so great right now without going to plugins). (-) JSR 271 - MIDP 2.1 This is about the levels of Java that need to be supported. Don't need this. We have something that is six letters better than Java, JavaScript. (-) JSR 139 - CDLC/CDC This is about minimum system levels, such as memory and processor speed. _______________________________________________ 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/20080421/ae54239f/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/20080421/ae54239f/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic16554.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080421/ae54239f/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/20080421/ae54239f/attachment-0002.gif From ksankar at cisco.com Mon Apr 21 16:49:23 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 21 Apr 2008 16:49:23 -0700 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: References: <9FA16888AD1BF64ABCE6C2532CCEB98A049B8AC7@xmb-sjc-219.amer.cisco.com> Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A049B8CC0@xmb-sjc-219.amer.cisco.com> Agreed. As I was reading your e-mail, I was also thinking of the 80/20 rule and there it is in #3 ! +1 on an open source impl. We should select the top 2 or 3 APIs (possibly location and a couple of others), implement them and go from there. Cheers P.S : BTW, am on the road and hence my absence in the con calls. Last week was in Atlanta, volunteering as Technical judge in the First Lego league World festival. ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Monday, April 21, 2008 1:41 PM To: mobile at openajax.org Subject: Re: [OpenAjaxMobile] J2ME technologies Hi Krishna, Here is what I propose (which is starting to move into proposals about what OpenAjax Alliance should do after the exploratory phase ends in April): (1) Update the table where it is now [1] to reflect our latest thinking. (I haven't looked yet to see what updates are needed.) (2) Update the requirements wiki page [2] to make sure that we have line items for everything from the table that we feel is relevant (3) But only go to a highly coarse grain level regarding details for the requirements wiki page [2]. My guess is that there are lots and lots of detailed issues within each feature area that require research and work, along with figuring out what features belong in the 80 side of the 80/20 split. My thinking is that the most efficient way to sweat out the details is to do so as part of an open source project which maps a platform independent set of APIs to platform implementations, such as J2ME or MobileScript or Windows Mobile or whatever. Jon "Krishna Sankar (ksankar)" "Krishna Sankar (ksankar)" Sent by: mobile-bounces at openajax.org 04/21/2008 11:34 AM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To "OpenAjax Alliance discussion list on Mobile Ajax" cc Subject Re: [OpenAjaxMobile] J2ME technologies Initially we had a list and some thoughts at http://www.openajax.org/member/wiki/Mobile_Device_APIs#Other_JSRs_and_Re levance_to_OpenAJAX_Mobile_Device_API . Should we separate the table and work on elaborating on the APIs ? Cheers ________________________________ From: mobile-bounces at openajax.org [ mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Friday, April 18, 2008 9:18 AM To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] J2ME technologies Hi Klas, Thanks for sending the list of J2ME technologies. I have moved the list into this email for discussion. Below is the list of JSRs along with my thinking (to launch discussion) about whether we need to factor that JSR into our requirements or whether we should ignore that JSR. I haven't yet adjusted the requirements to take this list of JSRs into account. I wanted to see if there was any email discussion before messing with the requirements page. Jon ----------------------------- (-) JSR-180 - SIP (Session Initiation Protocol) For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ I'm not a networking guy, but the writeups seem to say that SIP is a request/response protocol alternative to HTTP. I don't think we should include SIP on our list of Mobile Device APIs for our initial effort. We should instead focus on higher-level APIs that sit on top of things like HTTP and SIP. What do others think? (-) JSR 177 - SATSA (Security and Trust Services API) PKI, CRYPTO, APDU As we discussed in the phone call yesterday (and at other phone calls), we are thinking that the device service APIs themselves are orthogonal to the security system. Therefore, the features from JSR 177 should server as input into our the security framework efforts, but we don't need to add any specific APIs that correspond to JSR 177. (-) JSR 172 - Web Services When it comes to Web Services, Mobile Ajax can get by with the same feature set that Desktop Ajax has. We don't need additional mobile device APIs for this. J2ME needs it because it doesn't have a browser engine to leverage. (+) JSR 234 - Multimedia Suppl. Features supported by this JSR: - Access for camera specific controls like visual settings (brightness, contrast), flashlights, lighting modes and zooming. - Proper access to radio and other channel/frequency based media sources including RDS (radio data system) - Access to advanced audio processing capabilities like equalizer, audio effects, artificial reverberation and positional 3D audio. Dynamically changing audio resources are adressed as well. - Media output direction. For example, the ability to choose whether the audio is played out from speaker of from headset. We certainly need basic ability to work with the camera and to play audio. These should be added. However, most of the features here are advanced and will be interesting to only a small subset of Ajax applications, and therefore we shouldn't clutter our requirements list with these advanced features. (+) JSR 293 - Location API 2.0 We certainly need basic ability to access current location. (-) JSR 211 - Content Handler Appears to be about asociating MIME types with particular handlers. Browser engine takes care of this already. (-) JSR 238 - Internationalization Ajax applications just have to deal with whatever i18n features are available within the browser and from JavaScript. We don't need any additional device APIs in this area. (-) JSR 287 - Vector Graphics 2.0 Ajax applications just have to deal with whatever vector graphics features are available within the browser. We don't need any additional device APIs in this area. (-) JSR 284 - 3D Graphics 3D graphics isn't a priority for mobile any more than desktop. Ajax applications just have to deal with whatever 3D features are available within the browser, which at the present is pretty much zero. We don't need any additional device APIs in this area. (+) JSR 082 - Bluetooth We certainly need basic ability to work with bluetooth. (+) JSR 075 - File and PIM We certainly need basic ability to work with the file system and the PIM . (+) JSR 205 - Messaging 2.0 We certainly need basic ability to work with SMS and MMS. (-)(?) JSR 135 - Mobile Media This JSR is about accessing "audio and multimedia resources" (presumably video). My first guess is that we should just rely on what the browser gives us in this area (which isn't so great right now without going to plugins). (-) JSR 271 - MIDP 2.1 This is about the levels of Java that need to be supported. Don't need this. We have something that is six letters better than Java, JavaScript. (-) JSR 139 - CDLC/CDC This is about minimum system levels, such as memory and processor speed._______________________________________________ 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/20080421/2cb58a6b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 105 bytes Desc: graycol.gif Url : http://openajax.org/pipermail/mobile/attachments/20080421/2cb58a6b/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 45 bytes Desc: ecblank.gif Url : http://openajax.org/pipermail/mobile/attachments/20080421/2cb58a6b/attachment-0003.gif From jferrai at us.ibm.com Mon Apr 21 16:58:22 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 21 Apr 2008 16:58:22 -0700 Subject: [OpenAjaxMobile] New wiki page for Paddy's document "Architecture and Security Proposal" Message-ID: Around April 10, Paddy sent an email with an HTML attachment that contained a documented titled "Architecture and Security Proposal". I have now converted Paddy's doucment into wiki format and uploaded it to: * http://www.openajax.org/member/wiki/Paddy_Architecture_and_Security_Proposal I think the above document is very good. I included color-coded comments onto the above wiki page with my questions and comments. I also gave some thought (and included color-coded comments) about how to merge Paddy's document into the existing wiki page on security: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Maybe we can discuss Paddy's document (and its relationship to the existing Security wiki page) once we make some more progress on the Requirements page. Paddy, perhaps we can discuss some of the questions and comments I had about your paper on the email list ??? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080421/8b3ff34e/attachment.html From paddy.byers at gmail.com Mon Apr 21 17:53:44 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Tue, 22 Apr 2008 01:53:44 +0100 Subject: [OpenAjaxMobile] New wiki page for Paddy's document "Architecture and Security Proposal" In-Reply-To: References: Message-ID: <59db1b5a0804211753na922933kb279ca4c2540ff25@mail.gmail.com> Hi, > Paddy, perhaps we can discuss some of the questions and comments I had > about your paper on the email list ??? > Yes of course. Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080422/dc56c49b/attachment.html From Guenter.Klas at vodafone.com Tue Apr 22 09:10:24 2008 From: Guenter.Klas at vodafone.com (Klas, Guenter, VF-Group) Date: Tue, 22 Apr 2008 18:10:24 +0200 Subject: [OpenAjaxMobile] J2ME technologies In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDC8CBFB@SESTHSRV10.zoomon.local> Message-ID: <35A49C95DFAC164C8CB1F1A99415E3CD01DDB68E@EITO-MBX02.internal.vodafone.com> Hi there, BTW, I think the list I sent is actually MSA 1.1 Difference between MSA 1 and MSA 1.1: The payment API 229 dropped out. MSA 1.1 includes 15 numbered JSRs I believe. Released in Feb 08. MSA 2 adds some more, like e.g. contactless to support near-field-comms services or e.g. sensor API. That discussion is in fact ongoing. The spec is currently in early draft review. http://jcp.org/aboutJava/communityprocess/edr/jsr249/index.html Guenter -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Andrew Sledd Sent: 21 April 2008 07:35 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second that second.... The capabilities of these JSRs provide a good review of the capabilities that we need to be providing in the Device API. As an aside and for information may I point out that the JSRs from Klaus' list are from the Mobile Service Architecture 2 (MSA 2 aka JSR-249 still in Early Draft Review) and not MSA 1 (JSR-248 Final and released). Most of the JSRs in MSA 2 are second versions of those in the MSA 1, some of which are still in development. Andy -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Caudevilla, Guillermo,VF-ES (gcaudev) Sent: den 18 april 2008 18:51 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies Yes, I also second that proposal. From the given list these are the JSR that should be included within the Scriptable API. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: viernes, 18 de abril de 2008 17:29 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] J2ME technologies I second this proposal. For speed readers, here arethe JSRs that are being considered for inclusion in the mobile Ajax APIs: 1. *JSR 234 - Multimedia Suppl.* 2. *JSR 293 - Location API 2.0* 3. *JSR 082 - Bluetooth* 4. *JSR 075 - File and PIM* 5. *JSR 205 - Messaging 2.0* It feels good to whittle down the requirements to this list. Nikunj Jon Ferraiolo wrote: > > Hi Klas, > Thanks for sending the list of J2ME technologies. I have moved the > list into this email for discussion. Below is the list of JSRs along > with my thinking (to launch discussion) about whether we need to > factor that JSR into our requirements or whether we should ignore that > JSR. > > I haven't yet adjusted the requirements to take this list of JSRs into > account. I wanted to see if there was any email discussion before > messing with the requirements page. > > Jon > > ----------------------------- > > > *(-) **JSR-180 - SI**P** (Session Initiation Protocol)* > > For intro, see: http://developers.sun.com/mobility/apis/articles/sip/ > > I'm not a networking guy, but the writeups seem to say that SIP is a > request/response protocol alternative to HTTP. I don't think we should > include SIP on our list of Mobile Device APIs for our initial effort. > We should instead focus on higher-level APIs that sit on top of things > like HTTP and SIP. What do others think? > > *(-) **JSR 177 - SATSA **(Security and Trust Services API)* > * PKI, CRYPTO, APDU* > > As we discussed in the phone call yesterday (and at other phone > calls), we are thinking that the device service APIs themselves are > orthogonal to the security system. Therefore, the features from JSR > 177 should server as input into our the security framework efforts, > but we don't need to add any specific APIs that correspond to JSR 177. > > *(-) **JSR 172 - Web Services* > > When it comes to Web Services, Mobile Ajax can get by with the same > feature set that Desktop Ajax has. We don't need additional mobile > device APIs for this. J2ME needs it because it doesn't have a browser > engine to leverage. > > *(+) **JSR 234 - Multimedia Suppl.* > > Features supported by this JSR: > - Access for camera specific controls like visual settings > (brightness, contrast), flashlights, lighting modes and zooming. > - Proper access to radio and other channel/frequency based media > sources including RDS (radio data system) > - Access to advanced audio processing capabilities like equalizer, > audio effects, artificial reverberation and positional 3D audio. > Dynamically changing audio resources are adressed as well. > - Media output direction. For example, the ability to choose whether > the audio is played out from speaker of from headset. > > We certainly need basic ability to work with the camera and to play > audio. These should be added. > > However, most of the features here are advanced and will be > interesting to only a small subset of Ajax applications, and therefore > we shouldn't clutter our requirements list with these advanced features. > > *(+) **JSR 293 - Location API 2.0* > > We certainly need basic ability to access current location. > > *(-) **JSR 211 - Content Handler* > > Appears to be about asociating MIME types with particular handlers. > Browser engine takes care of this already. > > *(-) **JSR 238 - Internationalization* > > Ajax applications just have to deal with whatever i18n features are > available within the browser and from JavaScript. We don't need any > additional device APIs in this area. > > *(-) **JSR 287 - Vector Graphics 2.0* > > Ajax applications just have to deal with whatever vector graphics > features are available within the browser. We don't need any > additional device APIs in this area. > > *(-) **JSR 284 - 3D Graphics* > > 3D graphics isn't a priority for mobile any more than desktop. Ajax > applications just have to deal with whatever 3D features are available > within the browser, which at the present is pretty much zero. We don't > need any additional device APIs in this area. > > *(+) **JSR 082 - Bluetooth* > > We certainly need basic ability to work with bluetooth. > > *(+) **JSR 075 - File and PIM* > > We certainly need basic ability to work with the file system and the > PIM . > *(+) **JSR 205 - Messaging 2.0* > > We certainly need basic ability to work with SMS and MMS. > > *(-)**(?)** **JSR 135 - Mobile Media* > > This JSR is about accessing "audio and multimedia resources" > (presumably video). My first guess is that we should just rely on what > the browser gives us in this area (which isn't so great right now > without going to plugins). > > *(-) **JSR 271 - MIDP 2.1* > > This is about the levels of Java that need to be supported. Don't need > this. We have something that is six letters better than Java, JavaScript. > > *(-) **JSR 139 - CDLC/CDC* > > This is about minimum system levels, such as memory and processor speed. > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From jferrai at us.ibm.com Tue Apr 22 16:12:17 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 22 Apr 2008 16:12:17 -0700 Subject: [OpenAjaxMobile] Some questions to Paddy about his security paper Message-ID: Paddy, Here are some questions and discussion topics I had from your security and architecture proposal: * http://www.openajax.org/member/wiki/Paddy_Architecture_and_Security_Proposal (1) You suggest that each separate API has its own URI, both interface and implementation. From the wiki page: JON: I understand why we need to put a URI on an interface definition so that we can be sure which spec we are working with, and I understand why we need to put a URI on an implementation so implementations can be uniquely defined (we have a similar requirement with Hub 1.0). But we need to avoid putting unnecessary bookkeeping requirements and too much bureaucracy on ourselves and on the world. Therefore, I'm not sure about requiring a URI for a particular implementation of a particular interface. (2) Your document has a section on application deployment models. During last week's teleconference, we endorsed Nikunj's application deployment breakdown found at: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements#Support_for_multiple_Application_deployment_models Until Nikunj cleans up that wiki page, we agreed to Nikunj's 4 categories in blue: browser-based, widgets, native apps with web controls, and then the 4th category will be called (if I remember correctly) "Hybrid browser applications". Is Nikunj's breakdown OK with you? If so, then we need to merge your categorization in this document with Nikunj's categorization . (3) I have a clarification question for "Support for trusted systems": From the wiki page: JON: I was somewhat confused about the intended meaning here. I assume that trusted subsystems should be able to make calls to platform APIs, but the implication is that somehow or other the trusted subsystem won't allow an application to bypass security by invoking the trusted subsystem's APIs which then indirectly invoke the platform APIs. (4) Under "Action", are some words missing? (See red-colored notes on the wiki page) (5) Under "Bind", maybe I'm missing something, but I'm not sure that we need to force all implementations into a binding process. From the wiki page: JON: I don't think we should require a binding process via a binding action. I would expect that in most situations the platform takes care of linking an implementation to a scriptable API under the hood, and from the perspective of an application, all that it knows is that the given scriptable API is supported. Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080422/7ff17273/attachment.html From guillermo.caudevilla at vodafone.com Thu Apr 24 04:03:23 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Thu, 24 Apr 2008 13:03:23 +0200 Subject: [OpenAjaxMobile] Deployment model use cases Message-ID: <5D15570EE5B94A419F79FD3A2ABF223FF760EE@ESM9-MXMB05.vf-es.internal.vodafone.com> All, Below you will find some simple explanation/use cases for each deployment model in discussion. I also attach the Device API use cases once again, the use cases are the same but now they are updated with pre and post conditions information. <> Regards. Guillermo. Open Ajax Alliance - Use cases for application deployment. Full frame web sites These are regular web pages a user consumes by means of the browser. Lots of examples are already available in the web, examples in which a user can browse a site, get information, submit data in a similar way to the PC-space. Web sites accessing device APIs will also be capable of providing the user with new features such as "Click to call", meaning that the user will be able to browse a site as usual and click on a banner or ad to launch the dialer and establish a new call with a shop, for example . Web runtime based widgets Locally installed web applications retrieving and presenting data from the internet and the device. The typical example is a weather widget that a user launches to get weather information from the internet dependant on their real location. Embedded web controls inside native applications Integrating the web within native applications such as the dialer, the address book or any other third party application. An example of this would be adding a web control showing a map for each contact the user has within their address book. This way the user can browse the address book, select a contact and easily get a map showing the contact home address (which the user has stored within the device) and how to get there from their current location. Native Ajax applications Native mobile device applications (also known as Site Specific Browser Applications) which are tailored to web sites such as Flickr, Facebook or LinkedIn. These applications get the most of these web sites by integrating the device data and functionality with the site. An example of this sort of applications could be a "Flickr native Ajax application" this application would automatically connect to Flickr on launching, allowing the user to search Flickr data base of pictures, add comments to pictures as usual but also upload her own pictures seamlessly from her device multimedia gallery, launch the camera to upload a new picture on the move and automatically add location information as a tag. 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 > > 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/20080424/7e861ac0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: OAA - Vodafone Use Cases Proposal.doc Type: application/msword Size: 214528 bytes Desc: OAA - Vodafone Use Cases Proposal.doc Url : http://openajax.org/pipermail/mobile/attachments/20080424/7e861ac0/attachment-0001.doc From Andrew.Sledd at ikivo.com Thu Apr 24 07:58:17 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Thu, 24 Apr 2008 16:58:17 +0200 Subject: [OpenAjaxMobile] Reminder: Call today Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDCC3D72@SESTHSRV10.zoomon.local> Hi everyone! Just a reminder of the conference call today. Focus on the Requirements discussion. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements UC's have been update as well. http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases Guillermo sent input on UCs for different app deployment methods http://openajax.org/pipermail/mobile/2008q2/000218.html Regards, Andy ________________________________________________ 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 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/20080424/1e17a6c0/attachment.html From Andrew.Sledd at ikivo.com Sun Apr 27 23:29:22 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Mon, 28 Apr 2008 08:29:22 +0200 Subject: [OpenAjaxMobile] FW: Minutes 2008-03-27 Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDCC3F65@SESTHSRV10.zoomon.local> Mobile Minutes 2008- 04-24 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008- 04-24 Attendees * David Boloker, IBM (co-chair) * Andrew Sledd, Ikivo (co-chair) * David Pollington, Vodafone * Guillermo Caudevilla, Vodafone * Jon Ferraiolo, IBM * Paddy Byers, Aplix * Nikunj Mehta, Oracle Summary of New Actions: ACTION: Jon to remove the questions from the last section on the Survey page. ACTION: Jon to put Access & Blue Tooth into the Requirements List. ACTION: Jon to create a To Do page on the wiki. This page will capture all Actions necessary for completion of the clean-up of phase 1, uc and requirements development. ACTION: All to work actions. Take an un-assigned actions and assign it to oneself by editing the wiki. In this way we can avoid duplicating each others efforts and cover the Survey review more quickly. Minutes - scribe Andrew Scribe? Andrew: Thanks to Jon for his exemplary work in minute taking. We agreed last time to rotate the minutes taking duty. Is there a volunteer for today's call? Paddy: I might have to cut out but am willing to do it another time. No takers. Andrew: Then I will take notes today. Security Concept Proposal by Paddy Paddy : I think we can and should continue the security discussion via email. But we should involve the Security TF. Jon: Yes, I sent an email to the chair of the Security TF and am awaiting response. I believe we have gotten far on the framework proposal and involving others from the that group will be good. Mobile Device API Requirements Application Deployment Vodafone input on Deployment UCs http://openajax.org/pipermail/mobile/2008q2/000218.html David P: In our development of the UCs we were a bit unsure as to what Native Application terminology included, so we re-named the deployment method Site Specific Browser Application and this is our preferred naming, at least for the use case we present. Guillermo presents UCs and describes the combination of Device API to local device information with web access to information: Guillermo: For Native Application we think the term is confusing and that there is a better know term which expresses what we mean here. That term was introduced with Prism and used in Bubbles. The term is Site Specific Browser Application. David P: a general example is that the Site Specific Browser Application (SSBA) is presented to the user and initiated thru normal means, say by clicking an icon. It uses the onboard WebRuntime to present the information in the application. The UI is optimized for the application purposes, showing only those controls which are necessary for the specific application. Paddy: Yes, but this deployment model is doing more. Firstly, from metadata you can retrieve application specific detail. Secondly, the application is sandboxed to a degree and can add constraints like no cross side scripting or cookie capturing Nikunj: Yes, we need to think about this as two distinct things the isolation level of the applications and the coarseness of the UI. In an SSBA isolation level is much greater than other deployment methods. Paddy: It is important to separate deployment model from implementation architecture. SSBA implementation has impact on the security model but such a security model need not be restricted to this deployment model. For example a widget could offer the same isolation level. Terminology discussion. AGREE to change the term to Site Specific Browser Application. Device API Requirements Andrew: We've been reviewing existing API's as a means of determining a good scope for the UCs and Requirements. We've collected considerable information on the Survey page http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey . In line with this there was discussion last week and via email about the MSA (Java JSR-248 and 249). Nikunj made a proposal from that review which focused the scope to a few required features (http://openajax.org/pipermail/mobile/2008q2/000206.html ) Multimedia, Location, Bluetooth, File and PIM, Messaging. The Device API Survey page has something similar but different in the very last section at the bottom; Location, Some parts of security, File & PM, Content Handler, SIP. Should we reconcile these? Jon: One thing we need to do is to remove these questions from the Survey page and move relevant info to the Requirements page. Jon: Regarding Content Handling - I don't think that is necessary as the Browser handles that. The Java API is basically a mime type mapping. Agreement to remove the Content Handling for this purpose. Jon: SIP - Nikunj: There are several important protocols currently in use. SIP is not currently used. For the time being network protocols should be considered beyond the scope of this group. We will use what's there in the browsers of today... primarily HTTP Jon: going forward we may expand. General agreement ACTION: Jon to remove the questions from the last section on the Survey page. Nikunj: The MSAs have been reviewed for finding requirements appropriate for us. We need to make a more thorough review of the information on the Survey page. Andrew: What about an api for accelerometer? Jon: What does that enable? Nikunj: That provides, for example, the attitude of the device, the tilt of the device. Jon: So you could automatically sense the change from portrait to landscape? Nikunj: Yes. Jon: We should capture this. Andrew: Blue Tooth?` Nikunj: is it a network protocol which should be treated as we discussed earlier or a feature? Paddy: as part Java it provides a simple API call for accessing and transferring data. It's on the level of a serial port access to beam contacts to others, printer access, or simple file transfer. Jon: this sounds like it could be complex, and maybe just now its not a high priority, but we should put it in the list and prioritize it later. ACTION: Jon to put Access & Blue Tooth into the Requirements List. Guillermo: In reviewing UC and requirements there are aspects of content management, application launching, background and foreground events and capability discovery which we need to capture. Andrew: Yes and for many Java devices the Content Handler API helps enable the launching of other applications. We may choose to do this in another way however. Your suggestions are new and good things we need to get into the requirements list. Andrew: At each face to face meeting I've attended, two topics have come up around which there seemed to be much consensus but which I'm not user have been addressed here. Specifically persistence, or offline use, and cross context scripting e.g. Google gears worker pools. We may have covered persistence but worker pools? Jon: is it appropriate to add worker pools? This is not part of current web and not part of HTML 5. It is being distributed solely by Google and is not really part of the open web. Andrew: I have no position currently, just wanted us to review all inputs before we determine that we are finished with Phase 1 of UC and Reqs definitions. official time reached. Andrew: Does everyone have a few minutes extra to discuss our status of completion? Andrew: So, have we met our goals for UC and Requirements? We are very close to the deadline of April 30. Jon: I think we can say we've met our goals. We've certainly amassed a great deal of information and established a list of UC and Requirements. So let's recognize that achievement and then do some clean-up and the last of the due diligence. I propose the 8th of May as a date when clean-up should be completed. By that time we should have reviewed the Survey page and completed all Actions. General Agreement ACTION: Jon to create a To Do page on the wiki. This page will capture all Actions necessary for completion of the clean-up of phase 1, uc and requirements development. ACTION: All to work actions. Take an un-assigned actions and assign it to oneself by editing the wiki. In this way we can avoid duplicating each others efforts and cover the Survey review more quickly. Andrew: Lastly, there was some discussion via email about the security framework proposal made by Paddy. Is there something we should be doing to close that out? Paddy: we'll this is a proposal to address the specific security consequences for the UC we've defined. It's more important at this stage to identify the UC, the requirements and the security consequences than it is to discuss this framework proposal for meeting them. I can work on this. Andrew closes the meeting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080428/1d2c0ea0/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT10194.txt Url: http://openajax.org/pipermail/mobile/attachments/20080428/1d2c0ea0/attachment.txt From nikunj.mehta at oracle.com Mon Apr 28 11:41:58 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Mon, 28 Apr 2008 11:41:58 -0700 Subject: [OpenAjaxMobile] API due diligence tasks (was Re: FW: Minutes 2008-03-27) In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDCC3F65@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDCC3F65@SESTHSRV10.zoomon.local> Message-ID: <48161A76.5070408@oracle.com> Reminder: We had agreed to take on diligence tasks to cover the various APIs that impact the Mobile Ajax API requirements. So far no one (besides myself) seems to have taken the time to accept a task for reviewing one of the identified APIs. Since we want to complete this survey within another 10 days, it is very important to start ASAP, if you have the bandwidth or the expertise to help out. Please go to http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo#Survey_wiki_page_.28i.e..2C_Mobile_Device_APIs_Survey.29 and add your name to your selected API Thanks, Nikunj Andrew Sledd wrote: > *Mobile Minutes 2008-* *04-24* > > URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008- 04-24 > > > > > *Attendees * > > o David Boloker, IBM (co-chair) > o Andrew Sledd, Ikivo (co-chair) > o David Pollington, Vodafone > o Guillermo Caudevilla, Vodafone > o Jon Ferraiolo, IBM > o Paddy Byers, Aplix > o Nikunj Mehta, Oracle > > *Summary of New Actions:* > ACTION: Jon to remove the questions from the last section on the > Survey page. > ACTION: Jon to put Access & Blue Tooth into the Requirements List. > ACTION: Jon to create a To Do page on the wiki. This page will capture > all Actions necessary for completion of the clean-up of phase 1, uc > and requirements development. > ACTION: All to work actions. Take an un-assigned actions and assign it > to oneself by editing the wiki. In this way we can avoid duplicating > each others efforts and cover the Survey review more quickly. > > *Minutes* * - scribe Andrew* > *Scribe?* > Andrew: Thanks to Jon for his exemplary work in minute taking. We > agreed last time to rotate the minutes taking duty. Is there a > volunteer for today's call? > > Paddy: I might have to cut out but am willing to do it another time. > No takers. > Andrew: Then I will take notes today. * * > > *Security * *Concept Proposal by Paddy* > > Paddy : I think we can and should continue the security discussion via > email. But we should involve the Security TF. > > Jon: Yes, I sent an email to the chair of the Security TF and am > awaiting response. I believe we have gotten far on the framework > proposal and involving others from the that group will be good. > > > > > Mobile Device API Requirements > > *Application Deployment* > > *Vodafone input on Deployment UCs* > http://openajax.org/pipermail/mobile/2008q2/000218.html > > David P: In our development of the UCs we were a bit unsure as to > what Native Application terminology included, so we re-named > the deployment method Site Specific Browser Application and this is > our preferred naming, at least for the use case we present. > > Guillermo presents UCs and describes the combination of Device API to > local device information with web access to information: > > Guillermo: For Native Application we think the term is confusing and > that there is a better know term which expresses what we mean here. > That term was introduced with Prism and used in Bubbles. The term is > Site Specific Browser Application. > > David P: a general example is that the Site Specific Browser > Application (SSBA) is presented to the user and initiated thru normal > means, say by clicking an icon. It uses the onboard WebRuntime to > present the information in the application. The UI is optimized for > the application purposes, showing only those controls which are > necessary for the specific application. > > Paddy: Yes, but this deployment model is doing more. Firstly, from > metadata you can retrieve application specific detail. Secondly, the > application is sandboxed to a degree and can add constraints like no > cross side scripting or cookie capturing > > Nikunj: Yes, we need to think about this as two distinct things the > isolation level of the applications and the coarseness of the UI. In > an SSBA isolation level is much greater than other deployment methods. > > Paddy: It is important to separate deployment model from > implementation architecture. SSBA implementation has impact on the > security model but such a security model need not be restricted to > this deployment model. For example a widget could offer the same > isolation level. > > Terminology discussion. AGREE to change the term to Site Specific > Browser Application. > > *Device API Requirements* > > Andrew: We've been reviewing existing API's as a means of determining > a good scope for the UCs and Requirements. We've collected > considerable information on the Survey page > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey . In > line with this there was discussion last week and via email about the > MSA (Java JSR-248 and 249). Nikunj made a proposal from that review > which focused the scope to a few required features > (http://openajax.org/pipermail/mobile/2008q2/000206.html) Multimedia, > Location, Bluetooth, File and PIM, Messaging. The Device API Survey > page has something similar but different in the very last section at > the bottom; Location, Some parts of security, File & PM, Content > Handler, SIP. > > Should we reconcile these? > > Jon: One thing we need to do is to remove these questions from the > Survey page and move relevant info to the Requirements page. > > Jon: Regarding Content Handling - I don't think that is necessary as > the Browser handles that. The Java API is basically a mime type mapping. > > Agreement to remove the Content Handling for this purpose. > > Jon: SIP - > > Nikunj: There are several important protocols currently in use. SIP is > not currently used. For the time being network protocols should be > considered beyond the scope of this group. We will use what's there in > the browsers of today... primarily HTTP > > Jon: going forward we may expand. > > General agreement > > ACTION: Jon to remove the questions from the last section on the > Survey page. > > Nikunj: The MSAs have been reviewed for finding requirements > appropriate for us. We need to make a more thorough review of the > information on the Survey page. > > > > > > Andrew: What about an api for accelerometer? > > Jon: What does that enable? > > Nikunj: That provides, for example, the attitude of the device, the > tilt of the device. > > Jon: So you could automatically sense the change from portrait to > landscape? > > Nikunj: Yes. > > Jon: We should capture this. > > Andrew: Blue Tooth?` > > Nikunj: is it a network protocol which should be treated as we > discussed earlier or a feature? > > Paddy: as part Java it provides a simple API call for accessing and > transferring data. It's on the level of a serial port access to beam > contacts to others, printer access, or simple file transfer. > > Jon: this sounds like it could be complex, and maybe just now its not > a high priority, but we should put it in the list and prioritize it > later. > > ACTION: Jon to put Access & Blue Tooth into the Requirements List. > > Guillermo: In reviewing UC and requirements there are aspects of > content management, application launching, background and foreground > events and capability discovery which we need to capture. > > Andrew: Yes and for many Java devices the Content Handler API helps > enable the launching of other applications. We may choose to do this > in another way however. Your suggestions are new and good things we > need to get into the requirements list. > > > > Andrew: At each face to face meeting I've attended, two topics have > come up around which there seemed to be much consensus but which I'm > not user have been addressed here. Specifically persistence, or > offline use, and cross context scripting e.g. Google gears worker > pools. We may have covered persistence but worker pools? > > Jon: is it appropriate to add worker pools? This is not part of > current web and not part of HTML 5. It is being distributed solely by > Google and is not really part of the open web. > > Andrew: I have no position currently, just wanted us to review all > inputs before we determine that we are finished with Phase 1 of UC and > Reqs definitions. > > official time reached. > > Andrew: Does everyone have a few minutes extra to discuss our status > of completion? > > Andrew: So, have we met our goals for UC and Requirements? We are > very close to the deadline of April 30. > > Jon: I think we can say we've met our goals. We've certainly amassed a > great deal of information and established a list of UC and > Requirements. So let's recognize that achievement and then do some > clean-up and the last of the due diligence. I propose the 8th of May > as a date when clean-up should be completed. By that time we should > have reviewed the Survey page and completed all Actions. > > General Agreement > > ACTION: Jon to create a To Do page on the wiki. This page will capture > all Actions necessary for completion of the clean-up of phase 1, uc > and requirements development. > > ACTION: All to work actions. Take an un-assigned actions and assign it > to oneself by editing the wiki. In this way we can avoid duplicating > each others efforts and cover the Survey review more quickly. > > Andrew: Lastly, there was some discussion via email about the security > framework proposal made by Paddy. Is there something we should be > doing to close that out? > > Paddy: we'll this is a proposal to address the specific security > consequences for the UC we've defined. It's more important at this > stage to identify the UC, the requirements and the security > consequences than it is to discuss this framework proposal for meeting > them. I can work on this. > > > > Andrew closes the meeting. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From jferrai at us.ibm.com Mon Apr 28 15:53:19 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 28 Apr 2008 15:53:19 -0700 Subject: [OpenAjaxMobile] RSVP: Mobile TF / Security TF joint phone call Message-ID: I have exchanged email with the chair of the Security Task Force, Larry Koved, about scheduling a phone call to have some people from the Mobile TF talk with some people from the Security TF provide some initial feedback on the security-related early work we have done for Mobile Device APIs. I would hope that we could find a time when Larry was available along with the Mobile TF people who have made most of the contributions to the security discussions. (e.g., Paddy and DavidP) Please respond to indicate whether either of these times work for you: Monday May 5 7amPT, 10amET, 3pm London, 4pm Paris Monday May 5 8amPT, 11amET, 4pm London, 5pm Paris Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris Paddy, it would help a lot if we were able to agree on a strategy for integrating your security/architecture paper with the existing security wiki page before this phone call. Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080428/e4ff0d41/attachment.html From paddy.byers at gmail.com Tue Apr 29 00:23:05 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Tue, 29 Apr 2008 08:23:05 +0100 Subject: [OpenAjaxMobile] RSVP: Mobile TF / Security TF joint phone call In-Reply-To: References: Message-ID: <59db1b5a0804290023t330eb97cw19446a643e6afa0@mail.gmail.com> Hi, Any of these times are OK for me. Thanks - Paddy On Mon, Apr 28, 2008 at 11:53 PM, Jon Ferraiolo wrote: > I have exchanged email with the chair of the Security Task Force, Larry > Koved, about scheduling a phone call to have some people from the Mobile TF > talk with some people from the Security TF provide some initial feedback on > the security-related early work we have done for Mobile Device APIs. I would > hope that we could find a time when Larry was available along with the > Mobile TF people who have made most of the contributions to the security > discussions. (e.g., Paddy and DavidP) > > Please respond to indicate whether either of these times work for you: > > Monday May 5 7amPT, 10amET, 3pm London, 4pm Paris > Monday May 5 8amPT, 11amET, 4pm London, 5pm Paris > Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris > > Paddy, it would help a lot if we were able to agree on a strategy for > integrating your security/architecture paper with the existing security wiki > page before this phone call. > > 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/20080429/999b5433/attachment.html From guillermo.caudevilla at vodafone.com Wed Apr 30 03:51:30 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Wed, 30 Apr 2008 12:51:30 +0200 Subject: [OpenAjaxMobile] API due diligence tasks (was Re: FW: Minutes2008-03-27) In-Reply-To: <48161A76.5070408@oracle.com> Message-ID: <5D15570EE5B94A419F79FD3A2ABF223FF7632B@ESM9-MXMB05.vf-es.internal.vodafone.com> Hi Nikunj, Not sure what we have to do. Can you provide me with further explanation on the task?. I?ll be happy to accept at least any tasks related to MobileScript. Thanks. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: lunes, 28 de abril de 2008 19:42 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] API due diligence tasks (was Re: FW: Minutes2008-03-27) Reminder: We had agreed to take on diligence tasks to cover the various APIs that impact the Mobile Ajax API requirements. So far no one (besides myself) seems to have taken the time to accept a task for reviewing one of the identified APIs. Since we want to complete this survey within another 10 days, it is very important to start ASAP, if you have the bandwidth or the expertise to help out. Please go to http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo#Survey_wiki_page_.28i.e..2C_Mobile_Device_APIs_Survey.29 and add your name to your selected API Thanks, Nikunj Andrew Sledd wrote: > *Mobile Minutes 2008-* *04-24* > > URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008- 04-24 > > > > > *Attendees * > > o David Boloker, IBM (co-chair) > o Andrew Sledd, Ikivo (co-chair) > o David Pollington, Vodafone > o Guillermo Caudevilla, Vodafone > o Jon Ferraiolo, IBM > o Paddy Byers, Aplix > o Nikunj Mehta, Oracle > > *Summary of New Actions:* > ACTION: Jon to remove the questions from the last section on the > Survey page. > ACTION: Jon to put Access & Blue Tooth into the Requirements List. > ACTION: Jon to create a To Do page on the wiki. This page will capture > all Actions necessary for completion of the clean-up of phase 1, uc > and requirements development. > ACTION: All to work actions. Take an un-assigned actions and assign it > to oneself by editing the wiki. In this way we can avoid duplicating > each others efforts and cover the Survey review more quickly. > > *Minutes* * - scribe Andrew* > *Scribe?* > Andrew: Thanks to Jon for his exemplary work in minute taking. We > agreed last time to rotate the minutes taking duty. Is there a > volunteer for today's call? > > Paddy: I might have to cut out but am willing to do it another time. > No takers. > Andrew: Then I will take notes today. * * > > *Security * *Concept Proposal by Paddy* > > Paddy : I think we can and should continue the security discussion via > email. But we should involve the Security TF. > > Jon: Yes, I sent an email to the chair of the Security TF and am > awaiting response. I believe we have gotten far on the framework > proposal and involving others from the that group will be good. > > > > > Mobile Device API Requirements > > *Application Deployment* > > *Vodafone input on Deployment UCs* > http://openajax.org/pipermail/mobile/2008q2/000218.html > > David P: In our development of the UCs we were a bit unsure as to > what Native Application terminology included, so we re-named the > deployment method Site Specific Browser Application and this is our > preferred naming, at least for the use case we present. > > Guillermo presents UCs and describes the combination of Device API to > local device information with web access to information: > > Guillermo: For Native Application we think the term is confusing and > that there is a better know term which expresses what we mean here. > That term was introduced with Prism and used in Bubbles. The term is > Site Specific Browser Application. > > David P: a general example is that the Site Specific Browser > Application (SSBA) is presented to the user and initiated thru normal > means, say by clicking an icon. It uses the onboard WebRuntime to > present the information in the application. The UI is optimized for > the application purposes, showing only those controls which are > necessary for the specific application. > > Paddy: Yes, but this deployment model is doing more. Firstly, from > metadata you can retrieve application specific detail. Secondly, the > application is sandboxed to a degree and can add constraints like no > cross side scripting or cookie capturing > > Nikunj: Yes, we need to think about this as two distinct things the > isolation level of the applications and the coarseness of the UI. In > an SSBA isolation level is much greater than other deployment methods. > > Paddy: It is important to separate deployment model from > implementation architecture. SSBA implementation has impact on the > security model but such a security model need not be restricted to > this deployment model. For example a widget could offer the same > isolation level. > > Terminology discussion. AGREE to change the term to Site Specific > Browser Application. > > *Device API Requirements* > > Andrew: We've been reviewing existing API's as a means of determining > a good scope for the UCs and Requirements. We've collected > considerable information on the Survey page > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey . In > line with this there was discussion last week and via email about the > MSA (Java JSR-248 and 249). Nikunj made a proposal from that review > which focused the scope to a few required features > (http://openajax.org/pipermail/mobile/2008q2/000206.html) Multimedia, > Location, Bluetooth, File and PIM, Messaging. The Device API Survey > page has something similar but different in the very last section at > the bottom; Location, Some parts of security, File & PM, Content > Handler, SIP. > > Should we reconcile these? > > Jon: One thing we need to do is to remove these questions from the > Survey page and move relevant info to the Requirements page. > > Jon: Regarding Content Handling - I don't think that is necessary as > the Browser handles that. The Java API is basically a mime type mapping. > > Agreement to remove the Content Handling for this purpose. > > Jon: SIP - > > Nikunj: There are several important protocols currently in use. SIP is > not currently used. For the time being network protocols should be > considered beyond the scope of this group. We will use what's there in > the browsers of today... primarily HTTP > > Jon: going forward we may expand. > > General agreement > > ACTION: Jon to remove the questions from the last section on the > Survey page. > > Nikunj: The MSAs have been reviewed for finding requirements > appropriate for us. We need to make a more thorough review of the > information on the Survey page. > > > > > > Andrew: What about an api for accelerometer? > > Jon: What does that enable? > > Nikunj: That provides, for example, the attitude of the device, the > tilt of the device. > > Jon: So you could automatically sense the change from portrait to > landscape? > > Nikunj: Yes. > > Jon: We should capture this. > > Andrew: Blue Tooth?` > > Nikunj: is it a network protocol which should be treated as we > discussed earlier or a feature? > > Paddy: as part Java it provides a simple API call for accessing and > transferring data. It's on the level of a serial port access to beam > contacts to others, printer access, or simple file transfer. > > Jon: this sounds like it could be complex, and maybe just now its not > a high priority, but we should put it in the list and prioritize it > later. > > ACTION: Jon to put Access & Blue Tooth into the Requirements List. > > Guillermo: In reviewing UC and requirements there are aspects of > content management, application launching, background and foreground > events and capability discovery which we need to capture. > > Andrew: Yes and for many Java devices the Content Handler API helps > enable the launching of other applications. We may choose to do this > in another way however. Your suggestions are new and good things we > need to get into the requirements list. > > > > Andrew: At each face to face meeting I've attended, two topics have > come up around which there seemed to be much consensus but which I'm > not user have been addressed here. Specifically persistence, or > offline use, and cross context scripting e.g. Google gears worker > pools. We may have covered persistence but worker pools? > > Jon: is it appropriate to add worker pools? This is not part of > current web and not part of HTML 5. It is being distributed solely by > Google and is not really part of the open web. > > Andrew: I have no position currently, just wanted us to review all > inputs before we determine that we are finished with Phase 1 of UC and > Reqs definitions. > > official time reached. > > Andrew: Does everyone have a few minutes extra to discuss our status > of completion? > > Andrew: So, have we met our goals for UC and Requirements? We are > very close to the deadline of April 30. > > Jon: I think we can say we've met our goals. We've certainly amassed a > great deal of information and established a list of UC and > Requirements. So let's recognize that achievement and then do some > clean-up and the last of the due diligence. I propose the 8th of May > as a date when clean-up should be completed. By that time we should > have reviewed the Survey page and completed all Actions. > > General Agreement > > ACTION: Jon to create a To Do page on the wiki. This page will capture > all Actions necessary for completion of the clean-up of phase 1, uc > and requirements development. > > ACTION: All to work actions. Take an un-assigned actions and assign it > to oneself by editing the wiki. In this way we can avoid duplicating > each others efforts and cover the Survey review more quickly. > > Andrew: Lastly, there was some discussion via email about the security > framework proposal made by Paddy. Is there something we should be > doing to close that out? > > Paddy: we'll this is a proposal to address the specific security > consequences for the UC we've defined. It's more important at this > stage to identify the UC, the requirements and the security > consequences than it is to discuss this framework proposal for meeting > them. I can work on this. > > > > Andrew closes the meeting. > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. From jferrai at us.ibm.com Wed Apr 30 08:54:09 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 30 Apr 2008 08:54:09 -0700 Subject: [OpenAjaxMobile] Special joint session on May 6 on Mobile Device APIs and security Message-ID: Hello Mobile TF and Security TF, We will be holding a special coordination phone call between the Mobile TF and Security TF on Tuesday, May 6, to have some kickoff discussions about the security issues associated with Mobile Device APIs and what initiatives make sense in this area for OpenAjax Alliance. This first phone call should be considered largely informal and mainly about information exchange. I did some checking with some people involved in the discussion, and I expect attendance at least from Larry Koved (chair of Security TF), probably a few other IBM web security experts, David Pollington of Vodafone and Paddy Byers of Aplix. (Paddy has contributed a document around security issues, so it is important that he can attend.) The larger context of this phone call is as follows. Last September, the industry held a Workshop on Mobile Ajax (co-hosted by W3C and OpenAjax Alliance) where about 50 companies came together to speculate about the future of Mobile Ajax and determine what industry-wide initiatives were needed. There was a strong consensus that in order to enable the next-generation of mobile innovation the industry needed to find a way to allow the mobile Web Runtime (i.e., HTML+JavaScript) to have the ability to make JavaScript calls to device services such as current location, PIM, phone dialer, camera, SMS, MMS, and things like that. However, there are obvious security implications when mixing the Web with device-resident services. Then in March at Mobile World Congress at Barcelona, a subset of companies (~20) met at a meeting hosted by Vodafone to decide on next steps, and a number of those companies decided to pursue a fast-track exploratory initiative at OpenAjax Alliance in the months of March and April (2008) to characterize use cases, requirements and security considerations in order to get a feel for the landscape, with the idea that in May 2008 the Mobile TF can make an informed recommendation to the members of OpenAjax Alliance about future formal activities (e.g., charter a working group. launch an open source initiative, write a spec, etc.). The exploratory phase has produced an impressive amount of contribution from the participants. Here are some of the other relevant wiki pages for the Mobile Device APIs effort: Main page: http://www.openajax.org/member/wiki/Mobile_Device_APIs Use cases: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases Requirements: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Due diligence: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey The two main wiki pages that pertain to security issues around Mobile Device APIs are: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security * http://www.openajax.org/member/wiki/Paddy_Architecture_and_Security_Proposal (We hope to consolidate the above two wiki pages into a single wiki page before the phone call.) Incidentally, just to give an idea where this all might be headed, my personal thinking right now as we come to the end of the exploratory phase (which hasn't been discussed formally, let alone approved) is that OpenAjax Alliance should do two things: (1) Author an extensive white paper that characterize security concerns around Mobile Device APIs and offer conceptual models and suggestions for how mobile devices might address these concerns, (2) Launch an open source project for a JavaScript shim layer that provides Ajax developers with a write-once, run-anywhere APIs to device services, where the shim layer maps the OpenAjax APIs to platform-specific APIs. Below is the call-in information for the phone call. Jon --------- Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris 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/20080430/c0b0df8f/attachment-0001.html From jferrai at us.ibm.com Wed Apr 30 14:24:57 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 30 Apr 2008 14:24:57 -0700 Subject: [OpenAjaxMobile] Review of some technologies listed on survey page Message-ID: I went through the survey page (http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey) to look at sections that haven't been studied yet. Here is my assessment: 1. Ubiquitous Web Activity at W3C a. Delivery Context Ontology - This contains an interesting list of device capabilities queries that an Ajax application might find useful, such as the type of keyboard, pixel count, aspect ratio, and CPU chip. ***RECOMMENDATION***: Don't explicitly list them on our requirements page for version 1 support, but keep them in mind in case a particular application we want to pursue in version 1 ends up needing this information. b. Delivery Context: Cleint Interfaces - This contains generic APIs for retrieving device properties, but itself does not list any specific properties. ***RECOMMENDATION***: Nothing here that would cause us to add any new requirements. c. Device Repository API - API to allow server-side access to a repository of device characteristic information. This information is static and applies to every instance of each particular type of device. ***RECOMMENDATION***: Nothing here that would cause us to add any new requirements. d. Device Description Repository (DDR) - Descriptors for device capabilities, such as display width, color depth, markup support, and scripting support. ***RECOMMENDATION***: Don't explicitly list them on our requirements page for version 1 support, but keep them in mind in case a particular application we want to pursue in version 1 ends up needing this information. 3. Java - I did a pass through the Java tables on the survey page (http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey) and made sure that the survey page and the requirements page reflected our discussion last week about the relevance of the various JSRs. 4. Windows Mobile - I did a pass through the Windows Mobile documentation. which has a ton of APIs for C++ applications. I took a number of the items from that list and listed them under a new section on the Requirement page titled "APIs that are non-requirements". One feature that I added to the requirements list was mailing syncing. I hope to get further later today. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080430/c1d15784/attachment.html From jferrai at us.ibm.com Wed Apr 30 16:37:04 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 30 Apr 2008 16:37:04 -0700 Subject: [OpenAjaxMobile] Review of some technologies listed on survey page In-Reply-To: Message-ID: OK, I finished going through all of the references on the Mobile Device APIs Survey page, and updated the Requirements page for any features that I noticed that we had not mentioned yet. The only thing not yet finished is someone doing one more pass through the VF MobileScript spec and one more pass through our use cases to make sure that we didn't miss anything. Jon Jon Ferraiolo/Menlo Park/IBM at IBMUS To Sent by: mobile at openajax.org mobile-bounces at op cc enajax.org Subject [OpenAjaxMobile] Review of some 04/30/08 02:24 PM technologies listed on survey page Please respond to OpenAjax Alliance discussion list on Mobile Ajax I went through the survey page ( http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey) to look at sections that haven't been studied yet. Here is my assessment: 1. Ubiquitous Web Activity at W3C a. Delivery Context Ontology - This contains an interesting list of device capabilities queries that an Ajax application might find useful, such as the type of keyboard, pixel count, aspect ratio, and CPU chip. ***RECOMMENDATION***: Don't explicitly list them on our requirements page for version 1 support, but keep them in mind in case a particular application we want to pursue in version 1 ends up needing this information. b. Delivery Context: Cleint Interfaces - This contains generic APIs for retrieving device properties, but itself does not list any specific properties. ***RECOMMENDATION***: Nothing here that would cause us to add any new requirements. c. Device Repository API - API to allow server-side access to a repository of device characteristic information. This information is static and applies to every instance of each particular type of device. ***RECOMMENDATION***: Nothing here that would cause us to add any new requirements. d. Device Description Repository (DDR) - Descriptors for device capabilities, such as display width, color depth, markup support, and scripting support. ***RECOMMENDATION***: Don't explicitly list them on our requirements page for version 1 support, but keep them in mind in case a particular application we want to pursue in version 1 ends up needing this information. 3. Java - I did a pass through the Java tables on the survey page ( http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey) and made sure that the survey page and the requirements page reflected our discussion last week about the relevance of the various JSRs. 4. Windows Mobile - I did a pass through the Windows Mobile documentation. which has a ton of APIs for C++ applications. I took a number of the items from that list and listed them under a new section on the Requirement page titled "APIs that are non-requirements". One feature that I added to the requirements list was mailing syncing. I hope to get further later today. 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/20080430/9045f13f/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/20080430/9045f13f/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic10339.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080430/9045f13f/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/20080430/9045f13f/attachment-0002.gif From jferrai at us.ibm.com Wed Apr 30 16:40:16 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 30 Apr 2008 16:40:16 -0700 Subject: [OpenAjaxMobile] Reminder: phone call tomorrow (Thursday) Message-ID: Andrew Sledd can't make it, so either David Boloker or I will chair the phone call tomorrow. The main topic will be going over our todo list: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo A top priority is to merge Paddy's security document with the existing security wiki page so that we have a single document to discuss on the special phone call with the Security TF on Thursday. Thanks. Jon --------- Date: each Thursday (starting with March 6, ending on May 8, but skipping March 20) Time: Through end of March: 9amPT, noonET, 4pm London, 5pm Paris April and later: 9amPT, noonET, 5pm London, 6pm Paris Agenda Mobile Device APIs initiative home page Mobile Device APIs Objectives Mobile Device APIs Use Cases Mobile Device APIs Requirements Mobile Device APIs Security Mobile Device APIs Due Diligence Industry Survey Mobile Device APIs initiative todo list 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/20080430/31b4592a/attachment-0001.html From boloker at us.ibm.com Wed Apr 30 18:59:03 2008 From: boloker at us.ibm.com (David Boloker) Date: Wed, 30 Apr 2008 20:59:03 -0500 Subject: [OpenAjaxMobile] Reminder: phone call tomorrow (Thursday) In-Reply-To: Message-ID: Hi, Sorry I can't make it either as I'm in a customer meeting. Regrets, David Jon Ferraiolo/Menlo Park/IBM at IBMUS Sent by: mobile-bounces at openajax.org 04/30/08 07:40 PM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To mobile at openajax.org cc Subject [OpenAjaxMobile] Reminder: phone call tomorrow (Thursday) Andrew Sledd can't make it, so either David Boloker or I will chair the phone call tomorrow. The main topic will be going over our todo list: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo A top priority is to merge Paddy's security document with the existing security wiki page so that we have a single document to discuss on the special phone call with the Security TF on Thursday. Thanks. Jon --------- Date: each Thursday (starting with March 6, ending on May 8, but skipping March 20) Time: Through end of March: 9amPT, noonET, 4pm London, 5pm Paris April and later: 9amPT, noonET, 5pm London, 6pm Paris Agenda Mobile Device APIs initiative home page Mobile Device APIs Objectives Mobile Device APIs Use Cases Mobile Device APIs Requirements Mobile Device APIs Security Mobile Device APIs Due Diligence Industry Survey Mobile Device APIs initiative todo list 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 _______________________________________________ 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/20080430/da7b324c/attachment.html From paddy.byers at gmail.com Thu May 1 06:00:19 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 1 May 2008 14:00:19 +0100 Subject: [OpenAjaxMobile] Some questions to Paddy about his security paper In-Reply-To: References: Message-ID: <59db1b5a0805010600g266102e2u8d39b773c836d45@mail.gmail.com> Hi, > (1) You suggest that each separate API has its own URI, both interface and > implementation. From the wiki page: JON: I understand why we need to put a > URI on an interface definition so that we can be sure which spec we are > working with, and I understand why we need to put a URI on an implementation > so implementations can be uniquely defined (we have a similar requirement > with Hub 1.0). But we need to avoid putting unnecessary bookkeeping > requirements and too much bureaucracy on ourselves and on the world. > Therefore, I'm not sure about requiring a URI for a particular > implementation of a particular interface. > OK, it wasn't the idea that everything separate declares IDs for interface and implementation. What I was proposing is that IDs, expressed as URIs, can be defined for interfaces, if interfaces are defined independently from implementations, as well as for implementations. Then, when requesting an API (either programmatically at the time a page is loaded, say, or declaratively in a manifest/descriptor for a widget) it is possible *either* to request an implementation by ID, or solely to specify an interface, in which case it is up to the implementation to resolve that interface ID into an implementation ID. In the case that an interface is already present (eg by virtue of being implemented natively in the browser), then nothing needs to be done. > (2) Your document has a section on application deployment models. During > last week's teleconference, we endorsed Nikunj's application deployment > breakdown found at: > > * > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements#Support_for_multiple_Application_deployment_models > > Until Nikunj cleans up that wiki page, we agreed to Nikunj's 4 categories > in blue: browser-based, widgets, native apps with web controls, and then the > 4th category will be called (if I remember correctly) "Hybrid browser > applications". Is Nikunj's breakdown OK with you? If so, then we need to > merge your categorization in this document with Nikunj's categorization . > Yes, there should be a common breakdown. I'm happy with Nikunj's breakdown, but I'm not sure we have a good enough definition yet of each of them. > (3) I have a clarification question for "Support for trusted systems": > From the wiki page: JON: I was somewhat confused about the intended > meaning here. I assume that trusted subsystems should be able to make calls > to platform APIs, but the implication is that somehow or other the trusted > subsystem won't allow an application to bypass security by invoking the > trusted subsystem's APIs which then indirectly invoke the platform APIs. > Yes, trusted subsystems use platform API functionality in order to implement their own scriptable API, and can be relied upon to ensure that such "indirect" invocation of the platform APIs does not expose platform functionality that was not intended. > (4) Under "Action", are some words missing? (See red-colored notes on the > wiki page) > Yes :) I think this is a markdown -> mediawiki transcoding error. Actions are uniquely identified by the combination of: - a scheme identifier; - an action identifier; written as : So, for example a particular scheme might be used to define a series of actions corresponding to platform API calls, and another scheme might be used to define actions relating to scriptable API calls. In WebVM, where the platform APIs correspond to (already defined) Java platform API calls, we use the scheme midp: and action identifers based on Java's own permission names. In this case, a fully qualified action identifier might be: midp:javax.microedition.location.Location Different platforms might have their own naming scheme for platform APIs and/or permissions. We might also define and ooa: scheme, and a series of specific actions within that scheme, together with a mapping to equivalent actions in other schemes. > (5) Under "Bind", maybe I'm missing something, but I'm not sure that we > need to force all implementations into a binding process. From the wiki > page: JON: I don't think we should require a binding process via a binding > action. I would expect that in most situations the platform takes care of > linking an implementation to a scriptable API under the hood, and from the > perspective of an application, all that it knows is that the given > scriptable API is supported. > Even if an implementation doesn't need to perform a binding operation in order to establish the existence of an API, or bind the content to that API, I think there is still an action, subject to security checking, at which the content is granted the right to use that API. For installable widgets, this security checking might effectively take place at the time the widget is installed, or at any time prior to any of the APIs in question being called. For a web page, there might be a check, circa load-time, that the originating site is authorised to use specific APIs rather than at the specific time of an API being called. For implementations that might be required to perform some specific action to ensure the availability of any API (eg download and install a library), the bind event can serve this additional purpose, but I think a notional bind action has relevance beyond that. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080501/99ce6ebb/attachment-0001.html From paddy.byers at gmail.com Thu May 1 06:44:20 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 1 May 2008 14:44:20 +0100 Subject: [OpenAjaxMobile] New wiki page for Paddy's document "Architecture and Security Proposal" In-Reply-To: References: Message-ID: <59db1b5a0805010644ta50b732k4915b5d1610588e@mail.gmail.com> Hi, > Paddy, perhaps we can discuss some of the questions and comments I had > about your paper on the email list ??? > I've had a look at the documents again and I agree with all of your suggestions for merging the structure of the two documents. Going back to the discussion we had on the call last week, I think we should try to capture something that indicates where we think we have got to on use cases and requirements, if we can, in a way that is more definitive than the (necessarily tentative) framework proposal. Perhaps initially what we do is have the proposal, structured as you suggest, but at the end of each subsection (where there are specific proposals, not just definitions) there could be a "motivation" comment which states the reasoning behind the proposal, including explicit or implicitly assumed requirements. This way we would at least have some text that captures the requirements that underpin the proposal, which people can agree or disagree with, independent of the proposal itself. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080501/ade92c7d/attachment.html From jferrai at us.ibm.com Thu May 1 07:27:52 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 1 May 2008 07:27:52 -0700 Subject: [OpenAjaxMobile] Some questions to Paddy about his security paper In-Reply-To: <59db1b5a0805010600g266102e2u8d39b773c836d45@mail.gmail.com> Message-ID: Paddy, Thanks! Comments below as follows: JON2: (In green this time.) Jon "Paddy Byers" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc 05/01/08 06:00 AM Subject Re: [OpenAjaxMobile] Some questions to Paddy about his security paper Please respond to OpenAjax Alliance discussion list on Mobile Ajax Hi, (1) You suggest that each separate API has its own URI, both interface and implementation. From the wiki page: JON: I understand why we need to put a URI on an interface definition so that we can be sure which spec we are working with, and I understand why we need to put a URI on an implementation so implementations can be uniquely defined (we have a similar requirement with Hub 1.0). But we need to avoid putting unnecessary bookkeeping requirements and too much bureaucracy on ourselves and on the world. Therefore, I'm not sure about requiring a URI for a particular implementation of a particular interface. OK, it wasn't the idea that everything separate declares IDs for interface and implementation. What I was proposing is that IDs, expressed as URIs, can be defined for interfaces, if interfaces are defined independently from implementations, as well as for implementations. Then, when requesting an API (either programmatically at the time a page is loaded, say, or declaratively in a manifest/descriptor for a widget) it is possible *either* to request an implementation by ID, or solely to specify an interface, in which case it is up to the implementation to resolve that interface ID into an implementation ID. In the case that an interface is already present (eg by virtue of being implemented natively in the browser), then nothing needs to be done. JON2: I think we are in agreement here that we should use URIs for each API module, such as "http://openajax.org/apis/location", and for each implementation, such as "http://aplixcorp.com/javabridge" (or whatever). Lots of details to work out here, but we can wait until we start implementation efforts to work out the details. (2) Your document has a section on application deployment models. During last week's teleconference, we endorsed Nikunj's application deployment breakdown found at: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements#Support_for_multiple_Application_deployment_models Until Nikunj cleans up that wiki page, we agreed to Nikunj's 4 categories in blue: browser-based, widgets, native apps with web controls, and then the 4th category will be called (if I remember correctly) "Hybrid browser applications". Is Nikunj's breakdown OK with you? If so, then we need to merge your categorization in this document with Nikunj's categorization . Yes, there should be a common breakdown. I'm happy with Nikunj's breakdown, but I'm not sure we have a good enough definition yet of each of them. JON2: Agreed, but I think we don't need better words before deciding on what OpenAjax Alliance should do. In my mind, the key things are the use cases (which are far further along than I had hoped), the security discussion (same thing), and our need to decide which requirements have the highest priority (which we haven't discussed yet). (3) I have a clarification question for "Support for trusted systems": From the wiki page: JON: I was somewhat confused about the intended meaning here. I assume that trusted subsystems should be able to make calls to platform APIs, but the implication is that somehow or other the trusted subsystem won't allow an application to bypass security by invoking the trusted subsystem's APIs which then indirectly invoke the platform APIs. Yes, trusted subsystems use platform API functionality in order to implement their own scriptable API, and can be relied upon to ensure that such "indirect" invocation of the platform APIs does not expose platform functionality that was not intended. JON2: Thanks. (4) Under "Action", are some words missing? (See red-colored notes on the wiki page) Yes :) I think this is a markdown -> mediawiki transcoding error. Actions are uniquely identified by the combination of: - a scheme identifier; - an action identifier; written as : So, for example a particular scheme might be used to define a series of actions corresponding to platform API calls, and another scheme might be used to define actions relating to scriptable API calls. In WebVM, where the platform APIs correspond to (already defined) Java platform API calls, we use the scheme midp: and action identifers based on Java's own permission names. In this case, a fully qualified action identifier might be: midp:javax.microedition.location.Location Different platforms might have their own naming scheme for platform APIs and/or permissions. We might also define and ooa: scheme, and a series of specific actions within that scheme, together with a mapping to equivalent actions in other schemes. JON2: Interesting suggestion. My initial reaction is positive. (5) Under "Bind", maybe I'm missing something, but I'm not sure that we need to force all implementations into a binding process. From the wiki page: JON: I don't think we should require a binding process via a binding action. I would expect that in most situations the platform takes care of linking an implementation to a scriptable API under the hood, and from the perspective of an application, all that it knows is that the given scriptable API is supported. Even if an implementation doesn't need to perform a binding operation in order to establish the existence of an API, or bind the content to that API, I think there is still an action, subject to security checking, at which the content is granted the right to use that API. For installable widgets, this security checking might effectively take place at the time the widget is installed, or at any time prior to any of the APIs in question being called. For a web page, there might be a check, circa load-time, that the originating site is authorised to use specific APIs rather than at the specific time of an API being called. For implementations that might be required to perform some specific action to ensure the availability of any API (eg download and install a library), the bind event can serve this additional purpose, but I think a notional bind action has relevance beyond that. JON2: My thinking today is that we need to support two different workflows: "bind-then-call", and also just "call". What I mean by "call" is that user JavaScript should be able to simply call the location APIs or the PIM APIs without any setup other than inserting a SCRIPT tag that loads the OpenAjax JavaScript shim layer, and the API either succeeds or fails. This is the way that the Web Runtime works today; eg, you don't have to bind to XMLHttpRequest before using it. But definitely there will be scenarios that will require some sort of formal initialization process (bind-then-call) where the user JavaScript has to first invoke a setup method before it can invoke the APIs. Thanks - 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/20080501/ba334969/attachment-0001.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/20080501/ba334969/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic21959.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080501/ba334969/attachment-0004.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/20080501/ba334969/attachment-0005.gif From paddy.byers at gmail.com Thu May 1 07:51:41 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 1 May 2008 15:51:41 +0100 Subject: [OpenAjaxMobile] Some questions to Paddy about his security paper In-Reply-To: References: <59db1b5a0805010600g266102e2u8d39b773c836d45@mail.gmail.com> Message-ID: <59db1b5a0805010751h69021098p2c94ada95d3bcab1@mail.gmail.com> Hi, JON2: My thinking today is that we need to support two different workflows: > "bind-then-call", and also just "call". What I mean by "call" is that user > JavaScript should be able to simply call the location APIs or the PIM APIs > without any setup other than inserting a SCRIPT tag that loads the OpenAjax > JavaScript shim layer, and the API either succeeds or fails. This is the way > that the Web Runtime works today; eg, you don't have to bind to > XMLHttpRequest before using it. But definitely there will be scenarios that > will require some sort of formal initialization process (bind-then-call) > where the user JavaScript has to first invoke a setup method before it can > invoke the APIs. > OK; I take the point about XHR, but the hard-coded nature of the security policy surrounding the use of XHR is itself a problem. The other analogy with existing practice, however, is in the IE controls over use of ActiveX, which are meta-level permissions rather than permissions controlling individual APIs. If I know that a bind event, with parameters that indicate which API is being bound, is presented to the security manager, then I can write policies that say things like: - any site can use APIs it has defined itself without having to prompt the user; - site X can use any device API it likes, provided it prompts the user first; - site Y cannot use any device API, even APIs that I don't know about yet. It would be nice if we could rely on such policies being possible even on implementations that don't have to go through any other enabling mechanism to make APIs available in a given scope. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080501/e7b99d8f/attachment.html From jferrai at us.ibm.com Thu May 1 10:36:47 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 1 May 2008 10:36:47 -0700 Subject: [OpenAjaxMobile] Minutes 2008-05-01 Message-ID: Thanks to Paddy for taking minutes today. Mobile Minutes 2008-05-01 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-05-01 Attendees David Pollington, Vodafone Guillermo Caudevilla, Vodafone Jon Ferraiolo, IBM Paddy Byers, Aplix Nikunj Mehta, Oracle John Hardi, Motricity Krishna Shankar, Cisco Minutes Welcome to Motricity Jon: Welcome to John Hardi and Motricity. Can you tell us about Motricity? John: We do portals for US operators. We want to see JavaScript and APIs and want to see portals with widgets available to a broader audience. Jon: Others at OpenAjax share this objective. There is widget work happening in other committees. IBM demonstrated some OpenAjax work in this area on an iPhone at AJAXWorld in March. To Do page http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo Nikunj did good work on the TODO list 2 sections open actions, closed actions closed actions: can see lots has happened in the last week. go through J2ME table, sync with requirements page. survey page, ensure no requirements missed make sure deployment models consistent added section to requirements page: APIs that are not required, avoid repetition elsewhere security page: scheduled a joint phone call open actions remaining: use cases work still needing to be done: Nikunj volunteered to make contribution on APIs needed by the non-Vodafone use cases some requirements don't have associated use cases. Maybe OK, but should take a look and see if use cases shoudl be created for these. Nikunj volunteered. need mapping from use cases to requirements? Not really important now, easier to create and maintain once the usecases and APIs are more stable. Feature strings issue Jon: related to separate thread between Padd/John. W3C has asked OOA for help in identifying ways of identifying certain device capabilities: relates to the use of a URI for identifying an API. Nikunj: relates to loading/introspection. Would be useful if made part of a common scheme. Yahoo and Google use a namespacing approach within their loaders. Jon: was thinking that too. Any objections? (No) In the hub: had a loader where hub itself was modularised, with unique strings that identify modules. But this feature was dropped. In the hub, use dot syntax for topic names. when a library is registered, the hub publishes the event OpenAjax.hub.registerLibrary In the openajax registry, we use dot notation to identify JS globals Exact syntax for how we do it is beyond the scope of this call: but here we should discuss the general notion of identifying strings for capabilities, plus intrspection. Nikunj: want to add to requirements. Jon: there are scenarios where you might not have to load before you call. In some workflows you just call, et with Http Request. So we need to support both "bind-then-call" and just "call". Nikunj: it depends on the deployment model. Jon: we dont know yet how our stuff will be set up. It is possible that by referencing the script, using the script tage, there might be no explicit need to programmatically load. Paddy: bind event has relevance to the security policy, as well as just being part of an enabling mechanism for binding, eg in the case where plugins need to be loaded. (Nikunj volunteers to update the requirements page to reflect need to support both "bind-then-call" and "call" plus mention the security relevance. Jon: I will do the merge of the security pages today. Jon: only thing left is the objectives section. But before that, lets look at the requirements page and the section at the bottom. Requirements page http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Non-requirements section Paddy: not all of the JSR135 is out of scope, eg camera access (still picture pcature, for example). Nikunj: should tidy up via Wiki. Will volunteer to tidy up, organise a little, and add some detail in some areas. Title - non-requirements - is misleading. Perhaps just "beyond immediate scope". Should expand to say why beond immediate scope. Other red comments need tidying. People agreed that it is good to include explanatory text with items to explain why we think the given item is beyond immediate scope. (Some items already have this.) Discuss other outstanding actions Support for multi-origin models: is confusing and difficult to express as presented here. Any objections to remove it? No. Nikunj: recently, Microsoft published a paper about secure communications for mashups. This is more relevant to the existing OOA work on secure mashups than it is to mobile security work. Extensibility:remove requirements (1) and (4), and turn these into objectives. Items (2) and (3) belong to the "introspection" section. Standardised loader: need to add the requirements we've agree today - eg support for the dual models of bin-then-call and just-call. Also, security aspects of the bind event needs to be mentioned here as discussed earlier. Device service API requirements existing blue text can be moved to survey page in relating to OMA. Objectives page http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives Should separate out "objectives" and "principles". Any objections? No. Detailed comments: Nikiunj: proposed revised set of princuples and objectives to address Jon's comments. Now propose this second version rather than the version presently on the wiki. What about interoperability as an objective? Emphasis in new proposed wording is just cost reduction. Why not all of the other aspects of interoperability? Jon: think it deserves an item for itself, probably in the objectives. What are objectives and what are principles? objectives relate to why; principles embody decisions made as to how. What about javascript -friendly? Not mentioned anywhere right now in the principles. We should add this. Next steps Jon: almost finished, all TODOs assigned, which is great. Next week we can discuss what we want to do next - and declare victory on our requirements/use cases phase. Need to decide how to publicise our progress: perhaps just blog entry but can discuss next week. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080501/3f2af858/attachment.html From jferrai at us.ibm.com Fri May 2 10:13:23 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 2 May 2008 10:13:23 -0700 Subject: [OpenAjaxMobile] A couple of additions to the objectives page Message-ID: One of my actions was to review the 10April phone call (http://openajax.org/pipermail/mobile/2008q2/000192.html) to make sure that the discussion from that phone call was captured on the wiki. (The reason why that phone is special is that I had already reviewed all of the other phone calls previously.) I have now completed the review of the minutes from 10April, and as a result I added the following two things to the principles section: * A new bullet titled "Balance scope against usability and time-to-market", which captures the notion that we want to prioritize the 80/20 case and not try to solve all of the worlds problems with our initial efforts * I added some words at the end of the "JavaScript-friendly" bullet to make sure we captured the notion that we want to architect our technologies in a manner that easily allows JavaScript programmers to create custom APIs on top of our APIs Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080502/eba9277f/attachment.html From jferrai at us.ibm.com Mon May 5 08:33:39 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 5 May 2008 08:33:39 -0700 Subject: [OpenAjaxMobile] REMINDER: Special joint session on May 6 on Mobile Device APIs and security Message-ID: Just a reminder - we will have a phone call tomorrow. We have merged the two wiki pages into one. For tomorrow's call, we will focus on this wiki page: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Thanks. Jon ----------------- Hello Mobile TF and Security TF, We will be holding a special coordination phone call between the Mobile TF and Security TF on Tuesday, May 6, to have some kickoff discussions about the security issues associated with Mobile Device APIs and what initiatives make sense in this area for OpenAjax Alliance. This first phone call should be considered largely informal and mainly about information exchange. I did some checking with some people involved in the discussion, and I expect attendance at least from Larry Koved (chair of Security TF), probably a few other IBM web security experts, David Pollington of Vodafone and Paddy Byers of Aplix. (Paddy has contributed a document around security issues, so it is important that he can attend.) The larger context of this phone call is as follows. Last September, the industry held a Workshop on Mobile Ajax (co-hosted by W3C and OpenAjax Alliance) where about 50 companies came together to speculate about the future of Mobile Ajax and determine what industry-wide initiatives were needed. There was a strong consensus that in order to enable the next-generation of mobile innovation the industry needed to find a way to allow the mobile Web Runtime (i.e., HTML+JavaScript) to have the ability to make JavaScript calls to device services such as current location, PIM, phone dialer, camera, SMS, MMS, and things like that. However, there are obvious security implications when mixing the Web with device-resident services. Then in March at Mobile World Congress at Barcelona, a subset of companies (~20) met at a meeting hosted by Vodafone to decide on next steps, and a number of those companies decided to pursue a fast-track exploratory initiative at OpenAjax Alliance in the months of March and April (2008) to characterize use cases, requirements and security considerations in order to get a feel for the landscape, with the idea that in May 2008 the Mobile TF can make an informed recommendation to the members of OpenAjax Alliance about future formal activities (e.g., charter a working group. launch an open source initiative, write a spec, etc.). The exploratory phase has produced an impressive amount of contribution from the participants. Here are some of the other relevant wiki pages for the Mobile Device APIs effort: Main page: http://www.openajax.org/member/wiki/Mobile_Device_APIs Use cases: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases Requirements: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Due diligence: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey The two main wiki pages that pertain to security issues around Mobile Device APIs are: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security * http://www.openajax.org/member/wiki/Paddy_Architecture_and_Security_Proposal (We hope to consolidate the above two wiki pages into a single wiki page before the phone call.) Incidentally, just to give an idea where this all might be headed, my personal thinking right now as we come to the end of the exploratory phase (which hasn't been discussed formally, let alone approved) is that OpenAjax Alliance should do two things: (1) Author an extensive white paper that characterize security concerns around Mobile Device APIs and offer conceptual models and suggestions for how mobile devices might address these concerns, (2) Launch an open source project for a JavaScript shim layer that provides Ajax developers with a write-once, run-anywhere APIs to device services, where the shim layer maps the OpenAjax APIs to platform-specific APIs. Below is the call-in information for the phone call. Jon --------- Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris 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/20080505/dcf08409/attachment.html From Andrew.Sledd at ikivo.com Mon May 5 22:43:06 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Tue, 6 May 2008 07:43:06 +0200 Subject: [OpenAjaxMobile] Probable regretts RE: REMINDER: Special joint session on May 6 on MobileDevice APIs and security In-Reply-To: Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDCC4522@SESTHSRV10.zoomon.local> Sorry but I'm probably not able to attend this special meeting. Andy ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 5 maj 2008 17:34 To: mobile at openajax.org; security at openajax.org Subject: [OpenAjaxMobile] REMINDER: Special joint session on May 6 on MobileDevice APIs and security Just a reminder - we will have a phone call tomorrow. We have merged the two wiki pages into one. For tomorrow's call, we will focus on this wiki page: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Thanks. Jon ----------------- Hello Mobile TF and Security TF, We will be holding a special coordination phone call between the Mobile TF and Security TF on Tuesday, May 6, to have some kickoff discussions about the security issues associated with Mobile Device APIs and what initiatives make sense in this area for OpenAjax Alliance. This first phone call should be considered largely informal and mainly about information exchange. I did some checking with some people involved in the discussion, and I expect attendance at least from Larry Koved (chair of Security TF), probably a few other IBM web security experts, David Pollington of Vodafone and Paddy Byers of Aplix. (Paddy has contributed a document around security issues, so it is important that he can attend.) The larger context of this phone call is as follows. Last September, the industry held a Workshop on Mobile Ajax (co-hosted by W3C and OpenAjax Alliance) where about 50 companies came together to speculate about the future of Mobile Ajax and determine what industry-wide initiatives were needed. There was a strong consensus that in order to enable the next-generation of mobile innovation the industry needed to find a way to allow the mobile Web Runtime (i.e., HTML+JavaScript) to have the ability to make JavaScript calls to device services such as current location, PIM, phone dialer, camera, SMS, MMS, and things like that. However, there are obvious security implications when mixing the Web with device-resident services. Then in March at Mobile World Congress at Barcelona, a subset of companies (~20) met at a meeting hosted by Vodafone to decide on next steps, and a number of those companies decided to pursue a fast-track exploratory initiative at OpenAjax Alliance in the months of March and April (2008) to characterize use cases, requirements and security considerations in order to get a feel for the landscape, with the idea that in May 2008 the Mobile TF can make an informed recommendation to the members of OpenAjax Alliance about future formal activities (e.g., charter a working group. launch an open source initiative, write a spec, etc.). The exploratory phase has produced an impressive amount of contribution from the participants. Here are some of the other relevant wiki pages for the Mobile Device APIs effort: Main page: http://www.openajax.org/member/wiki/Mobile_Device_APIs Use cases: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases Requirements: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements Due diligence: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey The two main wiki pages that pertain to security issues around Mobile Device APIs are: * http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security * http://www.openajax.org/member/wiki/Paddy_Architecture_and_Security_Prop osal (We hope to consolidate the above two wiki pages into a single wiki page before the phone call.) Incidentally, just to give an idea where this all might be headed, my personal thinking right now as we come to the end of the exploratory phase (which hasn't been discussed formally, let alone approved) is that OpenAjax Alliance should do two things: (1) Author an extensive white paper that characterize security concerns around Mobile Device APIs and offer conceptual models and suggestions for how mobile devices might address these concerns, (2) Launch an open source project for a JavaScript shim layer that provides Ajax developers with a write-once, run-anywhere APIs to device services, where the shim layer maps the OpenAjax APIs to platform-specific APIs. Below is the call-in information for the phone call. Jon --------- Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris 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/20080506/6fd6eac4/attachment.html From jferrai at us.ibm.com Tue May 6 14:33:47 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 6 May 2008 14:33:47 -0700 Subject: [OpenAjaxMobile] Minutes special phone call 2008-05-06 between Mobile TF and Security TF Message-ID: Mobile Minutes 2008-05-06 URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 Attendees Larry Koved, IBM (Security TF) Suresh Chari, IBM (Security TF) Paddy Byers, Aplix (Mobile TF) Nikunj Mehta, Oracle (Mobile TF) Guillermo Caudevilla, Vodafone (Mobile TF) Caroline??, Vodadone (Mobile TF) David Pollington, Vodafone (Mobile TF) Jon Ferraiolo, IBM (Security TF & Mobile TF) Agenda Feedback from Security TF on work so far within Mobile TF on a conceptual framework for mobile device API security http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Minutes (Jon provides background on the phone call, how the industry decided that there needed to be a community effort around JavaScript APIs to mobile device services, and that dealing with security is considered critical.) (Jon quickly summarizes use cases, with four deployment models, web, widgets, native apps loading a WebRuntime DLL, and a site specific browser.) (Jon describes the thinking by the current thinking behind the security wiki page where we attempt to provide a conceptual framework and some guidelines for particular cases, but leave the final decisions to the vendors, and count on the market to drive the vendors towards good solutions.) Caroline: Is there a risk that if we don't define quite a few guidelines, then the industry might drift towards insecure approaches? Jon: Yes, there is a risk that vendors might adopt insecure approaches, and also an interoperability risk if vendors choose different approaches, which might confuse developers and users. Nikunj: Our thinking is that besides a conceptual framework, we also provide recommendations. Jon: Yes, but I'm not sure if I would say "recommendation" yet. We have to get further along to see how confident we are about what we are proposing. Maybe some things will be recommendations, and maybe others will be suggestions for consideration. But, yes, we want to identify the most common scenarios and the associated issues and make recommendations or suggestions for them. Paddy: Aplix is creating a plugin that enables runtime APIs to Java. We have a permissions framework. Our aspiration for this work is sharing the permissions framework with other similar products. Imagine a JavaScript API to a certain function. There could be multiple underlying implementations of that API, not just ours. We want common APIs and a common security policy approach. The JavaScript says here are the things I require. We need a common approach for security policies that governs the use of those APIs. Larry: I generally agree with that perspective. We don't want unexpected results on different platforms. Jon: I am hearing that we want to have a common policy framework but OK if different products implement different security policies within that common framework. Paddy: We use Java API permissions but another implementation might model after a different permission engine. Better to have a common way to express the APIs. Jon: Makes sense to me. Jon: Let's talk about one thing in particular. Paddy has proposed a feature string corresponding to each API, some sort of unique ID, and the ability to ask the system if you have permission to use that API. Paddy: The permission check wouldn't happen at the user JavaScript level. Larry: What is the programming model? What are the types of security???? to enforce? What are the constraints on those functions? For example, getcurrentlocation(). Do we want to do something like Java where there is a call to a Java-like security manager? Versus the OpenAjax Hub which is more of a message passing paradigm. Suresh: I think Paddy's right. You need a standard way of asking for the feature you want to access. Is that correct, Paddy? Paddy: We have been talking about deployment models, both for installed widgets and web site. Have a security manager or access control. Uniformly intercepts all security-relevant actions. Making a decision based on the identities of the things making the action. URL for a web site or a widget identified via distinguished name. Then what action is attempted, and particular circumstances passed as parameters. The Security manager intercepts. Doesn't live in JavaScript land. Lives in the browser or a plugin, something that is protected. Larry: OK, sounds very familiar. Java security works like this. Applet has a certain set of requirements. JAZ. But you need other attributes for mobile workflows. In the regulated space, in Switzerland, for example, some transactions are OK in Switzerland but not outside of Switzerland. So the location attribute can be important. Larry: Let me tell you my concerns from a pragmatic perspective. I've done Java security for 12 years. It functions correctly, but has a couple of deficiencies. Operationally, however, what I have observed is that people can't figure out how to do security policies. I've a tool for Java security, Sord (?) for Java. What I have found is that people have trouble with Java's stack-based security policy. I like your apporach but the challenge will be to keep it simple enough while still enforcing what the intent is. My personal opinion is that we need something similar but simpler than Java that covers base requirements. Paddy: Because of JavaScript, you can't make distinctions between call stacks if everything is in the same frame. So, we wouldn't have the full generality of JavaScript stack introspection. But we do want the notion of a trusted subsystem. I know this is possible in case of a Java bridge. The trusted subsystem is trusted to not expose the full set of APIs to its clients. We want to capture this in some sort of general way. Larry: Does everyone here understand how Java security works? Jon: I don't. (Larry promises to send info) Larry: Java looks at all of the code in the runtime stack and checks the authorization of each caller in the stack. If anyone is not authorized, then there is an error. Problem is that developers can't figure out what's in the calling stack. Shortcut with doPrivelege. There are books. Question is whether we can adopt these basic concepts. Get desired properties but not as much complexity. Java is probably the closest thing that exist to what we need. Paddy: Regarding the difficulties in writing policy, is it just something that is intrinsically difficult? Larry: Sun took one approach. I had proposed another, which is in Sord (?). Code analysis tools can't really be used with JavaScript because of eval(). Need a simpler approach that leverages domains or signatures. Larry: Coming to the end of the call. Next steps? Jon: Larry needs to send links to info on Java security. Jon: Next question is whether the security white paper or whatever should be driven by Mobile TF, with collaboration from Security TF, or the other way. (Conclusion: drive from Mobile TF due to close coupling with API effort and expected higher participation level from Mobile TF) Caroline: OMTP is doing something similar. Should we try to align the two efforts? Jon: I would guess yes, but I don't know what OMTP is doing because they are trying to agree to allow information to be shared outside of OMTP. I am scheduled to talk to Nick Alcott on May 23. Caroline: Yes, we (OMTP) are trying to get agreement to release some things to the public. (Jon/Caroline agree to have a phone call next week Thursday or Friday to coordinate on OMTP) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080506/10e08ac9/attachment.html From weingram at tibco.com Tue May 6 16:51:30 2008 From: weingram at tibco.com (Howard Weingram) Date: Tue, 6 May 2008 16:51:30 -0700 Subject: [OpenAjaxMobile] FW: [OpenAjaxSecurity] Minutes special phone call 2008-05-06 betweenMobile TF and Security TF Message-ID: Does the following roughly summarize the situation (this is partly a recap and partly additional commentary)? 1. A device can expose named features. These are exposed to JavaScript in the mobile browser as APIs. 2. A device must be able to control which scripts can be trusted to access these features by using these APIs. By default, no permissions are granted (a "white list"). 3. The environment (browser, OS, etc.) must enforce the access permissions; JavaScript running in a mobile browser cannot police itself. JavaScript running in a gadget outside of the browser cannot police itself. 4. Access policies for the browser could be expressed in terms of the domain from which JavaScript (or a gadget) is obtained. A benefit of this is that, much as I like JavaScript, this approach is not JavaScript specific. Other types of downloadable runtime components can be likewise controlled. Domains are already the main unit of access control for web browsers, so they already play a huge role in OpenAjax proposals related to security (sandboxes in OpenAjax Hub). 5. For gadgets outside of the browser, you could adopt this same approach (or just let the device treat these gadgets as applications and rely on the device to deal with access on an application by application basis). 6. When a script wants to access a feature, the device must requiest that the user explicitly grant the domain permission to access the feature. Script on web pages or gadgets from that domain can then access that feature. 7. A user must be able to revoke a granted privilege. 8. If multiple frames F1 and F2 are present and are associated with domains D1 and D2, then the fact that script from domain D1 is permitted to access a given feature does not imply that F2 can access it. 9. Special policies (e.g. can't access some features in Switzerland) would need to be understood and enforced by the device environment, not by the JavaScript. As such, while it may be useful for some JavaScript to find out from the environment what normally-accessible features are disabled at a given moment, the JavaScript won't be responsible for enforcing that disablement. General comment: The more complex the permissioning mechanism, the less likely it is that it will ever be implemented in devices. History is littered with standards (in the security sphere, in particular) that were never implemented fully because they drowned in complexity. Anything we propose must be as minimal and focused as possible, with concepts that are as simple, concrete and familiar as we can make them. Question: Were these "features" the same that I discussed with you, Jon, in the context of gadgets (i.e., a feature is a named interface specification, no more and no less) or is this a separate use of the term "feature?" hw ________________________________ From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Tuesday, May 06, 2008 2:34 PM To: mobile at openajax.org; security at openajax.org Subject: [OpenAjaxSecurity] Minutes special phone call 2008-05-06 betweenMobile TF and Security TF Mobile Minutes 2008-05-06 URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 Attendees Larry Koved, IBM (Security TF) Suresh Chari, IBM (Security TF) Paddy Byers, Aplix (Mobile TF) Nikunj Mehta, Oracle (Mobile TF) Guillermo Caudevilla, Vodafone (Mobile TF) Caroline ?, Vodadone (Mobile TF) David Pollington, Vodafone (Mobile TF) Jon Ferraiolo, IBM (Security TF & Mobile TF) Agenda Feedback from Security TF on work so far within Mobile TF on a conceptual framework for mobile device API security http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Minutes (Jon provides background on the phone call, how the industry decided that there needed to be a community effort around JavaScript APIs to mobile device services, and that dealing with security is considered critical.) (Jon quickly summarizes use cases, with four deployment models, web, widgets, native apps loading a WebRuntime DLL, and a site specific browser.) (Jon describes the thinking by the current thinking behind the security wiki page where we attempt to provide a conceptual framework and some guidelines for particular cases, but leave the final decisions to the vendors, and count on the market to drive the vendors towards good solutions.) Caroline: Is there a risk that if we don't define quite a few guidelines, then the industry might drift towards insecure approaches? Jon: Yes, there is a risk that vendors might adopt insecure approaches, and also an interoperability risk if vendors choose different approaches, which might confuse developers and users. Nikunj: Our thinking is that besides a conceptual framework, we also provide recommendations. Jon: Yes, but I'm not sure if I would say "recommendation" yet. We have to get further along to see how confident we are about what we are proposing. Maybe some things will be recommendations, and maybe others will be suggestions for consideration. But, yes, we want to identify the most common scenarios and the associated issues and make recommendations or suggestions for them. Paddy: Aplix is creating a plugin that enables runtime APIs to Java. We have a permissions framework. Our aspiration for this work is sharing the permissions framework with other similar products. Imagine a JavaScript API to a certain function. There could be multiple underlying implementations of that API, not just ours. We want common APIs and a common security policy approach. The JavaScript says here are the things I require. We need a common approach for security policies that governs the use of those APIs. Larry: I generally agree with that perspective. We don't want unexpected results on different platforms. Jon: I am hearing that we want to have a common policy framework but OK if different products implement different security policies within that common framework. Paddy: We use Java API permissions but another implementation might model after a different permission engine. Better to have a common way to express the APIs. Jon: Makes sense to me. Jon: Let's talk about one thing in particular. Paddy has proposed a feature string corresponding to each API, some sort of unique ID, and the ability to ask the system if you have permission to use that API. Paddy: The permission check wouldn't happen at the user JavaScript level. Larry: What is the programming model? What are the types of security ??? to enforce? What are the constraints on those functions? For example, getcurrentlocation(). Do we want to do something like Java where there is a call to a Java-like security manager? Versus the OpenAjax Hub which is more of a message passing paradigm. Suresh: I think Paddy's right. You need a standard way of asking for the feature you want to access. Is that correct, Paddy? Paddy: We have been talking about deployment models, both for installed widgets and web site. Have a security manager or access control. Uniformly intercepts all security-relevant actions. Making a decision based on the identities of the things making the action. URL for a web site or a widget identified via distinguished name. Then what action is attempted, and particular circumstances passed as parameters. The Security manager intercepts. Doesn't live in JavaScript land. Lives in the browser or a plugin, something that is protected. Larry: OK, sounds very familiar. Java security works like this. Applet has a certain set of requirements. JAZ. But you need other attributes for mobile workflows. In the regulated space, in Switzerland, for example, some transactions are OK in Switzerland but not outside of Switzerland. So the location attribute can be important. Larry: Let me tell you my concerns from a pragmatic perspective. I've done Java security for 12 years. It functions correctly, but has a couple of deficiencies. Operationally, however, what I have observed is that people can't figure out how to do security policies. I've a tool for Java security, Sord (?) for Java. What I have found is that people have trouble with Java's stack-based security policy. I like your apporach but the challenge will be to keep it simple enough while still enforcing what the intent is. My personal opinion is that we need something similar but simpler than Java that covers base requirements. Paddy: Because of JavaScript, you can't make distinctions between call stacks if everything is in the same frame. So, we wouldn't have the full generality of JavaScript stack introspection. But we do want the notion of a trusted subsystem. I know this is possible in case of a Java bridge. The trusted subsystem is trusted to not expose the full set of APIs to its clients. We want to capture this in some sort of general way. Larry: Does everyone here understand how Java security works? Jon: I don't. (Larry promises to send info) Larry: Java looks at all of the code in the runtime stack and checks the authorization of each caller in the stack. If anyone is not authorized, then there is an error. Problem is that developers can't figure out what's in the calling stack. Shortcut with doPrivelege. There are books. Question is whether we can adopt these basic concepts. Get desired properties but not as much complexity. Java is probably the closest thing that exist to what we need. Paddy: Regarding the difficulties in writing policy, is it just something that is intrinsically difficult? Larry: Sun took one approach. I had proposed another, which is in Sord (?). Code analysis tools can't really be used with JavaScript because of eval(). Need a simpler approach that leverages domains or signatures. Larry: Coming to the end of the call. Next steps? Jon: Larry needs to send links to info on Java security. Jon: Next question is whether the security white paper or whatever should be driven by Mobile TF, with collaboration from Security TF, or the other way. (Conclusion: drive from Mobile TF due to close coupling with API effort and expected higher participation level from Mobile TF) Caroline: OMTP is doing something similar. Should we try to align the two efforts? Jon: I would guess yes, but I don't know what OMTP is doing because they are trying to agree to allow information to be shared outside of OMTP. I am scheduled to talk to Nick Alcott on May 23. Caroline: Yes, we (OMTP) are trying to get agreement to release some things to the public. (Jon/Caroline agree to have a phone call next week Thursday or Friday to coordinate on OMTP) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080506/36977521/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT28906675.txt Url: http://openajax.org/pipermail/mobile/attachments/20080506/36977521/attachment-0001.txt From koved at us.ibm.com Tue May 6 18:08:05 2008 From: koved at us.ibm.com (Larry Koved) Date: Tue, 6 May 2008 21:08:05 -0400 Subject: [OpenAjaxMobile] [OpenAjaxSecurity] Minutes special phone call 2008-05-06 between Mobile TF and Security TF In-Reply-To: Message-ID: I've updated the wiki to point to sample references materials on Java security. Jon Ferraiolo/Menlo Park/IBM at IBMUS Sent by: security-bounces at openajax.org 05/06/2008 05:33 PM Please respond to OpenAjax Alliance Security Task Force To mobile at openajax.org, security at openajax.org cc Subject [OpenAjaxSecurity] Minutes special phone call 2008-05-06 between Mobile TF and Security TF Mobile Minutes 2008-05-06 URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 Attendees Larry Koved, IBM (Security TF) Suresh Chari, IBM (Security TF) Paddy Byers, Aplix (Mobile TF) Nikunj Mehta, Oracle (Mobile TF) Guillermo Caudevilla, Vodafone (Mobile TF) Caroline ?, Vodadone (Mobile TF) David Pollington, Vodafone (Mobile TF) Jon Ferraiolo, IBM (Security TF & Mobile TF) Agenda Feedback from Security TF on work so far within Mobile TF on a conceptual framework for mobile device API security http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Minutes (Jon provides background on the phone call, how the industry decided that there needed to be a community effort around JavaScript APIs to mobile device services, and that dealing with security is considered critical.) (Jon quickly summarizes use cases, with four deployment models, web, widgets, native apps loading a WebRuntime DLL, and a site specific browser.) (Jon describes the thinking by the current thinking behind the security wiki page where we attempt to provide a conceptual framework and some guidelines for particular cases, but leave the final decisions to the vendors, and count on the market to drive the vendors towards good solutions.) Caroline: Is there a risk that if we don't define quite a few guidelines, then the industry might drift towards insecure approaches? Jon: Yes, there is a risk that vendors might adopt insecure approaches, and also an interoperability risk if vendors choose different approaches, which might confuse developers and users. Nikunj: Our thinking is that besides a conceptual framework, we also provide recommendations. Jon: Yes, but I'm not sure if I would say "recommendation" yet. We have to get further along to see how confident we are about what we are proposing. Maybe some things will be recommendations, and maybe others will be suggestions for consideration. But, yes, we want to identify the most common scenarios and the associated issues and make recommendations or suggestions for them. Paddy: Aplix is creating a plugin that enables runtime APIs to Java. We have a permissions framework. Our aspiration for this work is sharing the permissions framework with other similar products. Imagine a JavaScript API to a certain function. There could be multiple underlying implementations of that API, not just ours. We want common APIs and a common security policy approach. The JavaScript says here are the things I require. We need a common approach for security policies that governs the use of those APIs. Larry: I generally agree with that perspective. We don't want unexpected results on different platforms. Jon: I am hearing that we want to have a common policy framework but OK if different products implement different security policies within that common framework. Paddy: We use Java API permissions but another implementation might model after a different permission engine. Better to have a common way to express the APIs. Jon: Makes sense to me. Jon: Let's talk about one thing in particular. Paddy has proposed a feature string corresponding to each API, some sort of unique ID, and the ability to ask the system if you have permission to use that API. Paddy: The permission check wouldn't happen at the user JavaScript level. Larry: What is the programming model? What are the types of security ??? to enforce? What are the constraints on those functions? For example, getcurrentlocation(). Do we want to do something like Java where there is a call to a Java-like security manager? Versus the OpenAjax Hub which is more of a message passing paradigm. Suresh: I think Paddy's right. You need a standard way of asking for the feature you want to access. Is that correct, Paddy? Paddy: We have been talking about deployment models, both for installed widgets and web site. Have a security manager or access control. Uniformly intercepts all security-relevant actions. Making a decision based on the identities of the things making the action. URL for a web site or a widget identified via distinguished name. Then what action is attempted, and particular circumstances passed as parameters. The Security manager intercepts. Doesn't live in JavaScript land. Lives in the browser or a plugin, something that is protected. Larry: OK, sounds very familiar. Java security works like this. Applet has a certain set of requirements. JAZ. But you need other attributes for mobile workflows. In the regulated space, in Switzerland, for example, some transactions are OK in Switzerland but not outside of Switzerland. So the location attribute can be important. Larry: Let me tell you my concerns from a pragmatic perspective. I've done Java security for 12 years. It functions correctly, but has a couple of deficiencies. Operationally, however, what I have observed is that people can't figure out how to do security policies. I've a tool for Java security, Sord (?) for Java. What I have found is that people have trouble with Java's stack-based security policy. I like your apporach but the challenge will be to keep it simple enough while still enforcing what the intent is. My personal opinion is that we need something similar but simpler than Java that covers base requirements. Paddy: Because of JavaScript, you can't make distinctions between call stacks if everything is in the same frame. So, we wouldn't have the full generality of JavaScript stack introspection. But we do want the notion of a trusted subsystem. I know this is possible in case of a Java bridge. The trusted subsystem is trusted to not expose the full set of APIs to its clients. We want to capture this in some sort of general way. Larry: Does everyone here understand how Java security works? Jon: I don't. (Larry promises to send info) Larry: Java looks at all of the code in the runtime stack and checks the authorization of each caller in the stack. If anyone is not authorized, then there is an error. Problem is that developers can't figure out what's in the calling stack. Shortcut with doPrivelege. There are books. Question is whether we can adopt these basic concepts. Get desired properties but not as much complexity. Java is probably the closest thing that exist to what we need. Paddy: Regarding the difficulties in writing policy, is it just something that is intrinsically difficult? Larry: Sun took one approach. I had proposed another, which is in Sord (?). Code analysis tools can't really be used with JavaScript because of eval(). Need a simpler approach that leverages domains or signatures. Larry: Coming to the end of the call. Next steps? Jon: Larry needs to send links to info on Java security. Jon: Next question is whether the security white paper or whatever should be driven by Mobile TF, with collaboration from Security TF, or the other way. (Conclusion: drive from Mobile TF due to close coupling with API effort and expected higher participation level from Mobile TF) Caroline: OMTP is doing something similar. Should we try to align the two efforts? Jon: I would guess yes, but I don't know what OMTP is doing because they are trying to agree to allow information to be shared outside of OMTP. I am scheduled to talk to Nick Alcott on May 23. Caroline: Yes, we (OMTP) are trying to get agreement to release some things to the public. (Jon/Caroline agree to have a phone call next week Thursday or Friday to coordinate on OMTP)_______________________________________________ security mailing list security at openajax.org http://openajax.org/mailman/listinfo/security -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080506/be0842cf/attachment.html From koved at us.ibm.com Tue May 6 20:12:41 2008 From: koved at us.ibm.com (Larry Koved) Date: Tue, 6 May 2008 23:12:41 -0400 Subject: [OpenAjaxMobile] [OpenAjaxSecurity] FW: Minutes special phone call 2008-05-06 betweenMobile TF and Security TF In-Reply-To: Message-ID: Howard, Thanks for your summary. I think that we are in agreement. A few comments below. Thanks to Jon, who wrote up the meeting minutes. I updated the wiki to clarify a number of points, as well as add some Java security references for those people who are not familiar with Java security. Just to be clear -- we need something simpler than Java security! Larry security-bounces at openajax.org wrote on 05/06/2008 07:51:30 PM: > Does the following roughly summarize the situation > (this is partly a recap and partly additional commentary)? > > 1. A device can expose named features. These are > exposed to JavaScript in the mobile browser as APIs. > This appears to be the current proposal. (One alternative, that we did not discuss on the call, would be to use the Hub 1.1 and send messages to a service listening to messages. A security policy could be defined that would limit those domains / scripts that are allowed to communicate with these privileged services.) > 2. A device must be able to control which scripts can be > trusted to access these features by using these APIs. > By default, no permissions are granted (a "white list"). White listing would be the safest choice. Black listing is not always effective. > > 3. The environment (browser, OS, etc.) must enforce the > access permissions; JavaScript running in a mobile > browser cannot police itself. JavaScript running in a > gadget outside of the browser cannot police itself. > Yes. A best practice in security is to have a small, independent "reference monitor" implement the access control. See http://en.wikipedia.org/wiki/Reference_monitor > 4. Access policies for the browser could be expressed in > terms of the domain from which JavaScript (or a > gadget) is obtained. A benefit of this is that, much as > I like JavaScript, this approach is not JavaScript > specific. Other types of downloadable runtime > components can be likewise controlled. > > Domains are already the main unit of access control > for web browsers, so they already play a huge role in > OpenAjax proposals related to security (sandboxes in > OpenAjax Hub). > Domains are one attribute. As is done in Java, we could also consider code signing. It will depend on the capabilities of the device. > 5. For gadgets outside of the browser, you could adopt > this same approach (or just let the device treat these > gadgets as applications and rely on the device to > deal with access on an application by application basis). If the mobile task force believes that non-browser gadgets will be common (e.g., services/widgets that are bundled with the device, or downloaded by a service provider), then we should make some recommendation on how authentication / authorization for this code will be defined. > > 6. When a script wants to access a feature, the device > must requiest that the user explicitly grant the domain > permission to access the feature. > > Script on web pages or gadgets from that domain can > then access that feature. And/or security policies are pushed down by the service provider (or the device manufacturer). If we expect users to grant domain permissions, we need to make security policies really easy to understand and hard to misunderstand..... a tall order! Let's see what we can come up with!! > > 7. A user must be able to revoke a granted privilege. Agree. The user interface for this needs to be easy to use (i.e., intuitive). > > 8. If multiple frames F1 and F2 are present and are > associated with domains D1 and D2, then the fact > that script from domain D1 is permitted to access > a given feature does not imply that F2 can access it. Yes. > > 9. Special policies (e.g. can't access some features in > Switzerland) would need to be understood and > enforced by the device environment, not by the > JavaScript. As such, while it may be useful for some > JavaScript to find out from the environment what > normally-accessible features are disabled at a > given moment, the JavaScript won't be responsible > for enforcing that disablement. Agree. See my comment above about "reference monitors". > > > General comment: > > The more complex the permissioning mechanism, the > less likely it is that it will ever be implemented in > devices. History is littered with standards (in the security > sphere, in particular) that were never implemented fully > because they drowned in complexity. Anything we > propose must be as minimal and focused as possible, > with concepts that are as simple, concrete and familiar > as we can make them. > Totally agree. > > Question: > > Were these "features" the same that I discussed with you, > Jon, in the context of gadgets (i.e., a feature is a named > interface specification, no more and no less) or is this a > separate use of the term "feature?" > > hw > > From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] > On Behalf Of Jon Ferraiolo > Sent: Tuesday, May 06, 2008 2:34 PM > To: mobile at openajax.org; security at openajax.org > Subject: [OpenAjaxSecurity] Minutes special phone call 2008-05-06 > betweenMobile TF and Security TF > Mobile Minutes 2008-05-06 > > URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 > Attendees > Larry Koved, IBM (Security TF) > Suresh Chari, IBM (Security TF) > Paddy Byers, Aplix (Mobile TF) > Nikunj Mehta, Oracle (Mobile TF) > Guillermo Caudevilla, Vodafone (Mobile TF) > Caroline ?, Vodadone (Mobile TF) > David Pollington, Vodafone (Mobile TF) > Jon Ferraiolo, IBM (Security TF & Mobile TF) > > Agenda > Feedback from Security TF on work so far within Mobile TF on a > conceptual framework for mobile device API security > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security > > Minutes > (Jon provides background on the phone call, how the industry decided > that there needed to be a community effort around JavaScript APIs to > mobile device services, and that dealing with security is consideredcritical.) > (Jon quickly summarizes use cases, with four deployment models, web, > widgets, native apps loading a WebRuntime DLL, and a site specific browser.) > (Jon describes the thinking by the current thinking behind the > security wiki page where we attempt to provide a conceptual > framework and some guidelines for particular cases, but leave the > final decisions to the vendors, and count on the market to drive the > vendors towards good solutions.) > Caroline: Is there a risk that if we don't define quite a few > guidelines, then the industry might drift towards insecure approaches? > Jon: Yes, there is a risk that vendors might adopt insecure > approaches, and also an interoperability risk if vendors choose > different approaches, which might confuse developers and users. > Nikunj: Our thinking is that besides a conceptual framework, we also > provide recommendations. > Jon: Yes, but I'm not sure if I would say "recommendation" yet. We > have to get further along to see how confident we are about what we > are proposing. Maybe some things will be recommendations, and maybe > others will be suggestions for consideration. But, yes, we want to > identify the most common scenarios and the associated issues and > make recommendations or suggestions for them. > Paddy: Aplix is creating a plugin that enables runtime APIs to Java. > We have a permissions framework. Our aspiration for this work is > sharing the permissions framework with other similar products. > Imagine a JavaScript API to a certain function. There could be > multiple underlying implementations of that API, not just ours. We > want common APIs and a common security policy approach. The > JavaScript says here are the things I require. We need a common > approach for security policies that governs the use of those APIs. > Larry: I generally agree with that perspective. We don't want > unexpected results on different platforms. > Jon: I am hearing that we want to have a common policy framework but > OK if different products implement different security policies > within that common framework. > Paddy: We use Java API permissions but another implementation might > model after a different permission engine. Better to have a common > way to express the APIs. > Jon: Makes sense to me. > Jon: Let's talk about one thing in particular. Paddy has proposed a > feature string corresponding to each API, some sort of unique ID, > and the ability to ask the system if you have permission to use that API. > Paddy: The permission check wouldn't happen at the user JavaScript level. > Larry: What is the programming model? What are the types of security > ??? to enforce? What are the constraints on those functions? For > example, getcurrentlocation(). Do we want to do something like Java > where there is a call to a Java-like security manager? Versus the > OpenAjax Hub which is more of a message passing paradigm. > Suresh: I think Paddy's right. You need a standard way of asking for > the feature you want to access. Is that correct, Paddy? > Paddy: We have been talking about deployment models, both for > installed widgets and web site. Have a security manager or access > control. Uniformly intercepts all security-relevant actions. Making > a decision based on the identities of the things making the action. > URL for a web site or a widget identified via distinguished name. > Then what action is attempted, and particular circumstances passed > as parameters. The Security manager intercepts. Doesn't live in > JavaScript land. Lives in the browser or a plugin, something that isprotected. > Larry: OK, sounds very familiar. Java security works like this. > Applet has a certain set of requirements. JAZ. But you need other > attributes for mobile workflows. In the regulated space, in > Switzerland, for example, some transactions are OK in Switzerland > but not outside of Switzerland. So the location attribute can be important. > Larry: Let me tell you my concerns from a pragmatic perspective. > I've done Java security for 12 years. It functions correctly, but > has a couple of deficiencies. Operationally, however, what I have > observed is that people can't figure out how to do security > policies. I've a tool for Java security, Sord (?) for Java. What I > have found is that people have trouble with Java's stack-based > security policy. I like your apporach but the challenge will be to > keep it simple enough while still enforcing what the intent is. My > personal opinion is that we need something similar but simpler than > Java that covers base requirements. > Paddy: Because of JavaScript, you can't make distinctions between > call stacks if everything is in the same frame. So, we wouldn't have > the full generality of JavaScript stack introspection. But we do > want the notion of a trusted subsystem. I know this is possible in > case of a Java bridge. The trusted subsystem is trusted to not > expose the full set of APIs to its clients. We want to capture this > in some sort of general way. > Larry: Does everyone here understand how Java security works? > Jon: I don't. > (Larry promises to send info) > Larry: Java looks at all of the code in the runtime stack and checks > the authorization of each caller in the stack. If anyone is not > authorized, then there is an error. Problem is that developers can't > figure out what's in the calling stack. Shortcut with doPrivelege. > There are books. Question is whether we can adopt these basic > concepts. Get desired properties but not as much complexity. Java is > probably the closest thing that exist to what we need. > Paddy: Regarding the difficulties in writing policy, is it just > something that is intrinsically difficult? > Larry: Sun took one approach. I had proposed another, which is in > Sord (?). Code analysis tools can't really be used with JavaScript > because of eval(). Need a simpler approach that leverages domains or > signatures. > Larry: Coming to the end of the call. Next steps? > Jon: Larry needs to send links to info on Java security. > Jon: Next question is whether the security white paper or whatever > should be driven by Mobile TF, with collaboration from Security TF, > or the other way. > (Conclusion: drive from Mobile TF due to close coupling with API > effort and expected higher participation level from Mobile TF) > Caroline: OMTP is doing something similar. Should we try to align > the two efforts? > Jon: I would guess yes, but I don't know what OMTP is doing because > they are trying to agree to allow information to be shared outside > of OMTP. I am scheduled to talk to Nick Alcott on May 23. > Caroline: Yes, we (OMTP) are trying to get agreement to release some > things to the public. > (Jon/Caroline agree to have a phone call next week Thursday or > Friday to coordinate on OMTP)_______________________________________________ > security mailing list > security at openajax.org > http://openajax.org/mailman/listinfo/security > _______________________________________________ > security mailing list > security at openajax.org > http://openajax.org/mailman/listinfo/security -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080506/40d4c25b/attachment-0001.html From weingram at tibco.com Tue May 6 22:53:19 2008 From: weingram at tibco.com (Howard Weingram) Date: Tue, 6 May 2008 22:53:19 -0700 Subject: [OpenAjaxMobile] [OpenAjaxSecurity] FW: Minutes special phone call2008-05-06 betweenMobile TF and Security TF In-Reply-To: References: Message-ID: Hi, Larry. Thank you! Some comments below. > 1. A device can expose named features. These are > exposed to JavaScript in the mobile browser as APIs. > This appears to be the current proposal. (One alternative, that we did not discuss on the call, would be to use the Hub 1.1 and send messages to a service listening to messages. A security policy could be defined that would limit those domains / scripts that are allowed to communicate with these privileged services.) [HW] That's an interesting idea. I offer the following questions that may help when evaluating the options. (1) The Hub is designed for the asynchronous exchange of typed events. Would most native device features behave in this way? Do you expect the device to have a message bus that is analogous to the OAH? Or would use of the Hub involve enforcing asynchronous behavior on essentially synchronous, direct device APIs? (2) Do device APIs typically want to pass functions and logic around, or do they typically want to pass data around? By default, I think I would avoid using the hub for this purpose until the proposal passes a cost-benefit analysis. Thus I want to know more about the device APIs under discussion. [/HW] > 2. A device must be able to control which scripts can be > trusted to access these features by using these APIs. > By default, no permissions are granted (a "white list"). White listing would be the safest choice. Black listing is not always effective. > 3. The environment (browser, OS, etc.) must enforce the > access permissions; JavaScript running in a mobile > browser cannot police itself. JavaScript running in a > gadget outside of the browser cannot police itself. > Yes. A best practice in security is to have a small, independent "reference monitor" implement the access control. See http://en.wikipedia.org/wiki/Reference_monitor [HW] Definitely. [/HW] > 4. Access policies for the browser could be expressed in > terms of the domain from which JavaScript (or a ... > OpenAjax proposals related to security (sandboxes in > OpenAjax Hub). > Domains are one attribute. As is done in Java, we could also consider code signing. It will depend on the capabilities of the device. [HW] Could be. Most likely for JavaScript that is part of an installed application on the mobile device rather than simply script on a web page. [/HW] > 5. For gadgets outside of the browser, you could adopt > this same approach (or just let the device treat these > gadgets as applications and rely on the device to > deal with access on an application by application basis). If the mobile task force believes that non-browser gadgets will be common (e.g., services/widgets that are bundled with the device, or downloaded by a service provider), then we should make some recommendation on how authentication / authorization for this code will be defined. [HW] If supported, they'll likely be common. Supporting non-browser or private-browser-instance JS widgets would be the fastest way to onboard a massive number of skilled developers (from the www) to start building things for a phone platform. [/HW] > 6. When a script wants to access a feature, the device > must requiest that the user explicitly grant the domain > permission to access the feature. > > Script on web pages or gadgets from that domain can > then access that feature. And/or security policies are pushed down by the service provider (or the device manufacturer). If we expect users to grant domain permissions, we need to make security policies really easy to understand and hard to misunderstand..... a tall order! Let's see what we can come up with!! [HW] 100% agree! [/HW] > 7. A user must be able to revoke a granted privilege. Agree. The user interface for this needs to be easy to use (i.e., intuitive). [HW] Agreed [/HW] > 8. If multiple frames F1 and F2 are present and are > associated with domains D1 and D2, then the fact > that script from domain D1 is permitted to access > a given feature does not imply that F2 can access it. Yes. > > 9. Special policies (e.g. can't access some features in > Switzerland) would need to be understood and > enforced by the device environment, not by the > JavaScript. As such, while it may be useful for some > JavaScript to find out from the environment what > normally-accessible features are disabled at a > given moment, the JavaScript won't be responsible > for enforcing that disablement. Agree. See my comment above about "reference monitors". > > > General comment: > > The more complex the permissioning mechanism, the > less likely it is that it will ever be implemented in > devices. History is littered with standards (in the security > sphere, in particular) that were never implemented fully > because they drowned in complexity. Anything we > propose must be as minimal and focused as possible, > with concepts that are as simple, concrete and familiar > as we can make them. > Totally agree. > > Question: > > Were these "features" the same that I discussed with you, > Jon, in the context of gadgets (i.e., a feature is a named > interface specification, no more and no less) or is this a > separate use of the term "feature?" [HW] Thanks again! [/HW] hw > > From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] > On Behalf Of Jon Ferraiolo > Sent: Tuesday, May 06, 2008 2:34 PM > To: mobile at openajax.org ; security at openajax.org > Subject: [OpenAjaxSecurity] Minutes special phone call 2008-05-06 > betweenMobile TF and Security TF > Mobile Minutes 2008-05-06 > > URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 > Attendees > Larry Koved, IBM (Security TF) > Suresh Chari, IBM (Security TF) > Paddy Byers, Aplix (Mobile TF) > Nikunj Mehta, Oracle (Mobile TF) > Guillermo Caudevilla, Vodafone (Mobile TF) > Caroline ?, Vodadone (Mobile TF) > David Pollington, Vodafone (Mobile TF) > Jon Ferraiolo, IBM (Security TF & Mobile TF) > > Agenda > Feedback from Security TF on work so far within Mobile TF on a > conceptual framework for mobile device API security > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security > > Minutes > (Jon provides background on the phone call, how the industry decided > that there needed to be a community effort around JavaScript APIs to > mobile device services, and that dealing with security is consideredcritical.) > (Jon quickly summarizes use cases, with four deployment models, web, > widgets, native apps loading a WebRuntime DLL, and a site specific browser.) > (Jon describes the thinking by the current thinking behind the > security wiki page where we attempt to provide a conceptual > framework and some guidelines for particular cases, but leave the > final decisions to the vendors, and count on the market to drive the > vendors towards good solutions.) > Caroline: Is there a risk that if we don't define quite a few > guidelines, then the industry might drift towards insecure approaches? > Jon: Yes, there is a risk that vendors might adopt insecure > approaches, and also an interoperability risk if vendors choose > different approaches, which might confuse developers and users. > Nikunj: Our thinking is that besides a conceptual framework, we also > provide recommendations. > Jon: Yes, but I'm not sure if I would say "recommendation" yet. We > have to get further along to see how confident we are about what we > are proposing. Maybe some things will be recommendations, and maybe > others will be suggestions for consideration. But, yes, we want to > identify the most common scenarios and the associated issues and > make recommendations or suggestions for them. > Paddy: Aplix is creating a plugin that enables runtime APIs to Java. > We have a permissions framework. Our aspiration for this work is > sharing the permissions framework with other similar products. > Imagine a JavaScript API to a certain function. There could be > multiple underlying implementations of that API, not just ours. We > want common APIs and a common security policy approach. The > JavaScript says here are the things I require. We need a common > approach for security policies that governs the use of those APIs. > Larry: I generally agree with that perspective. We don't want > unexpected results on different platforms. > Jon: I am hearing that we want to have a common policy framework but > OK if different products implement different security policies > within that common framework. > Paddy: We use Java API permissions but another implementation might > model after a different permission engine. Better to have a common > way to express the APIs. > Jon: Makes sense to me. > Jon: Let's talk about one thing in particular. Paddy has proposed a > feature string corresponding to each API, some sort of unique ID, > and the ability to ask the system if you have permission to use that API. > Paddy: The permission check wouldn't happen at the user JavaScript level. > Larry: What is the programming model? What are the types of security > ??? to enforce? What are the constraints on those functions? For > example, getcurrentlocation(). Do we want to do something like Java > where there is a call to a Java-like security manager? Versus the > OpenAjax Hub which is more of a message passing paradigm. > Suresh: I think Paddy's right. You need a standard way of asking for > the feature you want to access. Is that correct, Paddy? > Paddy: We have been talking about deployment models, both for > installed widgets and web site. Have a security manager or access > control. Uniformly intercepts all security-relevant actions. Making > a decision based on the identities of the things making the action. > URL for a web site or a widget identified via distinguished name. > Then what action is attempted, and particular circumstances passed > as parameters. The Security manager intercepts. Doesn't live in > JavaScript land. Lives in the browser or a plugin, something that isprotected. > Larry: OK, sounds very familiar. Java security works like this. > Applet has a certain set of requirements. JAZ. But you need other > attributes for mobile workflows. In the regulated space, in > Switzerland, for example, some transactions are OK in Switzerland > but not outside of Switzerland. So the location attribute can be important. > Larry: Let me tell you my concerns from a pragmatic perspective. > I've done Java security for 12 years. It functions correctly, but > has a couple of deficiencies. Operationally, however, what I have > observed is that people can't figure out how to do security > policies. I've a tool for Java security, Sord (?) for Java. What I > have found is that people have trouble with Java's stack-based > security policy. I like your apporach but the challenge will be to > keep it simple enough while still enforcing what the intent is. My > personal opinion is that we need something similar but simpler than > Java that covers base requirements. > Paddy: Because of JavaScript, you can't make distinctions between > call stacks if everything is in the same frame. So, we wouldn't have > the full generality of JavaScript stack introspection. But we do > want the notion of a trusted subsystem. I know this is possible in > case of a Java bridge. The trusted subsystem is trusted to not > expose the full set of APIs to its clients. We want to capture this > in some sort of general way. > Larry: Does everyone here understand how Java security works? > Jon: I don't. > (Larry promises to send info) > Larry: Java looks at all of the code in the runtime stack and checks > the authorization of each caller in the stack. If anyone is not > authorized, then there is an error. Problem is that developers can't > figure out what's in the calling stack. Shortcut with doPrivelege. > There are books. Question is whether we can adopt these basic > concepts. Get desired properties but not as much complexity. Java is > probably the closest thing that exist to what we need. > Paddy: Regarding the difficulties in writing policy, is it just > something that is intrinsically difficult? > Larry: Sun took one approach. I had proposed another, which is in > Sord (?). Code analysis tools can't really be used with JavaScript > because of eval(). Need a simpler approach that leverages domains or > signatures. > Larry: Coming to the end of the call. Next steps? > Jon: Larry needs to send links to info on Java security. > Jon: Next question is whether the security white paper or whatever > should be driven by Mobile TF, with collaboration from Security TF, > or the other way. > (Conclusion: drive from Mobile TF due to close coupling with API > effort and expected higher participation level from Mobile TF) > Caroline: OMTP is doing something similar. Should we try to align > the two efforts? > Jon: I would guess yes, but I don't know what OMTP is doing because > they are trying to agree to allow information to be shared outside > of OMTP. I am scheduled to talk to Nick Alcott on May 23. > Caroline: Yes, we (OMTP) are trying to get agreement to release some > things to the public. > (Jon/Caroline agree to have a phone call next week Thursday or > Friday to coordinate on OMTP)_______________________________________________ > security mailing list > security at openajax.org > http://openajax.org/mailman/listinfo/security > _______________________________________________ > security mailing list > security at openajax.org > http://openajax.org/mailman/listinfo/security -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080506/c3ee1a1d/attachment-0001.html From jferrai at us.ibm.com Wed May 7 10:36:28 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 7 May 2008 10:36:28 -0700 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) Message-ID: One of the topics that came up in the email discussion between Howard and Larry was whether it was a good idea to leverage the OpenAjax Hub for our mobile device APIs. Larry and Howard indicated that this was something to consider, and I think so, also, but my guess is that none of us has put enough thought into this in order for form a strong opinion. Therefore, I am starting an email thread to see if we can make progress on this issue. Let's put the Hub aside for a moment and ask two higher level questions: Question #1: Should our APIs be synchronous of asynchronous? For example, should it be: Synch: --- location = OpenAjax.whatever.getCurrentLocation(...) or Async: ---function MyCallBack(...) {...} ---OpenAjax.whatever.getCurrentLocation(MyCallback, ...); Note that JavaScript developers are very familiar with async programmer, in for no other reason that that's how XMLHttpRequest works. Obviously, synchronous is simpler for developers, but my thinking is that asynchronous is better because JavaScript is single-threaded, and some operations might take time for processing and therefore might block the UI from being responsive. Question #2: Should our APIs be designed around message passing? Let's assume that we agree on an async approach. Then the next question is whether each request should be packaged as a message that is published from one agent (e.g., the application) to another agent (e.g., the system)? If so, then maybe we should think about leveraging the OpenAjax Hub. My thinking is that we should *not* design our APIs around messaging passing (or the Hub), and instead use a more direct approach. Instead of sending a message that says "give me the current location", let's just call a getCurrentLocation() method. What do others think? Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080507/bff37858/attachment.html From jferrai at us.ibm.com Wed May 7 10:21:09 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 7 May 2008 10:21:09 -0700 Subject: [OpenAjaxMobile] Howard's comments (changing the title) In-Reply-To: Message-ID: Hi Howard and Larry, Sorry, I was incommunicado at the end of yesterday. See my views below. Jon "Howard Weingram" To Sent by: , "OpenAjax mobile-bounces at op Alliance Security Task Force" enajax.org cc 05/06/08 04:51 PM Subject [OpenAjaxMobile] FW: [OpenAjaxSecurity] Minutes special Please respond to phone call 2008-05-06 OpenAjax Alliance betweenMobile TF and Security TF discussion list on Mobile Ajax Does the following roughly summarize the situation (this is partly a recap and partly additional commentary)? 1. A device can expose named features. These are exposed to JavaScript in the mobile browser as APIs. I expect most of us agree with the general flavor here, but I want to nitpick with the terminology. I wouldn't phrase it exactly this way. First off, I think the term "user agent", "system", "environment" or "platform" is better than device because some people might think that the "device" is the hardware or core OS and not include the Web Runtime. I have been using the term "system" so far. Also, I think it is more accurate to say that the mobile system exposes features, some of which are named features (i.e., some of the exposed features correspond to the feature names that OpenAjax Alliance will produce and therefore can be used with a security manager that supports our guidelines). This is a subtle differentiation, but I just want to emphasize that even if we succeed in producing standards that get adopted in large parts of the mobile device API world, there will always be other parts of the industry that is bypassing our mechanisms. 2. A device must be able to control which scripts can be trusted to access these features by using these APIs. By default, no permissions are granted (a "white list"). Yes, sure, but again we'll need to soften the language, at a minimum from MUST to SHOULD. We can't and shouldn't attempt to mandate a single approach to vendors. White listing is likely to be one of our recommendations, but in particular scenarios a vendor might be justified in choosing an alternate approach, perhaps even blacklisting. 3. The environment (browser, OS, etc.) must enforce the access permissions; JavaScript running in a mobile browser cannot police itself. JavaScript running in a gadget outside of the browser cannot police itself. Yes. 4. Access policies for the browser could be expressed in terms of the domain from which JavaScript (or a gadget) is obtained. A benefit of this is that, much as I like JavaScript, this approach is not JavaScript specific. Other types of downloadable runtime components can be likewise controlled. Domains are already the main unit of access control for web browsers, so they already play a huge role in OpenAjax proposals related to security (sandboxes in OpenAjax Hub). Paddy has proposed (and this is now captured on the wiki) a generalization of this notion, where there are "agents" who can be identified by various techniques. Right now we give two examples, domains and distinguished name: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security#Agent_identity I expect that Paddy and others will agree that our architecture should be flexible enough to allow other identity mechanisms, not just domain and distinguished name. 5. For gadgets outside of the browser, you could adopt this same approach (or just let the device treat these gadgets as applications and rely on the device to deal with access on an application by application basis). We have talked about this in the Mobile TF, and I would say the consensus is yes and no. For the "yes", sure, it is possible that the industry consensus might result in the system treating gadgets in the same way as installable applications, but "no", we aren't certain ourselves that this is the best approach, and the rest of the community also might choose to treat widgets differently than installable applications. There is at least three major differences between a widget and an installable application. Widgets usually communicate with at most one web site, whereas installable applications are usually considered to be able to do just about anything, including talk to any number of web sites. Widgets often also get installed through a different user experience and they are launched from a different part of the mobile UI. Therefore, there is definitely an option to have different security policies to widgets and (other types of) installable applications. This is a great topic for more discussion. My guess is that our security framework and guidelines needs to do both, and allow either option for widgets: (a) treated the same as installable applications, or (b) treated differently. 6. When a script wants to access a feature, the device must requiest that the user explicitly grant the domain permission to access the feature. Script on web pages or gadgets from that domain can then access that feature. Our wiki page right now says that the policy might choose to allow, deny, or prompt regarding a particular access request: http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security#Permission_check_procedure In general, I believe our concensus is that OpenAjax Alliance should steer clear of mandating a particular approach to how the user gets involved in security. There are significant usability concerns regarding how a user gets involved in allowing software to get access to APIs. Prompting has proven to be problematic as users often just say yes to everything. We want the industry to innovate and organically discover the best approaches to user experience. Our guidelines are likely to point out that in various workflows the user needs to opt-in to allow access to private information, but opt-in might happen in various ways, such as listed particular domains as trusted, particular companies as trusted, particular applications (or widgets) as trusted, or maybe by runtime prompts. 7. A user must be able to revoke a granted privilege. At a minimum, we need to water this down from a MUST to a SHOULD. However, in practice with installed applications or widgets, I'm not sure how often a mobile user would actually invoke user interface to revoke priveleges except by uninstalling the software. For web pages, then I expect the browsers will offer some sort of trusted domain UI similar to what exists today, in which case probably there will be UI to revoke granted priveleges. 8. If multiple frames F1 and F2 are present and are associated with domains D1 and D2, then the fact that script from domain D1 is permitted to access a given feature does not imply that F2 can access it. Yes. 9. Special policies (e.g. can't access some features in Switzerland) would need to be understood and enforced by the device environment, not by the JavaScript. As such, while it may be useful for some JavaScript to find out from the environment what normally-accessible features are disabled at a given moment, the JavaScript won't be responsible for enforcing that disablement. Yes. General comment: The more complex the permissioning mechanism, the less likely it is that it will ever be implemented in devices. History is littered with standards (in the security sphere, in particular) that were never implemented fully because they drowned in complexity. Anything we propose must be as minimal and focused as possible, with concepts that are as simple, concrete and familiar as we can make them. Yes. Question: Were these "features" the same that I discussed with you, Jon, in the context of gadgets (i.e., a feature is a named interface specification, no more and no less) or is this a separate use of the term "feature?" Yes and no. Depends on how you think about things. In both cases, there is a string that identifies a collection of functionality, and a set of APIs associated with that string, which is the yes part, but I expect there will be differences in how things get initialized and used. My recommendation is to treat them as separate things for now, and as we get further along on both sides see if they happen to gravitate to the same solution. hw From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Tuesday, May 06, 2008 2:34 PM To: mobile at openajax.org; security at openajax.org Subject: [OpenAjaxSecurity] Minutes special phone call 2008-05-06 betweenMobile TF and Security TF Mobile Minutes 2008-05-06 URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 Attendees Larry Koved, IBM (Security TF) Suresh Chari, IBM (Security TF) Paddy Byers, Aplix (Mobile TF) Nikunj Mehta, Oracle (Mobile TF) Guillermo Caudevilla, Vodafone (Mobile TF) Caroline ?, Vodadone (Mobile TF) David Pollington, Vodafone (Mobile TF) Jon Ferraiolo, IBM (Security TF & Mobile TF) Agenda Feedback from Security TF on work so far within Mobile TF on a conceptual framework for mobile device API security http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security Minutes (Jon provides background on the phone call, how the industry decided that there needed to be a community effort around JavaScript APIs to mobile device services, and that dealing with security is considered critical.) (Jon quickly summarizes use cases, with four deployment models, web, widgets, native apps loading a WebRuntime DLL, and a site specific browser.) (Jon describes the thinking by the current thinking behind the security wiki page where we attempt to provide a conceptual framework and some guidelines for particular cases, but leave the final decisions to the vendors, and count on the market to drive the vendors towards good solutions.) Caroline: Is there a risk that if we don't define quite a few guidelines, then the industry might drift towards insecure approaches? Jon: Yes, there is a risk that vendors might adopt insecure approaches, and also an interoperability risk if vendors choose different approaches, which might confuse developers and users. Nikunj: Our thinking is that besides a conceptual framework, we also provide recommendations. Jon: Yes, but I'm not sure if I would say "recommendation" yet. We have to get further along to see how confident we are about what we are proposing. Maybe some things will be recommendations, and maybe others will be suggestions for consideration. But, yes, we want to identify the most common scenarios and the associated issues and make recommendations or suggestions for them. Paddy: Aplix is creating a plugin that enables runtime APIs to Java. We have a permissions framework. Our aspiration for this work is sharing the permissions framework with other similar products. Imagine a JavaScript API to a certain function. There could be multiple underlying implementations of that API, not just ours. We want common APIs and a common security policy approach. The JavaScript says here are the things I require. We need a common approach for security policies that governs the use of those APIs. Larry: I generally agree with that perspective. We don't want unexpected results on different platforms. Jon: I am hearing that we want to have a common policy framework but OK if different products implement different security policies within that common framework. Paddy: We use Java API permissions but another implementation might model after a different permission engine. Better to have a common way to express the APIs. Jon: Makes sense to me. Jon: Let's talk about one thing in particular. Paddy has proposed a feature string corresponding to each API, some sort of unique ID, and the ability to ask the system if you have permission to use that API. Paddy: The permission check wouldn't happen at the user JavaScript level. Larry: What is the programming model? What are the types of security ??? to enforce? What are the constraints on those functions? For example, getcurrentlocation(). Do we want to do something like Java where there is a call to a Java-like security manager? Versus the OpenAjax Hub which is more of a message passing paradigm. Suresh: I think Paddy's right. You need a standard way of asking for the feature you want to access. Is that correct, Paddy? Paddy: We have been talking about deployment models, both for installed widgets and web site. Have a security manager or access control. Uniformly intercepts all security-relevant actions. Making a decision based on the identities of the things making the action. URL for a web site or a widget identified via distinguished name. Then what action is attempted, and particular circumstances passed as parameters. The Security manager intercepts. Doesn't live in JavaScript land. Lives in the browser or a plugin, something that is protected. Larry: OK, sounds very familiar. Java security works like this. Applet has a certain set of requirements. JAZ. But you need other attributes for mobile workflows. In the regulated space, in Switzerland, for example, some transactions are OK in Switzerland but not outside of Switzerland. So the location attribute can be important. Larry: Let me tell you my concerns from a pragmatic perspective. I've done Java security for 12 years. It functions correctly, but has a couple of deficiencies. Operationally, however, what I have observed is that people can't figure out how to do security policies. I've a tool for Java security, Sord (?) for Java. What I have found is that people have trouble with Java's stack-based security policy. I like your apporach but the challenge will be to keep it simple enough while still enforcing what the intent is. My personal opinion is that we need something similar but simpler than Java that covers base requirements. Paddy: Because of JavaScript, you can't make distinctions between call stacks if everything is in the same frame. So, we wouldn't have the full generality of JavaScript stack introspection. But we do want the notion of a trusted subsystem. I know this is possible in case of a Java bridge. The trusted subsystem is trusted to not expose the full set of APIs to its clients. We want to capture this in some sort of general way. Larry: Does everyone here understand how Java security works? Jon: I don't. (Larry promises to send info) Larry: Java looks at all of the code in the runtime stack and checks the authorization of each caller in the stack. If anyone is not authorized, then there is an error. Problem is that developers can't figure out what's in the calling stack. Shortcut with doPrivelege. There are books. Question is whether we can adopt these basic concepts. Get desired properties but not as much complexity. Java is probably the closest thing that exist to what we need. Paddy: Regarding the difficulties in writing policy, is it just something that is intrinsically difficult? Larry: Sun took one approach. I had proposed another, which is in Sord (?). Code analysis tools can't really be used with JavaScript because of eval(). Need a simpler approach that leverages domains or signatures. Larry: Coming to the end of the call. Next steps? Jon: Larry needs to send links to info on Java security. Jon: Next question is whether the security white paper or whatever should be driven by Mobile TF, with collaboration from Security TF, or the other way. (Conclusion: drive from Mobile TF due to close coupling with API effort and expected higher participation level from Mobile TF) Caroline: OMTP is doing something similar. Should we try to align the two efforts? Jon: I would guess yes, but I don't know what OMTP is doing because they are trying to agree to allow information to be shared outside of OMTP. I am scheduled to talk to Nick Alcott on May 23. Caroline: Yes, we (OMTP) are trying to get agreement to release some things to the public. (Jon/Caroline agree to have a phone call next week Thursday or Friday to coordinate on OMTP)_______________________________________________ security mailing list security at openajax.org http://openajax.org/mailman/listinfo/security _______________________________________________ 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/20080507/6ba272f6/attachment-0001.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/20080507/6ba272f6/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic27015.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080507/6ba272f6/attachment-0004.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/20080507/6ba272f6/attachment-0005.gif From paddy.byers at gmail.com Wed May 7 10:50:10 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Wed, 7 May 2008 18:50:10 +0100 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: References: Message-ID: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> Hi, Personal opinion: > *Question #1: Should our APIs be synchronous of asynchronous?* > Asynchronous, except in the case where it is obvious (in nearly every conceivable architecture) that the call cannot block. For example, lets say you had a bluetooth discovery API. The discovery phase is known to be blocking and would be an asynchronous API. But retrieving details of the discovered devices is then known not to block, because all necessary details needed to fulfil the API was obtained in the asynchronous part of the operation. *Question #2: Should our APIs be designed around message passing?* > Allow for, but not force, a message-passing-based implementation. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080507/f896ae2b/attachment.html From jferrai at us.ibm.com Wed May 7 11:04:04 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 7 May 2008 11:04:04 -0700 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> Message-ID: Paddy, I don't understand what it means to allow for, but not force, a message passing implementation. Could you elaborate? Thanks. Jon "Paddy Byers" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc Suresh N Chari/Watson/IBM at IBMUS, 05/07/08 10:50 AM Michael Steiner/Watson/IBM at IBMUS, Sumeer Bhola/Watson/IBM at IBMUS, Larry Koved/Watson/IBM at IBMUS Please respond to Subject OpenAjax Alliance Re: [OpenAjaxMobile] Async vs sync discussion list APIs (leveraging the Hub?) on Mobile Ajax Hi, Personal opinion: Question #1: Should our APIs be synchronous of asynchronous? Asynchronous, except in the case where it is obvious (in nearly every conceivable architecture) that the call cannot block. For example, lets say you had a bluetooth discovery API. The discovery phase is known to be blocking and would be an asynchronous API. But retrieving details of the discovered devices is then known not to block, because all necessary details needed to fulfil the API was obtained in the asynchronous part of the operation. Question #2: Should our APIs be designed around message passing? Allow for, but not force, a message-passing-based implementation. Thanks - 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/20080507/c29bc291/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/20080507/c29bc291/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic15678.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080507/c29bc291/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/20080507/c29bc291/attachment-0002.gif From paddy.byers at gmail.com Wed May 7 11:15:44 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Wed, 7 May 2008 19:15:44 +0100 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: References: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> Message-ID: <59db1b5a0805071115u46db9321vce0ef8ebe9b26ca1@mail.gmail.com> Hi, > I don't understand what it means to allow for, but not force, a message > passing implementation. Could you elaborate? > Messaging passing should be one possible mechanism for implementation, but not the only implementation. If the async APIs are presented as you suggested, ie: ---function MyCallBack(...) {...} > ---OpenAjax.whatever.getCurrent > > Location(MyCallback, ...); > then you ensure that, although message-passing could be used to implement the API, there are other possible mechanisms - eg using asynchronous events from an ActiveX native library. Alternatively, you could have defined something like a message-passing protocol to get the location, which would then mean that other implementations are not possible. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080507/0912907c/attachment.html From jferrai at us.ibm.com Wed May 7 11:18:54 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 7 May 2008 11:18:54 -0700 Subject: [OpenAjaxMobile] Agenda for tomorrow's phone call {Phishing?} Message-ID: Time: 9amPT, noonET, 5pm London, 6pm Paris Agenda * Review action list - where do we stand? ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo * Is there anything else we need to do before claiming victory on our Exploratory phase? Proposed way forward: --1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). --2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: **** Work on a lengthy security white paper about allowing the Web Runtime to access device apis ***** But need to factor in coordination with OMTP **** Launch an open source project for a JavaScript shim layer ***** Need to sketch out a high-level plan (who, what, when, how) ***** Document the shim layer within a Specification --3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings * Full list of our Mobile Device API wiki pages: ** http://www.openajax.org/member/wiki/Mobile_Device_APIs ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo See below for call-in information. [edit] 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 IRC channel IRC channel: irc.freenode.net, #oaa-mobile Free online IRC client: http://java.freenode.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080507/793b6b35/attachment-0001.html From jferrai at us.ibm.com Wed May 7 11:49:11 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 7 May 2008 11:49:11 -0700 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: <59db1b5a0805071115u46db9321vce0ef8ebe9b26ca1@mail.gmail.com> Message-ID: Thanks. Makes sense to me. It would be great if others could indicate whether they are in agreement, also. Jon "Paddy Byers" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc Suresh N Chari/Watson/IBM at IBMUS, 05/07/08 11:15 AM Michael Steiner/Watson/IBM at IBMUS, Sumeer Bhola/Watson/IBM at IBMUS, Larry Koved/Watson/IBM at IBMUS Please respond to Subject OpenAjax Alliance Re: [OpenAjaxMobile] Async vs sync discussion list APIs (leveraging the Hub?) on Mobile Ajax Hi, I don't understand what it means to allow for, but not force, a message passing implementation. Could you elaborate? Messaging passing should be one possible mechanism for implementation, but not the only implementation. If the async APIs are presented as you suggested, ie: ---function MyCallBack(...) {...} ---OpenAjax.whatever.getCurrent Location(MyCallback, ...); then you ensure that, although message-passing could be used to implement the API, there are other possible mechanisms - eg using asynchronous events from an ActiveX native library. Alternatively, you could have defined something like a message-passing protocol to get the location, which would then mean that other implementations are not possible. Thanks - 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/20080507/8194cb3c/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/20080507/8194cb3c/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic04510.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080507/8194cb3c/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/20080507/8194cb3c/attachment-0002.gif From guillermo.caudevilla at vodafone.com Thu May 8 07:06:00 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Thu, 8 May 2008 16:06:00 +0200 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F014A29D1@ESM9-MXMB05.vf-es.internal.vodafone.com> Question #1: Should our APIs be synchronous of asynchronous? Asynchronous. Getting data from the device does not runs so smoothly as the in the PC space. From our experience with MobileScript (which uses synchronous calls) getting for instance contacts from both device and SIM card can be very time consuming. 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 Paddy Byers Sent: mi?rcoles, 07 de mayo de 2008 18:50 To: OpenAjax Alliance discussion list on Mobile Ajax Cc: Suresh N. Chari; Michael Steiner; Sumeer Bhola; Larry Koved Subject: Re: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) Hi, Personal opinion: Question #1: Should our APIs be synchronous of asynchronous? Asynchronous, except in the case where it is obvious (in nearly every conceivable architecture) that the call cannot block. For example, lets say you had a bluetooth discovery API. The discovery phase is known to be blocking and would be an asynchronous API. But retrieving details of the discovered devices is then known not to block, because all necessary details needed to fulfil the API was obtained in the asynchronous part of the operation. Question #2: Should our APIs be designed around message passing? Allow for, but not force, a message-passing-based implementation. Thanks - Paddy 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/20080508/dfd9bad4/attachment.html From paddy.byers at gmail.com Thu May 8 07:40:48 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Thu, 8 May 2008 15:40:48 +0100 Subject: [OpenAjaxMobile] Agenda for tomorrow's phone call {Phishing?} In-Reply-To: References: Message-ID: <59db1b5a0805080740k5bef866x7e6ae855d06c3116@mail.gmail.com> Hi, I'm sorry but I won't be able to make the call today. Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080508/ffe423ff/attachment.html From nikunj.mehta at oracle.com Thu May 8 09:15:35 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Thu, 08 May 2008 09:15:35 -0700 Subject: [OpenAjaxMobile] Agenda for tomorrow's phone call {Phishing?} In-Reply-To: References: Message-ID: <48232727.5030802@oracle.com> Has the meeting started? I am still hearing music. Nikunj Jon Ferraiolo wrote: > > > Time: > 9amPT, noonET, 5pm London, 6pm Paris > Agenda > * Review action list - where do we stand? > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo > * Is there anything else we need to do before claiming victory on our > Exploratory phase? > Proposed way forward: > --1. Publicize our progress. I don't think we can justify/execute a > press release on this particular topic. Instead, send short > announcement articles to Ajaxian and AJAXWorld, and also author/submit > a 2000-world article to AJAXWorld magazine (for both print and Web). > --2. Start work on a Working Group charter that describes what formal > activities we should take up at OpenAjax Alliance. Here is my thinking > of what the charter might say: > **** Work on a lengthy security white paper about allowing the Web > Runtime to access device apis > ***** But need to factor in coordination with OMTP > **** Launch an open source project for a JavaScript shim layer > ***** Need to sketch out a high-level plan (who, what, when, how) > ***** Document the shim layer within a Specification > --3. Send email to selected major players to tell them we finished the > exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > * Full list of our Mobile Device API wiki pages: > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo > See below for call-in information. > > [edit > ] > 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 > > IRC channel > > IRC channel: irc.freenode.net, #oaa-mobile > Free online IRC client: http://java.freenode.net/ > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From jferrai at us.ibm.com Thu May 8 09:26:57 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 8 May 2008 09:26:57 -0700 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Message-ID: Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080508/a2658e36/attachment-0001.html From guillermo.caudevilla at vodafone.com Thu May 8 09:32:13 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Thu, 8 May 2008 18:32:13 +0200 Subject: [OpenAjaxMobile] Agenda for tomorrow's phone call {Phishing?} In-Reply-To: <48232727.5030802@oracle.com> Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F014A29F5@ESM9-MXMB05.vf-es.internal.vodafone.com> Same here. 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 > -----Original Message----- From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Nikunj Mehta Sent: jueves, 08 de mayo de 2008 17:16 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] Agenda for tomorrow's phone call {Phishing?} Has the meeting started? I am still hearing music. Nikunj Jon Ferraiolo wrote: > > > Time: > 9amPT, noonET, 5pm London, 6pm Paris > Agenda > * Review action list - where do we stand? > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo > * Is there anything else we need to do before claiming victory on our > Exploratory phase? > Proposed way forward: > --1. Publicize our progress. I don't think we can justify/execute a > press release on this particular topic. Instead, send short > announcement articles to Ajaxian and AJAXWorld, and also author/submit > a 2000-world article to AJAXWorld magazine (for both print and Web). > --2. Start work on a Working Group charter that describes what formal > activities we should take up at OpenAjax Alliance. Here is my thinking > of what the charter might say: > **** Work on a lengthy security white paper about allowing the Web > Runtime to access device apis > ***** But need to factor in coordination with OMTP > **** Launch an open source project for a JavaScript shim layer > ***** Need to sketch out a high-level plan (who, what, when, how) > ***** Document the shim layer within a Specification --3. Send email > to selected major players to tell them we finished the exploratory > phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > * Full list of our Mobile Device API wiki pages: > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey > ** http://www.openajax.org/member/wiki/Mobile_Device_APIs_Todo > See below for call-in information. > > [edit > edit§ion=5>] > 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 > > IRC channel > > IRC channel: irc.freenode.net, #oaa-mobile Free online IRC client: > http://java.freenode.net/ > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile 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. From paddy.byers at gmail.com Thu May 8 23:52:01 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Fri, 9 May 2008 07:52:01 +0100 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: References: Message-ID: <59db1b5a0805082352w30ba9abcp226bacd15f464c6@mail.gmail.com> Hi, I'm traveling next week so only options 5 and 6 are possible for me. Thanks - Paddy On Thu, May 8, 2008 at 5:26 PM, Jon Ferraiolo wrote: > Hi everyone, > A number of people had sent in regrets for today's Mobile TF phone call, > but I was hoping that we could still have a productive phone call, but after > 10 minutes only John Hardi and I were on the call, so we cancelled. > > How about trying to reschedule for Monday or Tuesday next week? *Please > RSVP about which of the following times work for you:* > > 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm > 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm > 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm > 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm > 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm > 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm > > If we can't find a suitable time from the above list, then we'll just try > again next Thursday May 15 at the usual time, but I think we should attempt > to close out the exploratory phase as soon as we can. > > Here is the agenda: > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory on our > Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can justify/execute a press > release on this particular topic. Instead, send short announcement articles > to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to > AJAXWorld magazine (for both print and Web). > -- 2. Start work on a Working Group charter that describes what formal > activities we should take up at OpenAjax Alliance. Here is my thinking of > what the charter might say: > ---- o Work on a lengthy security white paper about allowing the Web > Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we finished the > exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > > 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/20080509/5b7235b9/attachment.html From david.pollington at vodafone.com Fri May 9 01:53:26 2008 From: david.pollington at vodafone.com (Pollington, David, VF-Group) Date: Fri, 9 May 2008 10:53:26 +0200 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: Message-ID: Options 1, 5 and 6 for me David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington at vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi 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: 08 May 2008 17:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080509/513a4177/attachment.html From nikunj.mehta at oracle.com Fri May 9 08:30:02 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Fri, 09 May 2008 08:30:02 -0700 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: References: Message-ID: <48246DFA.7030205@oracle.com> Hi Jon et al, 3 and 6 work for me. Nikunj Jon Ferraiolo wrote: > > Hi everyone, > A number of people had sent in regrets for today's Mobile TF phone > call, but I was hoping that we could still have a productive phone > call, but after 10 minutes only John Hardi and I were on the call, so > we cancelled. > > How about trying to reschedule for Monday or Tuesday next week? > */Please RSVP about which of the following times work for you:/* > > 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm > 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm > 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm > 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm > 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm > 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm > > If we can't find a suitable time from the above list, then we'll just > try again next Thursday May 15 at the usual time, but I think we > should attempt to close out the exploratory phase as soon as we can. > > Here is the agenda: > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory on our > Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can justify/execute a > press release on this particular topic. Instead, send short > announcement articles to Ajaxian and AJAXWorld, and also author/submit > a 2000-world article to AJAXWorld magazine (for both print and Web). > -- 2. Start work on a Working Group charter that describes what formal > activities we should take up at OpenAjax Alliance. Here is my thinking > of what the charter might say: > ---- o Work on a lengthy security white paper about allowing the Web > Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we finished > the exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > > Thanks. > Jon > > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From chaals at opera.com Sat May 10 08:14:09 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Sat, 10 May 2008 17:14:09 +0200 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: <59db1b5a0805082352w30ba9abcp226bacd15f464c6@mail.gmail.com> References: <59db1b5a0805082352w30ba9abcp226bacd15f464c6@mail.gmail.com> Message-ID: On Fri, 09 May 2008 08:52:01 +0200, Paddy Byers wrote: > Hi, > > I'm traveling next week so only options 5 and 6 are possible for me. And absent as I usually am, only Monday (options 1,2,3) works for me :( cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From guillermo.caudevilla at vodafone.com Sun May 11 02:38:16 2008 From: guillermo.caudevilla at vodafone.com (Caudevilla, Guillermo, VF-ES (gcaudev)) Date: Sun, 11 May 2008 11:38:16 +0200 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: Message-ID: <5D15570EE5B94A419F79FD3A2ABF223F014A2A80@ESM9-MXMB05.vf-es.internal.vodafone.com> 1, 2, 3 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: jueves, 08 de mayo de 2008 17:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings 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/20080511/c9211df1/attachment.html From Andrew.Sledd at ikivo.com Sun May 11 07:16:34 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Sun, 11 May 2008 16:16:34 +0200 Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call In-Reply-To: Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDD01BD0@SESTHSRV10.zoomon.local> I am traveling and unavailable until Thursday at the earliest. Andy ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 8 maj 2008 18:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080511/adc79d8d/attachment.html From nikunj.mehta at oracle.com Sun May 11 08:21:56 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Sun, 11 May 2008 08:21:56 -0700 Subject: [OpenAjaxMobile] Async vs sync APIs (leveraging the Hub?) In-Reply-To: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> References: <59db1b5a0805071050i2a34958bp96437e6859e6f266@mail.gmail.com> Message-ID: <48270F14.90806@oracle.com> Paddy Byers wrote: > Personal opinion: > > *Question #1: Should our APIs be synchronous of asynchronous?* > > Asynchronous, except in the case where it is obvious (in nearly every > conceivable architecture) that the call cannot block. On S60 devices, the XMLHttpRequest does not offer a sync mode at all. In HTML5, the SQL interface doesn't offer synchronous API anytime a result is expected. I support Paddy that the default style for calls that return a result would be asynchronous style callbacks. > > *Question #2: Should our APIs be designed around message passing?* > > Allow for, but not force, a message-passing-based implementation. We have two principles at question here - ergonomic APIs and Javascript friendly. It is better if the APIs use a similar style so that the learning curve is simplified. It would be preferable for style purposes to not arbitrarily switch between call and message styles within the API. Therefore, and given that most Javascript libraries do not use message passing style, IMHO OpenAjax should not use message passing. From jferrai at us.ibm.com Mon May 12 06:35:04 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 12 May 2008 06:35:04 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call on Thursday? In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD01BD0@SESTHSRV10.zoomon.local> Message-ID: Andy is out until Thursday. If the co-chair can't join the phone call until Thursday, then let's forget about a phone call earlier in the week. But let's make sure we will have a quorum for the regular Thursday time slot. Please RVSP about whether you will be able to attend a phone call on Thursday: Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Jon "Andrew Sledd" To Sent by: "OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax" enajax.org cc 05/11/08 07:16 AM Subject Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Please respond to OpenAjax Alliance discussion list on Mobile Ajax I am traveling and unavailable until Thursday at the earliest. Andy From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 8 maj 2008 18:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings 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/20080512/9d6e27f9/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/20080512/9d6e27f9/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic23668.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080512/9d6e27f9/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/20080512/9d6e27f9/attachment-0002.gif From paddy.byers at gmail.com Mon May 12 08:10:11 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Mon, 12 May 2008 16:10:11 +0100 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call on Thursday? In-Reply-To: References: <234EB4699C751A4A95DF4FD8D041BBFDD01BD0@SESTHSRV10.zoomon.local> Message-ID: <59db1b5a0805120810j24169061ua16126f555178a92@mail.gmail.com> > > But let's make sure we will have a quorum for the regular Thursday time > slot. *Please RVSP about whether you will be able to attend a phone call > on Thursday:* > Yes, I'm OK. Thanks - Paddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080512/ae45131f/attachment.html From nickolas at us.ibm.com Mon May 12 09:43:07 2008 From: nickolas at us.ibm.com (Stewart Nickolas) Date: Mon, 12 May 2008 12:43:07 -0400 Subject: [OpenAjaxMobile] Nickolas, Stewart is out of the office. Message-ID: I will be out of the office starting 05/12/2008 and will not return until 05/16/2008. I will respond to your message when I return. From nikunj.mehta at oracle.com Wed May 14 14:52:23 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Wed, 14 May 2008 14:52:23 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call on Thursday? In-Reply-To: References: Message-ID: <482B5F17.9040105@oracle.com> Jon Ferraiolo wrote: > > But let's make sure we will have a quorum for the regular Thursday > time slot. */Please RVSP about whether you will be able to attend a > phone call on Thursday:/* > My regrets. I am in meetings the rest of this week and can't make it to the morning call tomorrow. I will send out a separate email regarding the agenda Jon sent out earlier. Nikunj From ksankar at cisco.com Wed May 14 15:50:33 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Wed, 14 May 2008 15:50:33 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? In-Reply-To: References: <234EB4699C751A4A95DF4FD8D041BBFDD01BD0@SESTHSRV10.zoomon.local> Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B64A@xmb-sjc-219.amer.cisco.com> I will attend. Do we have a call number ? (Or is it same as before?) Interested in contributing to the shim layer. Quick question : Don't we need to have a rough spec first - as opposed to launch the Open Source and then documenting it ? May be both activities should happen in parallel. Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Monday, May 12, 2008 6:35 AM To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? Andy is out until Thursday. If the co-chair can't join the phone call until Thursday, then let's forget about a phone call earlier in the week. But let's make sure we will have a quorum for the regular Thursday time slot. Please RVSP about whether you will be able to attend a phone call on Thursday: Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Jon Inactive hide details for "Andrew Sledd" "Andrew Sledd" "Andrew Sledd" Sent by: mobile-bounces at openajax.org 05/11/08 07:16 AM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To "OpenAjax Alliance discussion list on Mobile Ajax" cc Subject Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call I am traveling and unavailable until Thursday at the earliest. Andy ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 8 maj 2008 18:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From jferrai at us.ibm.com Wed May 14 16:14:12 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 14 May 2008 16:14:12 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B64A@xmb-sjc-219.amer.cisco.com> Message-ID: Hi Krishna, Same call-in number as always. See http://www.openajaxalliance.org/member/wiki/Mobile_TF. Yes, I agree that a rough spec makes sense before doing much (or anything) on the implementation side. What I am thinking is that the *detailed* spec will tend to result from lessons learned from actual implementation, but the rough spec in general will be figured out on paper beforehand. I launched some initial discussion by asking whether our APIs should sync or async. We seem to have agreed on async, which is a major decision (IMO). Sometime soon we should talk about how one particular API (e.g., location) should look and see if that can serve as a reasonable model for the other APIs. Until tomorrow! Jon "Krishna Sankar (ksankar)" "OpenAjax Alliance discussion list Sent by: on Mobile Ajax" mobile-bounces at op enajax.org cc Subject 05/14/08 03:50 PM Re: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? Please respond to OpenAjax Alliance discussion list on Mobile Ajax I will attend. Do we have a call number ? (Or is it same as before?) Interested in contributing to the shim layer. Quick question : Don't we need to have a rough spec first - as opposed to launch the Open Source and then documenting it ? May be both activities should happen in parallel. Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Monday, May 12, 2008 6:35 AM To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? Andy is out until Thursday. If the co-chair can't join the phone call until Thursday, then let's forget about a phone call earlier in the week. But let's make sure we will have a quorum for the regular Thursday time slot. Please RVSP about whether you will be able to attend a phone call on Thursday: Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Jon Inactive hide details for "Andrew Sledd" "Andrew Sledd" "Andrew Sledd" Sent by: mobile-bounces at openajax.org 05/11/08 07:16 AM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To "OpenAjax Alliance discussion list on Mobile Ajax" cc Subject Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call I am traveling and unavailable until Thursday at the earliest. Andy ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 8 maj 2008 18:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile _______________________________________________ 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/20080514/38e90df9/attachment-0001.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/20080514/38e90df9/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic22115.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080514/38e90df9/attachment-0004.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/20080514/38e90df9/attachment-0005.gif From "arun" at mozilla.com Wed May 14 17:14:34 2008 From: "arun" at mozilla.com (Arun Ranganathan) Date: Wed, 14 May 2008 17:14:34 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? In-Reply-To: References: Message-ID: <20080515001434.D7DCE8240CE@dm-mail02.mozilla.org> I will attend. Look forward to talking at 9a.m. tomorrow :) -- A* Jon Ferraiolo wrote: > > Hi Krishna, > Same call-in number as always. See > http://www.openajaxalliance.org/member/wiki/Mobile_TF. > > Yes, I agree that a rough spec makes sense before doing much (or > anything) on the implementation side. What I am thinking is that the > *detailed* spec will tend to result from lessons learned from actual > implementation, but the rough spec in general will be figured out on > paper beforehand. I launched some initial discussion by asking whether > our APIs should sync or async. We seem to have agreed on async, which > is a major decision (IMO). Sometime soon we should talk about how one > particular API (e.g., location) should look and see if that can serve > as a reasonable model for the other APIs. > > Until tomorrow! > Jon > > Inactive hide details for "Krishna Sankar (ksankar)" > "Krishna Sankar (ksankar)" > > > *"Krishna Sankar (ksankar)" * > Sent by: mobile-bounces at openajax.org > > 05/14/08 03:50 PM > Please respond to > OpenAjax Alliance discussion list on Mobile > Ajax > > > > To > > "OpenAjax Alliance discussion list on Mobile Ajax" > > cc > > > Subject > > Re: [OpenAjaxMobile] RSVP please - Can you attend a phone call > onThursday? > > > > > I will attend. Do we have a call number ? (Or is it same as before?) > > Interested in contributing to the shim layer. > > Quick question : Don't we need to have a rough spec first - as opposed > to launch the Open Source and then documenting it ? May be both > activities should happen in parallel. > > Cheers > > > > ________________________________ > > From: mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo > Sent: Monday, May 12, 2008 6:35 AM > To: mobile at openajax.org > Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone > call onThursday? > > > > Andy is out until Thursday. If the co-chair can't join the phone > call until Thursday, then let's forget about a phone call earlier in the > week. > > But let's make sure we will have a quorum for the regular > Thursday time slot. Please RVSP about whether you will be able to attend > a phone call on Thursday: > > Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory > on our Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can > justify/execute a press release on this particular topic. Instead, send > short announcement articles to Ajaxian and AJAXWorld, and also > author/submit a 2000-world article to AJAXWorld magazine (for both print > and Web). > -- 2. Start work on a Working Group charter that describes what > formal activities we should take up at OpenAjax Alliance. Here is my > thinking of what the charter might say: > ---- o Work on a lengthy security white paper about allowing the > Web Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, > how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we > finished the exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > Jon > > Inactive hide details for "Andrew Sledd" > "Andrew Sledd" > > > > > "Andrew Sledd" > > Sent by: > mobile-bounces at openajax.org > > 05/11/08 07:16 AM > > Please respond to > OpenAjax Alliance discussion > list on Mobile Ajax > > > > > To > > "OpenAjax Alliance discussion list on Mobile Ajax" > > > > cc > > > > > Subject > > Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone > call > > > I am traveling and unavailable until Thursday at the earliest. > > Andy > > > ________________________________ > > From: mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo > Sent: den 8 maj 2008 18:27 > To: mobile at openajax.org > Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's > phone call > > > Hi everyone, > A number of people had sent in regrets for today's Mobile TF > phone call, but I was hoping that we could still have a productive phone > call, but after 10 minutes only John Hardi and I were on the call, so we > cancelled. > > How about trying to reschedule for Monday or Tuesday next week? > Please RSVP about which of the following times work for you: > > 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm > Paris/Stockholm > 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm > Paris/Stockholm > 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm > Paris/Stockholm > 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm > Paris/Stockholm > 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > > If we can't find a suitable time from the above list, then we'll > just try again next Thursday May 15 at the usual time, but I think we > should attempt to close out the exploratory phase as soon as we can. > > Here is the agenda: > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory > on our Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can > justify/execute a press release on this particular topic. Instead, send > short announcement articles to Ajaxian and AJAXWorld, and also > author/submit a 2000-world article to AJAXWorld magazine (for both print > and Web). > -- 2. Start work on a Working Group charter that describes what > formal activities we should take up at OpenAjax Alliance. Here is my > thinking of what the charter might say: > ---- o Work on a lengthy security white paper about allowing the > Web Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, > how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we > finished the exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > > Thanks. > Jon > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > > > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From ksankar at cisco.com Wed May 14 17:53:02 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Wed, 14 May 2008 17:53:02 -0700 Subject: [OpenAjaxMobile] RSVP please - Can you attend a phonecall onThursday? In-Reply-To: References: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B64A@xmb-sjc-219.amer.cisco.com> Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B6D4@xmb-sjc-219.amer.cisco.com> Good. I like "Rough consensus and running code" methodology anyway. Yep, a rough write-up, followed by implementations would solidify the interfaces. Would be better if we work across 2 feature APIs - basically more than one to get the full breadth of the complexity. May be start with Capability Discovery and Location/GPS API; then move on to messaging when we get that far. As the APIs will have to work across multiple device makers, we also would need a device discovery - probably part of the Capability Discovery API. Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Wednesday, May 14, 2008 4:14 PM To: OpenAjax Alliance discussion list on Mobile Ajax Subject: Re: [OpenAjaxMobile] RSVP please - Can you attend a phonecall onThursday? Hi Krishna, Same call-in number as always. See http://www.openajaxalliance.org/member/wiki/Mobile_TF. Yes, I agree that a rough spec makes sense before doing much (or anything) on the implementation side. What I am thinking is that the *detailed* spec will tend to result from lessons learned from actual implementation, but the rough spec in general will be figured out on paper beforehand. I launched some initial discussion by asking whether our APIs should sync or async. We seem to have agreed on async, which is a major decision (IMO). Sometime soon we should talk about how one particular API (e.g., location) should look and see if that can serve as a reasonable model for the other APIs. Until tomorrow! Jon Inactive hide details for "Krishna Sankar (ksankar)" "Krishna Sankar (ksankar)" "Krishna Sankar (ksankar)" Sent by: mobile-bounces at openajax.org 05/14/08 03:50 PM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To "OpenAjax Alliance discussion list on Mobile Ajax" cc Subject Re: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? I will attend. Do we have a call number ? (Or is it same as before?) Interested in contributing to the shim layer. Quick question : Don't we need to have a rough spec first - as opposed to launch the Open Source and then documenting it ? May be both activities should happen in parallel. Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Monday, May 12, 2008 6:35 AM To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone call onThursday? Andy is out until Thursday. If the co-chair can't join the phone call until Thursday, then let's forget about a phone call earlier in the week. But let's make sure we will have a quorum for the regular Thursday time slot. Please RVSP about whether you will be able to attend a phone call on Thursday: Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Jon Inactive hide details for "Andrew Sledd" "Andrew Sledd" "Andrew Sledd" Sent by: mobile-bounces at openajax.org 05/11/08 07:16 AM Please respond to OpenAjax Alliance discussion list on Mobile Ajax To "OpenAjax Alliance discussion list on Mobile Ajax" cc Subject Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call I am traveling and unavailable until Thursday at the earliest. Andy ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: den 8 maj 2008 18:27 To: mobile at openajax.org Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone call Hi everyone, A number of people had sent in regrets for today's Mobile TF phone call, but I was hoping that we could still have a productive phone call, but after 10 minutes only John Hardi and I were on the call, so we cancelled. How about trying to reschedule for Monday or Tuesday next week? Please RSVP about which of the following times work for you: 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm Paris/Stockholm 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm Paris/Stockholm 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm Paris/Stockholm If we can't find a suitable time from the above list, then we'll just try again next Thursday May 15 at the usual time, but I think we should attempt to close out the exploratory phase as soon as we can. Here is the agenda: Agenda * Review action list - where do we stand? -- Mobile Device APIs initiative todo list * Is there anything else we need to do before claiming victory on our Exploratory phase? * Proposed way forward: -- 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). -- 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: ---- o Work on a lengthy security white paper about allowing the Web Runtime to access device apis ------ + But need to factor in coordination with OMTP ---- o Launch an open source project for a JavaScript shim layer ------ + Need to sketch out a high-level plan (who, what, when, how) ---- o Document the shim layer within a Specification -- 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback * Decide on next meeting and frequency of future meetings Thanks. Jon _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile _______________________________________________ mobile mailing list mobile at openajax.org http://openajax.org/mailman/listinfo/mobile From "arun" at mozilla.com Thu May 15 11:49:54 2008 From: "arun" at mozilla.com (Arun Ranganathan) Date: Thu, 15 May 2008 11:49:54 -0700 Subject: [OpenAjaxMobile] WHATWG Location API Proposal | Re: RSVP please - Can you attend a phonecall onThursday? In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B6D4@xmb-sjc-219.amer.cisco.com> References: <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B64A@xmb-sjc-219.amer.cisco.com> <9FA16888AD1BF64ABCE6C2532CCEB98A04C3B6D4@xmb-sjc-219.amer.cisco.com> Message-ID: <20080515184954.ACB66B8604@dm-mail01.mozilla.org> Google Gears propose this to WHATWG: http://code.google.com/p/google-gears/wiki/LocationAPI To WebAPI they proposed their Blob API stuff. -- A* Krishna Sankar (ksankar) wrote: > Good. I like "Rough consensus and running code" methodology anyway. Yep, > a rough write-up, followed by implementations would solidify the > interfaces. > > Would be better if we work across 2 feature APIs - basically more than > one to get the full breadth of the complexity. May be start with > Capability Discovery and Location/GPS API; then move on to messaging > when we get that far. As the APIs will have to work across multiple > device makers, we also would need a device discovery - probably part of > the Capability Discovery API. > > Cheers > > ________________________________ > > From: mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo > Sent: Wednesday, May 14, 2008 4:14 PM > To: OpenAjax Alliance discussion list on Mobile Ajax > Subject: Re: [OpenAjaxMobile] RSVP please - Can you attend a > phonecall onThursday? > > > > Hi Krishna, > Same call-in number as always. See > http://www.openajaxalliance.org/member/wiki/Mobile_TF. > > Yes, I agree that a rough spec makes sense before doing much (or > anything) on the implementation side. What I am thinking is that the > *detailed* spec will tend to result from lessons learned from actual > implementation, but the rough spec in general will be figured out on > paper beforehand. I launched some initial discussion by asking whether > our APIs should sync or async. We seem to have agreed on async, which is > a major decision (IMO). Sometime soon we should talk about how one > particular API (e.g., location) should look and see if that can serve as > a reasonable model for the other APIs. > > Until tomorrow! > Jon > > Inactive hide details for "Krishna Sankar (ksankar)" > "Krishna Sankar (ksankar)" > > > > > "Krishna Sankar (ksankar)" > > Sent by: > mobile-bounces at openajax.org > > 05/14/08 03:50 PM > > Please respond to > OpenAjax Alliance discussion > list on Mobile Ajax > > > > > To > > "OpenAjax Alliance discussion list on Mobile Ajax" > > > > cc > > > > > Subject > > Re: [OpenAjaxMobile] RSVP please - Can you attend a phone call > onThursday? > > > I will attend. Do we have a call number ? (Or is it same as > before?) > > Interested in contributing to the shim layer. > > Quick question : Don't we need to have a rough spec first - as > opposed > to launch the Open Source and then documenting it ? May be both > activities should happen in parallel. > > Cheers > > > > ________________________________ > > From: mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo > Sent: Monday, May 12, 2008 6:35 AM > To: mobile at openajax.org > Subject: [OpenAjaxMobile] RSVP please - Can you attend a phone > call onThursday? > > > > Andy is out until Thursday. If the co-chair can't join the phone > call until Thursday, then let's forget about a phone call > earlier in the > week. > > But let's make sure we will have a quorum for the regular > Thursday time slot. Please RVSP about whether you will be able > to attend > a phone call on Thursday: > > Thursday May 15 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory > on our Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can > justify/execute a press release on this particular topic. > Instead, send > short announcement articles to Ajaxian and AJAXWorld, and also > author/submit a 2000-world article to AJAXWorld magazine (for > both print > and Web). > -- 2. Start work on a Working Group charter that describes what > formal activities we should take up at OpenAjax Alliance. Here > is my > thinking of what the charter might say: > ---- o Work on a lengthy security white paper about allowing the > Web Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, > how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we > finished the exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > Jon > > Inactive hide details for "Andrew Sledd" > "Andrew Sledd" > > > > > "Andrew Sledd" > > Sent by: > mobile-bounces at openajax.org > > 05/11/08 07:16 AM > > Please respond to > OpenAjax Alliance discussion > list on Mobile Ajax > > > > > To > > "OpenAjax Alliance discussion list on Mobile Ajax" > > > > cc > > > > > Subject > > Re: [OpenAjaxMobile] RSVP Please - Rescheduling today's phone > call > > > I am traveling and unavailable until Thursday at the earliest. > > Andy > > > ________________________________ > > From: mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo > Sent: den 8 maj 2008 18:27 > To: mobile at openajax.org > Subject: [OpenAjaxMobile] RSVP Please - Rescheduling today's > phone call > > > Hi everyone, > A number of people had sent in regrets for today's Mobile TF > phone call, but I was hoping that we could still have a > productive phone > call, but after 10 minutes only John Hardi and I were on the > call, so we > cancelled. > > How about trying to reschedule for Monday or Tuesday next week? > Please RSVP about which of the following times work for you: > > 1: Monday May 12 7am US-PT, 10am US-ET, 3pm Londong, 4pm > Paris/Stockholm > 2: Monday May 12 8am US-PT, 11am US-ET, 4pm Londong, 5pm > Paris/Stockholm > 3: Monday May 12 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > 4: Tuesday May 13 7am US-PT, 10am US-ET, 3pm Londong, 4pm > Paris/Stockholm > 5: Tuesday May 13 8am US-PT, 11am US-ET, 4pm Londong, 5pm > Paris/Stockholm > 6: Tuesday May 13 9am US-PT, noon US-ET, 5pm Londong, 6pm > Paris/Stockholm > > If we can't find a suitable time from the above list, then we'll > just try again next Thursday May 15 at the usual time, but I > think we > should attempt to close out the exploratory phase as soon as we > can. > > Here is the agenda: > > Agenda > > * Review action list - where do we stand? > -- Mobile Device APIs initiative todo list > * Is there anything else we need to do before claiming victory > on our Exploratory phase? > * Proposed way forward: > -- 1. Publicize our progress. I don't think we can > justify/execute a press release on this particular topic. > Instead, send > short announcement articles to Ajaxian and AJAXWorld, and also > author/submit a 2000-world article to AJAXWorld magazine (for > both print > and Web). > -- 2. Start work on a Working Group charter that describes what > formal activities we should take up at OpenAjax Alliance. Here > is my > thinking of what the charter might say: > ---- o Work on a lengthy security white paper about allowing the > Web Runtime to access device apis > ------ + But need to factor in coordination with OMTP > ---- o Launch an open source project for a JavaScript shim layer > ------ + Need to sketch out a high-level plan (who, what, when, > how) > ---- o Document the shim layer within a Specification > -- 3. Send email to selected major players to tell them we > finished the exploratory phase, please review and send feedback > * Decide on next meeting and frequency of future meetings > > > Thanks. > Jon > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > > > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > > > > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From jferrai at us.ibm.com Thu May 15 18:25:07 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 15 May 2008 18:25:07 -0700 Subject: [OpenAjaxMobile] Minutes 2008-05-15 Message-ID: Minutes from today's phone call: Mobile Minutes 2008-05-15 URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506 Attendees Paddy Byers, Aplix Guillermo Caudevilla, Vodafone David Pollington, Vodafone Jon Ferraiolo, IBM Bob Goodman, IBM Krishna Shankar, Cisco Kai Hendry, Aplix Arun Ranganathan, Mozilla Agenda Agenda Review action list - where do we stand? Mobile Device APIs initiative todo list Is there anything else we need to do before claiming victory on our Exploratory phase? Proposed way forward: 1. Publicize our progress. I don't think we can justify/execute a press release on this particular topic. Instead, send short announcement articles to Ajaxian and AJAXWorld, and also author/submit a 2000-world article to AJAXWorld magazine (for both print and Web). 2. Start work on a Working Group charter that describes what formal activities we should take up at OpenAjax Alliance. Here is my thinking of what the charter might say: Work on a lengthy security white paper about allowing the Web Runtime to access device apis But need to factor in coordination with OMTP Launch an open source project for a JavaScript shim layer Need to sketch out a high-level plan (who, what, when, how) Document the shim layer within a Specification 3. Send email to selected major players to tell them we finished the exploratory phase, please review and send feedback Decide on next meeting and frequency of future meetings Full list of our Mobile Device API wiki pages: Mobile Device APIs initiative home page Mobile Device APIs Objectives Mobile Device APIs Use Cases Mobile Device APIs Requirements Mobile Device APIs Security Mobile Device APIs Due Diligence Industry Survey Mobile Device APIs initiative todo list Minutes Action list status and whether we can move forward (Jon talks about how all actions have been completed except maybe one, which is where Nikunj volunteered to look at requirements and see if there are any use cases that need to be added, which Jon said was a nice-to-have action. Jon asks if we can consider the exploratory phase complete and move forward to the next phase) Krishna: I think we can move forward. (no other comments) Jon: OK, let's talk about how we might move forward. OMTP coordination Jon: But first let me report on a coordination phone call I had just an hour ago with Nick Allott and Caroline Belrose regarding OMTP's work in the same general area of device apis. They are working on a similar white paper as we are thinking about in the same sort of timeframe. Paddy: There was an OMTP f2f meeting this week where we talked about two strands of work. Architecture and Security, and then interfaces. My opinion is that in terms of maturity of thinking, very similar to here. Not surprising as there are overlapping contributors. The two organizations have somewhat different industry representation. They have mainly operators and device manufacturers. They are short on browser representation. Jon: They are also working on device APIs, but there is likely to be a difference there because we are thinking about a JavaScript shim with adapters, whereas they are more likely to specify standard APIs that device manufacturers should implement. Paddy: Yes, they aren't working on the Ajax layer. Paddy: Historically, operators make requests of device manufacturers about what should be embedded on devices. But emphasis now is to prevent duplication and make sure there are no gaps, but still feeling their way. Jon: Makes sense. Krishna: How about a joint paper with OMTP? Jon: Yes and no. Yes, we can definitely collaborate. But we probably can't actually do joint publishing from both organizations simultaneously, if only because of IP policy differences Paddy: By end of year OMTP is shooting for either a precise spec or a real reference implementations Shankar: A real product implementation? Paddy: Can't say at this time. But the spec would be capable of being implementable and will try to get implementations. Other question is browser vendors who are not in OMTP. Jon: Nokia can be a proxy for WebKit. Is Mozilla in OMTP? Arun: Not to my knowledge. Jon: Opera? Paddy: Not to my knowledge (no discussion about MS) Jon: Paddy, you are in both. What do you think we should do on our end? Paddy: I have contributed the same things to both. Caroline is chairing the OMTP effort. So far, the recommendation to OMTP will be aligned with what we have at OpenAjax. But there may be differences ultimately in scope. OMTP has usually given specific security approaches. Jon: Yes, now the vision is aligned, but things might change in the future. How about letting OMTP take the lead for now and we help, and then wait and see how things go? Krishna: That would allow us to focus on other things. If overlap is 50-60%, then yes that would make sense. Paddy: I would be cautious about ceasing activity. OMTP has important constituency, the carriers, but equally there is negligible input from browser manufacturers. And I worry about them being open enough. Jon: Wait and see? Krishna: Might lose some momentum that we now have. Could maybe do a white paper in a couple of months? Jon: Last year we did a major white paper in less than 2 months, so it is possible, but not guaranteed. The mobile white paper has been going on 9 months, is done, but still waiting for me to post it. Paddy: Who is prepared to make the effort? If me, might as well happen in OMTP. Paddy: We could get a liaison statement with OMTP rather than do work here Jon: Nick is trying to get OMTP to join OpenAjax Alliance to help with liaison effort. My thinking is wait and see and then look at what gaps start to emerge Krishna: Yes. Look again in a month or so. Paddy: Yes, that's fair. Shim layer Jon: Now let's talk about the shim layer. Arun: Are people aware of LocationAware from Mozilla? We would like to standardize on ECMA APIs for location Kai: Google Gears location APIs are in the WAF WG (someone): WAF? Not WebAPIs instead of WhatWG? Jon: Shim layer would require lots of contributors. More difficult than a normal Ajax effort because most of the work is in the adapters. Kai: I would be willing to contribute with Aplix WebVM. Maybe I would work with Opera. I'm also kind of interested in Gears. Jon: IBM might contribute, but no approvals at this time. How about Vodafone? Guillermo: Would have to talk but maybe yes with MobileScript source code. Jon: For Windows Mobile and Symbian? Guillermo: Yes, have things working on Windows Mobile and Symbian. One version with SpiderMonkey. Also working on a WebKit version. Jon: We need to make sure we have critical mass. Krishna: Maybe not when we start. People might join once they see things going. Jon: Yes (Kai suggestions about Silverlight and Flex involvement) Jon: Yes, but priority is with Open Web vendors. Arun: We have the Fennec project. Want to explore device APIs. Our vision is web is one platform. Interested in location, also address book. Mozilla now runs on a high-end Nokia device. The LocationAware effort is by the same guy who did Minimo. Kai: We would like to see Mozilla have a plugin API that can be used on an experimental basis. Wrapup Jon: OK, out of time. So, we are moving onto the next phase. Need to have a plan for who/what/when/how for the shim layer. I'll start something on the wiki. I'll ask the chairs for when we will have our next meeting. Maybe next week, maybe the week after. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080515/a2113e49/attachment.html From jferrai at us.ibm.com Fri May 16 13:50:05 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 16 May 2008 13:50:05 -0700 Subject: [OpenAjaxMobile] Location APIs In-Reply-To: <20080515184954.ACB66B8604@dm-mail01.mozilla.org> Message-ID: Hi Arun, Thanks for forwarding the link. I changed the title in case this email might launch a discussion thread, which I will initiate with my own opinions, and hope others offer theirs. My assessment is that Google Gears' location APIs ([1]) attempts to capture every possible bit of information about geolocation that might ever appear and allow for every possible location query scenario that might ever exist. Many kudos to them for attempting to craft a comprehensive set of APIs and attempting to do so within an open community process. The current state of affairs appears to be that the Gears team itself hasn't made up its mind about what the best APIs should be (based on the fact that there is an alternative API section), and there are other proposals in this space. According to [2], we also have JSR179, LocationAware, KDDI, iPhone, Motorola, NTT Docomo, Vodafone MobileScript with their own location APIs. Therefore, it is unclear when and how the industry will unite behind particular APIs, such as what Gears is proposing. (Although the Gears APIs look comprehensive, well-designed, have a big company behind them, and are on a standards track.) Regarding how this affects us, our recent hard work produced (among many other things) a set of Design Principles [3]. The first principle is: ----- Balance scope against usability and time-to-market Focus initially on the 20/80 cases where a more limited set of common features address the most important use cases in order to deliver simplicity and accelerate time-to-market. ----- My feeling is that for our location APIs, we would apply the 20/80 rule, and therefore would design an API that supported only the more typical higher-level scenarios where Ajax developers need to get the devices current location. For example, we might only have a single method (getCurrentLocation()) that returns similar JSON structures as Gears (i.e., lat/long info plus address info), and we certainly wouldn't have anything in the area of cell-tower APIs (such as what Gears has in its alternate proposal). Do people agree that our location APIs should only target a subset of what Gears is trying to address? Jon [1] http://code.google.com/p/google-gears/wiki/LocationAPI [2] http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey [3] http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives#Principles PS. I'm surprised at how quickly the Design Principles became useful. Good work, Nikunj. Arun Ranganathan <"arun"@mozilla.c om> To Sent by: OpenAjax Alliance discussion list mobile-bounces at op on Mobile Ajax enajax.org cc 05/15/08 11:49 AM Subject [OpenAjaxMobile] WHATWG Location API Proposal | Re: RSVP please - Please respond to Can you attend a phonecall arun at mozilla.com; onThursday? Please respond to OpenAjax Alliance discussion list on Mobile Ajax Google Gears propose this to WHATWG: http://code.google.com/p/google-gears/wiki/LocationAPI To WebAPI they proposed their Blob API stuff. -- A* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080516/d22448d5/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/20080516/d22448d5/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic07326.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080516/d22448d5/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/20080516/d22448d5/attachment-0002.gif From jferrai at us.ibm.com Mon May 19 11:39:57 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 19 May 2008 11:39:57 -0700 Subject: [OpenAjaxMobile] Did you mean 'async' instead of 'sync'? (in the white paper) In-Reply-To: <482B5F17.9040105@oracle.com> Message-ID: Hi Nikunj, I have now posted the white paper on our Web site, but I haven't added links from our home page to the white paper or sent out any announcements yet. As I was doing one more careful reading of the white paper, I noticed a section that you added that confused me. White paper: http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php Confusing section: http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php#Design_for_network Within the section on networking, the last bullet used to say "synchronous" but I changed it to "asynchronous" because the text appears to talk about asynchronous techniques. Which should it be, asynchronous or synchronous? Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080519/21f39dd8/attachment.html From jferrai at us.ibm.com Mon May 19 12:37:44 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 19 May 2008 12:37:44 -0700 Subject: [OpenAjaxMobile] Did you mean 'async' instead of 'sync'? (in the white paper) In-Reply-To: <4831D37F.9040708@oracle.com> Message-ID: Hi Nikunj, Thanks! Jon Nikunj Mehta To Jon Ferraiolo/Menlo Park/IBM at IBMUS 05/19/08 12:22 PM cc Subject Re: Did you mean 'async' instead of 'sync'? (in the white paper) Hi Jon, The current heading is correct - it should say apply updates asynchronously where possible. Thanks for catching this. Regards, Nikunj Jon Ferraiolo wrote: > > Hi Nikunj, > I have now posted the white paper on our Web site, but I haven't added > links from our home page to the white paper or sent out any > announcements yet. As I was doing one more careful reading of the > white paper, I noticed a section that you added that confused me. > > White paper: > http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php > Confusing section: > http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php#Design_for_network > > Within the section on networking, the last bullet used to say > "synchronous" but I changed it to "asynchronous" because the text > appears to talk about asynchronous techniques. Which should it be, > asynchronous or synchronous? > > Thanks. > Jon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080519/5d1a507d/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/20080519/5d1a507d/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic21944.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080519/5d1a507d/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/20080519/5d1a507d/attachment-0002.gif From "arun" at mozilla.com Tue May 20 16:53:07 2008 From: "arun" at mozilla.com (Arun Ranganathan) Date: Tue, 20 May 2008 16:53:07 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: References: Message-ID: <20080520235307.9CF19B85FC@dm-mail01.mozilla.org> Apologies, I hit send on this a bit too soon, and only caught the error just now :-) Here's what I intended to say: Jon, > > > The current state of affairs appears to be that the Gears team itself > hasn't made up its mind about what the best APIs should be (based on > the fact that there is an alternative API section), and there are > other proposals in this space. According to [2], we also have JSR179, > And >Do people agree that our location APIs should only target a subset of what Gears is trying to >address? I think whether we start with something like JSR179 (go to Nokia to download the actual JavaDoc)[1] *or* with Google Gears, we have to simplify for what JavaScripters want to do. And in the end, I'm not so sure how we can get a handle on this moving location API train but simplification is always good :-) I also agree with the design principles in general. I took a look at JSR179 [1], since I think that when crafting ECMAScript APIs, we should be informed by what came in the past, and in general I think developers will appreciate the due diligence in giving them primitives, objects, and methods that they've seen before. I just worry that it's a bit too complicated for the Web. For instance, within the JSR 179 proposal[1], you have both a Location.* interface and a Coordinates.* interface; the former's chief use is for obtaining address, and the latter gives us a quick way to get at longitude and latitude. But Google Gears[2] gets at the latitude and longitude much more easily via a callback function as a parameter to the main object (featuring asynchronous calls as a goal); this approach is also shared by the nascent LocationAware work. [3] Also: >For example, we might only have a single method (getCurrentLocation()) that returns similar >JSON structures as Gears (i.e., lat/long info plus address info), and we certainly wouldn't have >anything in the area of cell-tower APIs (such as what Gears has in its alternate proposal). Do you mean, JSON structures if we interact with a location provide that is possibly remote? If so, I like the Gears approach of using POST with structures that match the basic interface, such as Address. - A* [1] http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI [3] http://locationaware.org/wiki/Working_Draft From dougt at mozilla.com Tue May 20 19:54:22 2008 From: dougt at mozilla.com (Doug Turner) Date: Tue, 20 May 2008 19:54:22 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: <20080520235307.9CF19B85FC@dm-mail01.mozilla.org> References: <20080520235307.9CF19B85FC@dm-mail01.mozilla.org> Message-ID: Adding optional reverse geolocation(street address, zip codes, ect.) information in the spec may just confuse the web developer. Consider the simple case -- a site wants to serve up location specific content to a user. In the code, the developer is going to not only have to handle the case where a street address or zip code is provided, but also the default case where only a lat-long is provided. Since in the default case must be handled and in handling this default case, you will aquire all of the information that the reverse geolocation provided, i wonder why even bother having a special case. Example: var geo = google.gears.factory.create('beta.geolocation'); geo.getCurrentPosition(function(position) { if (position.address != null) //special case { // great!! i can use address.postalCode ... } else // default case { // ugh, i have to do something to provide postalcode to the rest of my application ... } }); Having everyone speak the same location language feels like the right thing; and that dialect is lat+longs. Of course, I can understand the ease-of-use of getting back a street address or zip code. Many datasets of corporations probably already speak zipcodes and providing that information in the geo location object may spark quick adoption. However, I am not sure what we can do for places in the world that do not speak streets or zip codes. Nor do I want a geolocation object that has dozens of properties that will further confuse the web developer. Regards, Doug Turner On May 20, 2008, at 4:53 PM, Arun Ranganathan wrote: > Apologies, I hit send on this a bit too soon, and only caught the > error just now :-) > > Here's what I intended to say: > > Jon, >> >> >> The current state of affairs appears to be that the Gears team >> itself hasn't made up its mind about what the best APIs should be >> (based on the fact that there is an alternative API section), and >> there are other proposals in this space. According to [2], we also >> have JSR179, >> > > > And > > >Do people agree that our location APIs should only target a subset > of what Gears is trying to >address? > > > I think whether we start with something like JSR179 (go to Nokia to > download the actual JavaDoc)[1] *or* with Google Gears, we have to > simplify for what JavaScripters want to do. And in the end, I'm not > so sure how we can get a handle on this moving location API train > but simplification is always good :-) I also agree with the design > principles in general. > > I took a look at JSR179 [1], since I think that when crafting > ECMAScript APIs, we should be informed by what came in the past, and > in general I think developers will appreciate the due diligence in > giving them primitives, objects, and methods that they've seen > before. I just worry that it's a bit too complicated for the Web. > > For instance, within the JSR 179 proposal[1], you have both a > Location.* interface and a Coordinates.* interface; the former's > chief use is for obtaining address, and the latter gives us a quick > way to get at longitude and latitude. But Google Gears[2] gets at > the latitude and longitude much more easily via a callback function > as a parameter to the main object (featuring asynchronous calls as a > goal); this approach is also shared by the nascent LocationAware > work. [3] > > Also: > > >For example, we might only have a single method > (getCurrentLocation()) that returns similar >JSON structures as > Gears (i.e., lat/long info plus address info), and we certainly > wouldn't have >anything in the area of cell-tower APIs (such as what > Gears has in its alternate proposal). > > > Do you mean, JSON structures if we interact with a location provide > that is possibly remote? If so, I like the Gears approach of using > POST with structures that match the basic interface, such as Address. > - A* > > [1] http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html > > [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI > > [3] http://locationaware.org/wiki/Working_Draft From jferrai at us.ibm.com Wed May 21 08:55:58 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 21 May 2008 08:55:58 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: Message-ID: Good discussion! I'm not a location-based application expert, but here is what my common sense tells me. (1) Yes, lat/long is the key thing to return in the context of getCurrentLocation() (2) But why not have the return value contains both lat/long and address information (if that can be determined), similar to what Gears returns. The application can then choose to use either the lat/long information or the address information. It would be OK if the address field were empty and only lat/long were returned - the developer would just have to deal with it. Jon Doug Turner To arun at mozilla.com 05/20/08 07:54 PM cc Jon Ferraiolo/Menlo Park/IBM at IBMUS, mobile at openajax.org Subject Re: Resend | Re: Location APIs Adding optional reverse geolocation(street address, zip codes, ect.) information in the spec may just confuse the web developer. Consider the simple case -- a site wants to serve up location specific content to a user. In the code, the developer is going to not only have to handle the case where a street address or zip code is provided, but also the default case where only a lat-long is provided. Since in the default case must be handled and in handling this default case, you will aquire all of the information that the reverse geolocation provided, i wonder why even bother having a special case. Example: var geo = google.gears.factory.create('beta.geolocation'); geo.getCurrentPosition(function(position) { if (position.address != null) //special case { // great!! i can use address.postalCode ... } else // default case { // ugh, i have to do something to provide postalcode to the rest of my application ... } }); Having everyone speak the same location language feels like the right thing; and that dialect is lat+longs. Of course, I can understand the ease-of-use of getting back a street address or zip code. Many datasets of corporations probably already speak zipcodes and providing that information in the geo location object may spark quick adoption. However, I am not sure what we can do for places in the world that do not speak streets or zip codes. Nor do I want a geolocation object that has dozens of properties that will further confuse the web developer. Regards, Doug Turner On May 20, 2008, at 4:53 PM, Arun Ranganathan wrote: > Apologies, I hit send on this a bit too soon, and only caught the > error just now :-) > > Here's what I intended to say: > > Jon, >> >> >> The current state of affairs appears to be that the Gears team >> itself hasn't made up its mind about what the best APIs should be >> (based on the fact that there is an alternative API section), and >> there are other proposals in this space. According to [2], we also >> have JSR179, >> > > > And > > >Do people agree that our location APIs should only target a subset > of what Gears is trying to >address? > > > I think whether we start with something like JSR179 (go to Nokia to > download the actual JavaDoc)[1] *or* with Google Gears, we have to > simplify for what JavaScripters want to do. And in the end, I'm not > so sure how we can get a handle on this moving location API train > but simplification is always good :-) I also agree with the design > principles in general. > > I took a look at JSR179 [1], since I think that when crafting > ECMAScript APIs, we should be informed by what came in the past, and > in general I think developers will appreciate the due diligence in > giving them primitives, objects, and methods that they've seen > before. I just worry that it's a bit too complicated for the Web. > > For instance, within the JSR 179 proposal[1], you have both a > Location.* interface and a Coordinates.* interface; the former's > chief use is for obtaining address, and the latter gives us a quick > way to get at longitude and latitude. But Google Gears[2] gets at > the latitude and longitude much more easily via a callback function > as a parameter to the main object (featuring asynchronous calls as a > goal); this approach is also shared by the nascent LocationAware > work. [3] > > Also: > > >For example, we might only have a single method > (getCurrentLocation()) that returns similar >JSON structures as > Gears (i.e., lat/long info plus address info), and we certainly > wouldn't have >anything in the area of cell-tower APIs (such as what > Gears has in its alternate proposal). > > > Do you mean, JSON structures if we interact with a location provide > that is possibly remote? If so, I like the Gears approach of using > POST with structures that match the basic interface, such as Address. > - A* > > [1] http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html > > [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI > > [3] http://locationaware.org/wiki/Working_Draft -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080521/3ef5ac0e/attachment-0001.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/20080521/3ef5ac0e/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic18247.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080521/3ef5ac0e/attachment-0004.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/20080521/3ef5ac0e/attachment-0005.gif From dougt at mozilla.com Wed May 21 09:50:46 2008 From: dougt at mozilla.com (Doug Turner) Date: Wed, 21 May 2008 09:50:46 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: References: Message-ID: Hi Jon, I think I address (2) in my response. Stepping back a bit, the most basic device that can give location information is GPS. It does not require any third party to be in involved. It simply writes out lats and longs to a serial bus. Other devices like operator LBS and Wifi- >Location services can do similar, plus they can provide address information. So, for some set of users they will only have access to a GPS, and another set will have access to something like a GPS but will also provide addressing information. Now, if I asked you to go write some code for a webpage to determine where a person is, you are going to have to create a code path for people that have addresses in their location information, and a fallback case for those that do not. Since you are already having to create this fallback case where you are having to deal with lats and longs, my position is to simple not provide this address in the API. Doug On May 21, 2008, at 8:55 AM, Jon Ferraiolo wrote: > Good discussion! > > I'm not a location-based application expert, but here is what my > common sense tells me. > > (1) Yes, lat/long is the key thing to return in the context of > getCurrentLocation() > (2) But why not have the return value contains both lat/long and > address information (if that can be determined), similar to what > Gears returns. The application can then choose to use either the lat/ > long information or the address information. It would be OK if the > address field were empty and only lat/long were returned - the > developer would just have to deal with it. > > Jon > > > Doug Turner > > > Doug Turner > 05/20/08 07:54 PM > > > To > > arun at mozilla.com > > cc > > Jon Ferraiolo/Menlo Park/IBM at IBMUS, mobile at openajax.org > > Subject > > Re: Resend | Re: Location APIs > > > > Adding optional reverse geolocation(street address, zip codes, ect.) > information in the spec may just confuse the web developer. Consider > the simple case -- a site wants to serve up location specific content > to a user. In the code, the developer is going to not only have to > handle the case where a street address or zip code is provided, but > also the default case where only a lat-long is provided. Since in the > default case must be handled and in handling this default case, you > will aquire all of the information that the reverse geolocation > provided, i wonder why even bother having a special case. > > Example: > > var geo = google.gears.factory.create('beta.geolocation'); > > geo.getCurrentPosition(function(position) { > > if (position.address != null) //special case > { > // great!! i can use address.postalCode > ... > } > else // default case > { > // ugh, i have to do something to provide postalcode to the rest of > my application > ... > } > > }); > > > Having everyone speak the same location language feels like the right > thing; and that dialect is lat+longs. > > Of course, I can understand the ease-of-use of getting back a street > address or zip code. Many datasets of corporations probably already > speak zipcodes and providing that information in the geo location > object may spark quick adoption. However, I am not sure what we can > do for places in the world that do not speak streets or zip codes. > Nor do I want a geolocation object that has dozens of properties that > will further confuse the web developer. > > Regards, > Doug Turner > > > > On May 20, 2008, at 4:53 PM, Arun Ranganathan wrote: > > > Apologies, I hit send on this a bit too soon, and only caught the > > error just now :-) > > > > Here's what I intended to say: > > > > Jon, > >> > >> > >> The current state of affairs appears to be that the Gears team > >> itself hasn't made up its mind about what the best APIs should be > >> (based on the fact that there is an alternative API section), and > >> there are other proposals in this space. According to [2], we also > >> have JSR179, > >> > > > > > > And > > > > >Do people agree that our location APIs should only target a subset > > of what Gears is trying to >address? > > > > > > I think whether we start with something like JSR179 (go to Nokia to > > download the actual JavaDoc)[1] *or* with Google Gears, we have to > > simplify for what JavaScripters want to do. And in the end, I'm not > > so sure how we can get a handle on this moving location API train > > but simplification is always good :-) I also agree with the design > > principles in general. > > > > I took a look at JSR179 [1], since I think that when crafting > > ECMAScript APIs, we should be informed by what came in the past, and > > in general I think developers will appreciate the due diligence in > > giving them primitives, objects, and methods that they've seen > > before. I just worry that it's a bit too complicated for the Web. > > > > For instance, within the JSR 179 proposal[1], you have both a > > Location.* interface and a Coordinates.* interface; the former's > > chief use is for obtaining address, and the latter gives us a quick > > way to get at longitude and latitude. But Google Gears[2] gets at > > the latitude and longitude much more easily via a callback function > > as a parameter to the main object (featuring asynchronous calls as a > > goal); this approach is also shared by the nascent LocationAware > > work. [3] > > > > Also: > > > > >For example, we might only have a single method > > (getCurrentLocation()) that returns similar >JSON structures as > > Gears (i.e., lat/long info plus address info), and we certainly > > wouldn't have >anything in the area of cell-tower APIs (such as what > > Gears has in its alternate proposal). > > > > > > Do you mean, JSON structures if we interact with a location provide > > that is possibly remote? If so, I like the Gears approach of using > > POST with structures that match the basic interface, such as > Address. > > - A* > > > > [1] http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html > > > > [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI > > > > [3] http://locationaware.org/wiki/Working_Draft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080521/bdf43de2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pic02060.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080521/bdf43de2/attachment.gif From "arun" at mozilla.com Wed May 21 11:33:18 2008 From: "arun" at mozilla.com (Arun Ranganathan) Date: Wed, 21 May 2008 11:33:18 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: References: Message-ID: <20080521183320.7B4D4B8601@dm-mail01.mozilla.org> Jon, When coining new browser primitives exposed at the same level as DOM stuff, we essentially go with the simplest thing that developers can do that won't break the web and that are possibly exposed on the given device. You'll notice that there's plenty of scope for more nuanced APIs on top of our primitive stack, and this has contributed for much of the boom on the web for third party encapsulations around basic browser primitives (Dojo, Prototype, jQuery, etc.). I'm with Ryan S and Doug T on this one -- latitude/longitude is the basic thing we *should* expose. These can be used with other services and providers (example: Google Maps) to obtain address information or proximity information based on latitude and longitude. We should also provide something akin to JSR179's "QualifiedCoordinates" object which returns latitude and longitude with percentage error (e.g. plus/minus 30 feet). The GoogleGears approach takes this into account by providing a float offset for accuracy. The browser will eventually have a sufficient number of DOM-level primitives such as postMessage and XS-XHR that will enable pretty straightforward interaction with remote service providers for data such as location. At that stage, spec'ing out a uniform JSON API such as the kind you mentioned might be helpful for addresses -- e.g. a JSON struct containing variations for US and international addresses. I've always been a fan of some kind of standardization across verticals (e.g. "mapping" or "feeds") in lieu of company-wide APIs (e.g. "Google APIs" or "Yahoo APIs"). The first task at hand, however, is to agree on some basic primitives for browsers on various devices :-) Jon Ferraiolo wrote: > > Good discussion! > > I'm not a location-based application expert, but here is what my > common sense tells me. > > (1) Yes, lat/long is the key thing to return in the context of > getCurrentLocation() > (2) But why not have the return value contains both lat/long and > address information (if that can be determined), similar to what Gears > returns. The application can then choose to use either the lat/long > information or the address information. It would be OK if the address > field were empty and only lat/long were returned - the developer would > just have to deal with it. > > Jon > > > Inactive hide details for Doug Turner Doug Turner > > > > *Doug Turner * > > 05/20/08 07:54 PM > > > > To > > arun at mozilla.com > > cc > > Jon Ferraiolo/Menlo Park/IBM at IBMUS, mobile at openajax.org > > Subject > > Re: Resend | Re: Location APIs > > > > > > Adding optional reverse geolocation(street address, zip codes, ect.) > information in the spec may just confuse the web developer. Consider > the simple case -- a site wants to serve up location specific content > to a user. In the code, the developer is going to not only have to > handle the case where a street address or zip code is provided, but > also the default case where only a lat-long is provided. Since in the > default case must be handled and in handling this default case, you > will aquire all of the information that the reverse geolocation > provided, i wonder why even bother having a special case. > > Example: > > var geo = google.gears.factory.create('beta.geolocation'); > > geo.getCurrentPosition(function(position) { > > if (position.address != null) //special case > { > // great!! i can use address.postalCode > ... > } > else // default case > { > // ugh, i have to do something to provide postalcode to the rest of > my application > ... > } > > }); > > > Having everyone speak the same location language feels like the right > thing; and that dialect is lat+longs. > > Of course, I can understand the ease-of-use of getting back a street > address or zip code. Many datasets of corporations probably already > speak zipcodes and providing that information in the geo location > object may spark quick adoption. However, I am not sure what we can > do for places in the world that do not speak streets or zip codes. > Nor do I want a geolocation object that has dozens of properties that > will further confuse the web developer. > > Regards, > Doug Turner > > > > On May 20, 2008, at 4:53 PM, Arun Ranganathan wrote: > > > Apologies, I hit send on this a bit too soon, and only caught the > > error just now :-) > > > > Here's what I intended to say: > > > > Jon, > >> > >> > >> The current state of affairs appears to be that the Gears team > >> itself hasn't made up its mind about what the best APIs should be > >> (based on the fact that there is an alternative API section), and > >> there are other proposals in this space. According to [2], we also > >> have JSR179, > >> > > > > > > And > > > > >Do people agree that our location APIs should only target a subset > > of what Gears is trying to >address? > > > > > > I think whether we start with something like JSR179 (go to Nokia to > > download the actual JavaDoc)[1] *or* with Google Gears, we have to > > simplify for what JavaScripters want to do. And in the end, I'm not > > so sure how we can get a handle on this moving location API train > > but simplification is always good :-) I also agree with the design > > principles in general. > > > > I took a look at JSR179 [1], since I think that when crafting > > ECMAScript APIs, we should be informed by what came in the past, and > > in general I think developers will appreciate the due diligence in > > giving them primitives, objects, and methods that they've seen > > before. I just worry that it's a bit too complicated for the Web. > > > > For instance, within the JSR 179 proposal[1], you have both a > > Location.* interface and a Coordinates.* interface; the former's > > chief use is for obtaining address, and the latter gives us a quick > > way to get at longitude and latitude. But Google Gears[2] gets at > > the latitude and longitude much more easily via a callback function > > as a parameter to the main object (featuring asynchronous calls as a > > goal); this approach is also shared by the nascent LocationAware > > work. [3] > > > > Also: > > > > >For example, we might only have a single method > > (getCurrentLocation()) that returns similar >JSON structures as > > Gears (i.e., lat/long info plus address info), and we certainly > > wouldn't have >anything in the area of cell-tower APIs (such as what > > Gears has in its alternate proposal). > > > > > > Do you mean, JSON structures if we interact with a location provide > > that is possibly remote? If so, I like the Gears approach of using > > POST with structures that match the basic interface, such as Address. > > - A* > > > > [1] > http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html > > > > [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI > > > > [3] http://locationaware.org/wiki/Working_Draft > > From aza at mozilla.com Wed May 21 15:16:40 2008 From: aza at mozilla.com (Aza) Date: Wed, 21 May 2008 15:16:40 -0700 Subject: [OpenAjaxMobile] Resend | Re: Location APIs In-Reply-To: <3A1EDC8A-0D58-4735-BCD8-242D167DF63D@skyhookwireless.com> References: <20080521183320.7B4D4B8601@dm-mail01.mozilla.org> <3A1EDC8A-0D58-4735-BCD8-242D167DF63D@skyhookwireless.com> Message-ID: Hi All, I'm getting ready to blog about the next iteration -- given the feedback I got last time -- of where I've been pushing the LocationAware API. The cool thing this time around is that I have a working mock-library, so that we can get folks to start playing with the API even before it is integrated into the browser. http://code.google.com/p/geolocation-firefox/ I am still undecided about the geocoding part. I am swayed by the keep-it-uber-simple side of things (following the XmlHttpRequest precedent). I am also swayed, as a content creator, by the ease of having geocoding included, so that my site doesn't have to do yet-another Ajax request. Because of that, I've set up the API to be gracefully upgradable, so that we can start without geocoding, and add it in later without breaking any code in the process. http://geolocation-firefox.googlecode.com/svn/trunk/MockGeolocation.js http://geolocation-firefox.googlecode.com/svn/trunk/MockGeolocationWithAddress.js You can see it in action here: http://geolocation-firefox.googlecode.com/svn/trunk/MockGeolocation.html -- Aza On Wed, May 21, 2008 at 1:21 PM, Ryan Sarver wrote: > Arun, > > Sorry, I should have also specified that an "accuracy", or also known as > "hpe" (horizontal positioning error) in the GPS world, should also be > returned with the lat/lon. > > best, rs > > > On May 21, 2008, at 2:33 PM, Arun Ranganathan wrote: > > Jon, >> >> When coining new browser primitives exposed at the same level as DOM >> stuff, we essentially go with the simplest thing that developers can do that >> won't break the web and that are possibly exposed on the given device. >> You'll notice that there's plenty of scope for more nuanced APIs on top of >> our primitive stack, and this has contributed for much of the boom on the >> web for third party encapsulations around basic browser primitives (Dojo, >> Prototype, jQuery, etc.). >> >> I'm with Ryan S and Doug T on this one -- latitude/longitude is the basic >> thing we *should* expose. These can be used with other services and >> providers (example: Google Maps) to obtain address information or proximity >> information based on latitude and longitude. We should also provide >> something akin to JSR179's "QualifiedCoordinates" object which returns >> latitude and longitude with percentage error (e.g. plus/minus 30 feet). The >> GoogleGears approach takes this into account by providing a float offset for >> accuracy. >> >> The browser will eventually have a sufficient number of DOM-level >> primitives such as postMessage and XS-XHR that will enable pretty >> straightforward interaction with remote service providers for data such as >> location. At that stage, spec'ing out a uniform JSON API such as the kind >> you mentioned might be helpful for addresses -- e.g. a JSON struct >> containing variations for US and international addresses. I've always been >> a fan of some kind of standardization across verticals (e.g. "mapping" or >> "feeds") in lieu of company-wide APIs (e.g. "Google APIs" or "Yahoo APIs"). >> The first task at hand, however, is to agree on some basic primitives for >> browsers on various devices :-) >> >> >> Jon Ferraiolo wrote: >> >>> >>> Good discussion! >>> >>> I'm not a location-based application expert, but here is what my common >>> sense tells me. >>> >>> (1) Yes, lat/long is the key thing to return in the context of >>> getCurrentLocation() >>> (2) But why not have the return value contains both lat/long and address >>> information (if that can be determined), similar to what Gears returns. The >>> application can then choose to use either the lat/long information or the >>> address information. It would be OK if the address field were empty and only >>> lat/long were returned - the developer would just have to deal with it. >>> >>> Jon >>> >>> >>> Inactive hide details for Doug Turner Doug Turner < >>> dougt at mozilla.com> >>> >>> >>> *Doug Turner * >>> >>> 05/20/08 07:54 PM >>> >>> >>> >>> To >>> >>> arun at mozilla.com >>> >>> cc >>> >>> Jon Ferraiolo/Menlo Park/IBM at IBMUS, mobile at openajax.org >>> >>> Subject >>> >>> Re: Resend | Re: Location APIs >>> >>> >>> >>> >>> >>> Adding optional reverse geolocation(street address, zip codes, ect.) >>> information in the spec may just confuse the web developer. Consider the >>> simple case -- a site wants to serve up location specific content to a >>> user. In the code, the developer is going to not only have to handle the >>> case where a street address or zip code is provided, but also the default >>> case where only a lat-long is provided. Since in the default case must be >>> handled and in handling this default case, you will aquire all of the >>> information that the reverse geolocation provided, i wonder why even bother >>> having a special case. >>> >>> Example: >>> >>> var geo = google.gears.factory.create('beta.geolocation'); >>> >>> geo.getCurrentPosition(function(position) { >>> >>> if (position.address != null) //special case >>> { >>> // great!! i can use address.postalCode >>> ... >>> } >>> else // default case >>> { >>> // ugh, i have to do something to provide postalcode to the rest of my >>> application >>> ... >>> } >>> >>> }); >>> >>> >>> Having everyone speak the same location language feels like the right >>> thing; and that dialect is lat+longs. >>> >>> Of course, I can understand the ease-of-use of getting back a street >>> address or zip code. Many datasets of corporations probably already speak >>> zipcodes and providing that information in the geo location object may >>> spark quick adoption. However, I am not sure what we can do for places in >>> the world that do not speak streets or zip codes. Nor do I want a >>> geolocation object that has dozens of properties that will further confuse >>> the web developer. >>> >>> Regards, >>> Doug Turner >>> >>> >>> >>> On May 20, 2008, at 4:53 PM, Arun Ranganathan wrote: >>> >>> > Apologies, I hit send on this a bit too soon, and only caught the > >>> error just now :-) >>> > >>> > Here's what I intended to say: >>> > >>> > Jon, >>> >> >>> >> >>> >> The current state of affairs appears to be that the Gears team >> >>> itself hasn't made up its mind about what the best APIs should be >> (based >>> on the fact that there is an alternative API section), and >> there are >>> other proposals in this space. According to [2], we also >> have JSR179, >>> >> >>> > >>> > >>> > And >>> > >>> > >Do people agree that our location APIs should only target a subset > >>> of what Gears is trying to >address? >>> > >>> > >>> > I think whether we start with something like JSR179 (go to Nokia to > >>> download the actual JavaDoc)[1] *or* with Google Gears, we have to > >>> simplify for what JavaScripters want to do. And in the end, I'm not > so >>> sure how we can get a handle on this moving location API train > but >>> simplification is always good :-) I also agree with the design > >>> principles in general. >>> > >>> > I took a look at JSR179 [1], since I think that when crafting > >>> ECMAScript APIs, we should be informed by what came in the past, and > in >>> general I think developers will appreciate the due diligence in > giving >>> them primitives, objects, and methods that they've seen > before. I just >>> worry that it's a bit too complicated for the Web. >>> > >>> > For instance, within the JSR 179 proposal[1], you have both a > >>> Location.* interface and a Coordinates.* interface; the former's > chief >>> use is for obtaining address, and the latter gives us a quick > way to get >>> at longitude and latitude. But Google Gears[2] gets at > the latitude and >>> longitude much more easily via a callback function > as a parameter to the >>> main object (featuring asynchronous calls as a > goal); this approach is >>> also shared by the nascent LocationAware > work. [3] >>> > >>> > Also: >>> > >>> > >For example, we might only have a single method > >>> (getCurrentLocation()) that returns similar >JSON structures as > Gears >>> (i.e., lat/long info plus address info), and we certainly > wouldn't have >>> >anything in the area of cell-tower APIs (such as what > Gears has in its >>> alternate proposal). >>> > >>> > >>> > Do you mean, JSON structures if we interact with a location provide > >>> that is possibly remote? If so, I like the Gears approach of using > POST >>> with structures that match the basic interface, such as Address. >>> > - A* >>> > >>> > [1] >>> http://www.forum.nokia.com/info/sw.nokia.com/id/56a9a94a-ab11-4f6a-84c4-4ee7ada2a7e8.html >>> > >>> > [2] http://code.google.com/p/google-gears/wiki/GeolocationAPI >>> > >>> > [3] http://locationaware.org/wiki/Working_Draft >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080521/5250feed/attachment.html From Andrew.Sledd at ikivo.com Tue May 27 10:33:47 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Tue, 27 May 2008 19:33:47 +0200 Subject: [OpenAjaxMobile] OAA Mobile Task Force Conference Call Invitation Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDD3EB1A@SESTHSRV10.zoomon.local> Hi all, PLEASE REPLY to andrew.sledd at ikivo.com if you will attend. I know it's short notice so I would like to ask for a show of hands on who can attend. Agenda proposal Review Status of TF deliverables (10 min) Next steps API Next steps Shim Andy, co-chair Mobile TF --------- Tuesday May 6 8amPT, 11amET, 4pm London, 5pm Paris 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 ________________________________________________ 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 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/20080527/0a7db99f/attachment.html From jferrai at us.ibm.com Thu May 29 09:02:51 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 29 May 2008 09:02:51 -0700 Subject: [OpenAjaxMobile] Anyone having trouble getting into the phone call today? Message-ID: An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080529/1f129df6/attachment.html From arun at mozilla.com Thu May 29 09:14:49 2008 From: arun at mozilla.com (Arun Ranganathan) Date: Thu, 29 May 2008 09:14:49 -0700 Subject: [OpenAjaxMobile] Anyone having trouble getting into the phone call today? In-Reply-To: References: Message-ID: <483ED679.9090106@mozilla.com> Greetings Jon et al., I send my belated regrets for today's call. I won't be able to attend. -- A* Jon Ferraiolo wrote: > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From ksankar at cisco.com Thu May 29 10:03:55 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Thu, 29 May 2008 10:03:55 -0700 Subject: [OpenAjaxMobile] Anyone having trouble getting into the phone calltoday? In-Reply-To: References: Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A04D3AE20@xmb-sjc-219.amer.cisco.com> Didn't see one. Possibly I missed the e-mail. Anyway am on the road. Cheers ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Jon Ferraiolo Sent: Thursday, May 29, 2008 9:03 AM To: mobile at openajax.org Subject: [OpenAjaxMobile] Anyone having trouble getting into the phone calltoday? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080529/06d252a9/attachment.html From Andrew.Sledd at ikivo.com Mon Jun 2 14:12:04 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Mon, 2 Jun 2008 23:12:04 +0200 Subject: [OpenAjaxMobile] Invitation: Conf call Thursday June 5 Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDD3F288@SESTHSRV10.zoomon.local> Hi all, Reminder to join in the Mobile Task Force conf call this week on Thursday. We canceled last weeks call due to limited availability of participants. Agenda proposal Review Status of TF deliverables (10 min) Next steps API Next steps Shim Andy, co-chair Mobile TF 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 [edit ] IRC channel * IRC channel: irc.freenode.net, #oaa-mobile * Free online IRC client: 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 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/20080602/6f9262b3/attachment.html From arun at mozilla.com Mon Jun 2 14:16:38 2008 From: arun at mozilla.com (Arun Ranganathan) Date: Mon, 02 Jun 2008 17:16:38 -0400 Subject: [OpenAjaxMobile] Invitation: Conf call Thursday June 5 In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD3F288@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDD3F288@SESTHSRV10.zoomon.local> Message-ID: <48446336.1060305@mozilla.com> Hi OpenAjax Listserv, I'm traveling for business that time, and will be unable to attend. -- A* Andrew Sledd wrote: > Hi all, > > Reminder to join in the Mobile Task Force conf call this week on > Thursday. We canceled last weeks call due to limited availability of > participants. > > Agenda proposal > Review Status of TF deliverables (10 min) > Next steps API > Next steps Shim > > Andy, co-chair Mobile TF > > > *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 > > [_edit_ > ] > *IRC channel * > > o IRC channel: irc.freenode.net, #oaa-mobile > o Free online IRC client: _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 * > > ** > > > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From Andrew.Sledd at ikivo.com Mon Jun 2 14:24:09 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Mon, 2 Jun 2008 23:24:09 +0200 Subject: [OpenAjaxMobile] Update RE: Invitation: Conf call Thursday June 5 In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD3F288@SESTHSRV10.zoomon.local> Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDD3F28A@SESTHSRV10.zoomon.local> Same time and place. Sorry forgot to confirm that in the previous mail. 9amPT, noonET, 5pm London, 6pm Paris ________________________________ From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Andrew Sledd Sent: den 2 juni 2008 23:12 To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] Invitation: Conf call Thursday June 5 Hi all, Reminder to join in the Mobile Task Force conf call this week on Thursday. We canceled last weeks call due to limited availability of participants. Agenda proposal Review Status of TF deliverables (10 min) Next steps API Next steps Shim Andy, co-chair Mobile TF 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 [edit ] IRC channel * IRC channel: irc.freenode.net, #oaa-mobile * Free online IRC client: 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 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/20080602/5ed67bff/attachment-0001.html From nikunj.mehta at oracle.com Mon Jun 2 14:32:32 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Mon, 02 Jun 2008 14:32:32 -0700 Subject: [OpenAjaxMobile] Update RE: Invitation: Conf call Thursday June 5 In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD3F28A@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDD3F28A@SESTHSRV10.zoomon.local> Message-ID: <484466F0.1070605@oracle.com> I will join the call. Nikunj Andrew Sledd wrote: > Same time and place. Sorry forgot to confirm that in the previous mail. > > 9amPT, noonET, 5pm London, 6pm Paris > > ------------------------------------------------------------------------ > *From:* mobile-bounces at openajax.org > [mailto:mobile-bounces at openajax.org] *On Behalf Of *Andrew Sledd > *Sent:* den 2 juni 2008 23:12 > *To:* OpenAjax Alliance discussion list on Mobile Ajax > *Subject:* [OpenAjaxMobile] Invitation: Conf call Thursday June 5 > > Hi all, > > Reminder to join in the Mobile Task Force conf call this week on > Thursday. We canceled last weeks call due to limited availability of > participants. > > Agenda proposal > Review Status of TF deliverables (10 min) > Next steps API > Next steps Shim > > Andy, co-chair Mobile TF > > > *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 > > [_edit_ > ] > *IRC channel * > > o IRC channel: irc.freenode.net, #oaa-mobile > o Free online IRC client: _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 * > > ** > > > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From paddy.byers at gmail.com Tue Jun 3 01:57:32 2008 From: paddy.byers at gmail.com (Paddy Byers) Date: Tue, 3 Jun 2008 09:57:32 +0100 Subject: [OpenAjaxMobile] Update RE: Invitation: Conf call Thursday June 5 In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD3F28A@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDD3F288@SESTHSRV10.zoomon.local> <234EB4699C751A4A95DF4FD8D041BBFDD3F28A@SESTHSRV10.zoomon.local> Message-ID: <59db1b5a0806030157n72f0da98h3c65bf0cba2a27a5@mail.gmail.com> Hi, Sorry for recent absences, I will be there. Paddy On Mon, Jun 2, 2008 at 10:24 PM, Andrew Sledd wrote: > Same time and place. Sorry forgot to confirm that in the previous mail. > > 9amPT, noonET, 5pm London, 6pm Paris > > ------------------------------ > *From:* mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] *On > Behalf Of *Andrew Sledd > *Sent:* den 2 juni 2008 23:12 > *To:* OpenAjax Alliance discussion list on Mobile Ajax > *Subject:* [OpenAjaxMobile] Invitation: Conf call Thursday June 5 > > Hi all, > > Reminder to join in the Mobile Task Force conf call this week on Thursday. > We canceled last weeks call due to limited availability of participants. > > Agenda proposal > Review Status of TF deliverables (10 min) > Next steps API > Next steps Shim > > Andy, co-chair Mobile TF > > > *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 > > [*edit* > ] > *IRC channel * > > - IRC channel: irc.freenode.net, #oaa-mobile > - Free online IRC client: *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* > > ** > > > 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. > > > _______________________________________________ > 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/20080603/ab99150f/attachment-0001.html From jferrai at us.ibm.com Wed Jun 4 16:38:03 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 4 Jun 2008 16:38:03 -0700 Subject: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video calling overlooked? In-Reply-To: Message-ID: Is video calling captured on our requirements list? Jon "Scott, Andrew E" wrote on 06/04/2008 04:00:41 PM: > Hi Jon. > > It should be fine to forward the email. > > Thanks for this. I'm glad to hear that it's not being intentionally left out. > > Andrew Scott > > > From: Jon Ferraiolo > Sent: Thursday, 5 June 2008 1:19 AM > To: Scott, Andrew E > Subject: Re: OpenAjax Mobile Task Force - Video calling overlooked? > Hi Andrew, > Good observation! I don't know if the people who worked on the > requirements list just plain forgot about video calling or whether > they were thinking it was a feature of audio calling. > > Is it OK to forward this to mobile at openajax.org? I can also create > an email from scratch that asks about video calling. > > In terms of whether we will support video calling, I guess the > answer is yes. I believe our intent is to provide APIs for commonly > useful things. The question is more about when rather than if. > According to recent discussion, we are planning to pursue some APIs > right away to get something working and then add other APIs over the > course of time. > > Jon > > > > > Hi Jon. > > I hope that you can assist me. > > I was looking at the OpenAjax Alliance mobile device API > requirements, and on first glance it appears that an obvious one has > been missed: video calling. > > The only calling requirements listed for device service APIs on this page > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > are captured under "voice". There is no mention of video calling > (despite this capability being on the vast majority of new 3G phones). > > Could I please confirm that video calling is intended to be captured > under the voice calling requirements? > > Andrew Scott > Emerging Technology Manager, Telstra Chief Technology Office -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080604/f8f58278/attachment.html From rotan.hanrahan at mobileaware.com Thu Jun 5 02:46:47 2008 From: rotan.hanrahan at mobileaware.com (Rotan Hanrahan) Date: Thu, 5 Jun 2008 05:46:47 -0400 Subject: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video callingoverlooked? References: Message-ID: While I can imagine a typical call that has audio and no video, I cannot imagine a typical call that has video but no audio (notwithstanding the use-case of mobile interaction between hearing-challenged users). Consequently, it's probably not a problem to consider video calling as a specialised form of voice calling, insofar as it is voice augmented with video. Still, it might be a good idea to change the section title from "Voice" to "Calls", as that covers all grounds. I wonder if there's a case then for controlling what is advertised by a device for the purpose of accepting calls? For example, should the API permit my video-enabled device to be set to accept only voice calls? (We all know the use-case of being somewhere where video might be inappropriate.) If so, then the API may need to be extended to facilitate such control. Maybe this would come under the heading of Indicators, as part of "presence" (which is also missing from the list). ---Rotan. PS On the matter of Geo-location (already mentioned in the requirements) you should note the following: http://lists.w3.org/Archives/Public/public-geolocation/ which (afaik) is the only public hint that W3C is about to embark on this issue. Feel free to contact me privately and I'll direct you to the people behind the scenes. If your company is in the W3C, ask your AC Rep for details. ________________________________ From: mobile-bounces at openajax.org on behalf of Jon Ferraiolo Sent: Thu 05/06/2008 00:38 To: mobile at openajax.org Cc: Scott, Andrew E Subject: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video callingoverlooked? Is video calling captured on our requirements list? Jon "Scott, Andrew E" wrote on 06/04/2008 04:00:41 PM: > Hi Jon. > > It should be fine to forward the email. > > Thanks for this. I'm glad to hear that it's not being intentionally left out. > > Andrew Scott > > > From: Jon Ferraiolo > Sent: Thursday, 5 June 2008 1:19 AM > To: Scott, Andrew E > Subject: Re: OpenAjax Mobile Task Force - Video calling overlooked? > Hi Andrew, > Good observation! I don't know if the people who worked on the > requirements list just plain forgot about video calling or whether > they were thinking it was a feature of audio calling. > > Is it OK to forward this to mobile at openajax.org? I can also create > an email from scratch that asks about video calling. > > In terms of whether we will support video calling, I guess the > answer is yes. I believe our intent is to provide APIs for commonly > useful things. The question is more about when rather than if. > According to recent discussion, we are planning to pursue some APIs > right away to get something working and then add other APIs over the > course of time. > > Jon > > > > > Hi Jon. > > I hope that you can assist me. > > I was looking at the OpenAjax Alliance mobile device API > requirements, and on first glance it appears that an obvious one has > been missed: video calling. > > The only calling requirements listed for device service APIs on this page > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > are captured under "voice". There is no mention of video calling > (despite this capability being on the vast majority of new 3G phones). > > Could I please confirm that video calling is intended to be captured > under the voice calling requirements? > > Andrew Scott > Emerging Technology Manager, Telstra Chief Technology Office From jferrai at us.ibm.com Thu Jun 5 07:48:44 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 5 Jun 2008 07:48:44 -0700 Subject: [OpenAjaxMobile] Update from OMTP Message-ID: I received an email from Nick Allott with more information about what's going on at OMTP relative to mobile device APIs. To summarize, I received a slide deck and a document, both of which provided more detail, but basically confirmed what Nick sketched out previously. They are working on: * JavaScript APIs to be implemented on the device * Policy framework (which still appears to overlap with the security white paper we had been contemplating) * Extensibility mechanisms (to allow innovation and differentiation) * Application packaging They are focused on browser scenarios and widget scenarios. I did not see any mention of device-resident applications that use the Web Runtime (our #3 deployment scenario) or site-specific browser applications (our #4). I suggest that we monitor their progress and look for opportunities to recommend generalizations to them such that their policy framework can be applied to scenarios 3 and 4. OMTP is sincere in its efforts to partner with relevant activities at other organizations, including us. Their slide deck right now shows OpenAjax Hub (although IMO we need discussion on that front) and their materials refer to W3C Widgets and related initiatives (e.g., packaging). (One thing that was new to me from the information that was provided was mention of "Web packaging". I will be curious to see what's going on there. Perhaps they are thinking of leveraging the ZIP packaging and digital signatures features from W3C Widgets for use with Web sites as a mechanism to help the browser decide on content trustworthiness.) Nick promises a continuing flow of information. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080605/8ed05e0b/attachment.html From jferrai at us.ibm.com Thu Jun 5 08:17:52 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 5 Jun 2008 08:17:52 -0700 Subject: [OpenAjaxMobile] Open source project ideas Message-ID: We need to talk about the where/when/what/how/who for the shim layer open source project. Here are some proposals: Where: If it is an OpenAjax Alliance open source project, for IPR reasons, it has to be done within our OpenAjax project: * http://openajaxallianc.sourceforge.net/ * http://sourceforge.net/projects/openajaxallianc My thinking is that we add a 4th project named "device" (which would be parallel to existing projects "hub", "hub11", and "gadgets"). When: I don't know about everyone else, but I am booked in the month of June and couldn't do much on the open source project until early July. But once we get started, I hope we can move fairly quickly such that we can have something working by September. (See discussion of demo below.) What: I propose that we start off with a limited subset of APIs that are sufficient for one particular application (or maybe two) that use only a few APIs, and get that working initially, and then move on to adding other APIs. Here is an idea for a proposed application: * In the browser * Accesses current location API and address book * Talks to a Web server (hosted at OpenAjax?) through XMLHttpRequest to share your location and retrieve the location of any contacts who are participating in this application * Displays a map that shows everyone's location Or something like that. I am certainly not hung up on the above example. How: We get this working with at least two different platforms to the point that we can demo it at a tradeshow. Goal is to have two phones with the proper software installed that are communicating with each other. (OK if it requires special-purpose browser plugins) I assume that we will have an SPI mechanism such that bridge code can be plugged into the shim layer which maps the shim layer into platform-specific APIs. We have an SPI mechanism in OpenAjax Hub 1.1, defined at (http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_Providers). I haven't looked at this enough to have an opinion about whether such an approach makes sense here. Who: Short-term critical mass to me is sufficient participation such that we can get a demo working on two different platform providers by September. Therefore, we probably need commitments from two platform provider vendors (where Aplix would be an example of a platform provider). Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080605/606700a0/attachment.html From Andrew.E.Scott at team.telstra.com Thu Jun 5 23:43:25 2008 From: Andrew.E.Scott at team.telstra.com (Scott, Andrew E) Date: Fri, 6 Jun 2008 16:43:25 +1000 Subject: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video callingoverlooked? In-Reply-To: References: Message-ID: Thanks Rotan. Also note that there would need to be some capability, in a "calls" API, to specify whether it should be set up as a voice connection or a video connection. This is important as the either the calling or receiving devices may not support video calls (e.g. devices may not be in 3G coverage), although it may be possible for some web applications to know if a video call would be possible. Andrew Scott Emerging Technology Manager, Telstra Chief Technology Office Phone: +61 417 137 515 Email: andrew.e.scott at team.telstra.com -----Original Message----- From: Rotan Hanrahan [mailto:rotan.hanrahan at mobileaware.com] Sent: Thursday, 5 June 2008 7:47 PM To: OpenAjax Alliance discussion list on Mobile Ajax; mobile at openajax.org Cc: Scott, Andrew E Subject: RE: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video callingoverlooked? While I can imagine a typical call that has audio and no video, I cannot imagine a typical call that has video but no audio (notwithstanding the use-case of mobile interaction between hearing-challenged users). Consequently, it's probably not a problem to consider video calling as a specialised form of voice calling, insofar as it is voice augmented with video. Still, it might be a good idea to change the section title from "Voice" to "Calls", as that covers all grounds. I wonder if there's a case then for controlling what is advertised by a device for the purpose of accepting calls? For example, should the API permit my video-enabled device to be set to accept only voice calls? (We all know the use-case of being somewhere where video might be inappropriate.) If so, then the API may need to be extended to facilitate such control. Maybe this would come under the heading of Indicators, as part of "presence" (which is also missing from the list). ---Rotan. PS On the matter of Geo-location (already mentioned in the requirements) you should note the following: http://lists.w3.org/Archives/Public/public-geolocation/ which (afaik) is the only public hint that W3C is about to embark on this issue. Feel free to contact me privately and I'll direct you to the people behind the scenes. If your company is in the W3C, ask your AC Rep for details. ________________________________ From: mobile-bounces at openajax.org on behalf of Jon Ferraiolo Sent: Thu 05/06/2008 00:38 To: mobile at openajax.org Cc: Scott, Andrew E Subject: [OpenAjaxMobile] FWD: OpenAjax Mobile Task Force - Video callingoverlooked? Is video calling captured on our requirements list? Jon "Scott, Andrew E" wrote on 06/04/2008 04:00:41 PM: > Hi Jon. > > It should be fine to forward the email. > > Thanks for this. I'm glad to hear that it's not being intentionally left out. > > Andrew Scott > > > From: Jon Ferraiolo > Sent: Thursday, 5 June 2008 1:19 AM > To: Scott, Andrew E > Subject: Re: OpenAjax Mobile Task Force - Video calling overlooked? > Hi Andrew, > Good observation! I don't know if the people who worked on the > requirements list just plain forgot about video calling or whether > they were thinking it was a feature of audio calling. > > Is it OK to forward this to mobile at openajax.org? I can also create an > email from scratch that asks about video calling. > > In terms of whether we will support video calling, I guess the answer > is yes. I believe our intent is to provide APIs for commonly useful > things. The question is more about when rather than if. > According to recent discussion, we are planning to pursue some APIs > right away to get something working and then add other APIs over the > course of time. > > Jon > > > > > Hi Jon. > > I hope that you can assist me. > > I was looking at the OpenAjax Alliance mobile device API requirements, > and on first glance it appears that an obvious one has been missed: > video calling. > > The only calling requirements listed for device service APIs on this > page > http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements > are captured under "voice". There is no mention of video calling > (despite this capability being on the vast majority of new 3G phones). > > Could I please confirm that video calling is intended to be captured > under the voice calling requirements? > > Andrew Scott > Emerging Technology Manager, Telstra Chief Technology Office From jferrai at us.ibm.com Mon Jun 9 10:01:28 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Mon, 9 Jun 2008 10:01:28 -0700 Subject: [OpenAjaxMobile] Ajaxian and AJAXWorld articles announcing new white papers Message-ID: FYI - Sorry I was slow in getting the word out. Last week, Ajaxian and AJAXWorld published announcements about our two new white papers: * Ajaxian: http://ajaxian.com/archives/openajax-alliance-white-papers-on-mobile-ajax-and-recent-browser-advances * AJAXWorld: http://openwebdeveloper.sys-con.com/read/582662.htm The Mobile Ajax white paper was the result of several months of collaboration and hard work within the Mobile Task Force. Thanks again to everyone for their contributions. The other white paper, Good News for Ajax, was just republishing an article I submitted to AJAXWorld in March. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080609/ecaf4db9/attachment.html From ian.hay at orange-ftgroup.com Tue Jun 10 03:34:57 2008 From: ian.hay at orange-ftgroup.com (ian.hay at orange-ftgroup.com) Date: Tue, 10 Jun 2008 11:34:57 +0100 Subject: [OpenAjaxMobile] RIA - Ovum Report Message-ID: Hi All, My first post to the list so may well have been covered before, apologies if so. I've just been reading an OVUM report about RIA's and they state that there are 4 main initiatives in the RIA field across all devices: Microsoft with Silverlight Adobe with AIR Sun with JavaFX Google with Gears and leading the drive to open standards based and community tools Seems they are not aware of OpenAjax and the mobile initiatives however it is dated 22 May so the announcements on Ajaxian etc weren't out then were they? Kind Regards orange_logo Ian Hay Head of Emerging Technologies NSM/TECH/ISIR +44 7976 355070 ********************************* 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/20080610/13429879/attachment.html From jferrai at us.ibm.com Tue Jun 10 14:50:24 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 10 Jun 2008 14:50:24 -0700 Subject: [OpenAjaxMobile] RIA - Ovum Report In-Reply-To: Message-ID: Hi Ian, Thanks for bringing this up. The press and analysts sometimes get confused and seem to give much greater attention to technologies that might take off in the future (e.g., AIR, Silverlight, Java FX, Google Gears) rather than technologies that are widely adopted today (e.g., Ajax). Also, the definition of RIA seems to have shifted from the more classic definition of Rich Internet Applications (http://en.wikipedia.org/wiki/Rich_Internet_application) to mean whatever (vaporous, hand-waving) vision of future technology that comes out of the proprietary world. Suddenly, your user interface isn't an RIA unless it supports video and uses the word "offline" somehow (whether you need either of them or not). I guess Google Maps within the browser, and other Ajax things that used to be considered cool, have become hum-drum. The press and analysts tend to be enamored by what the big companies promote. Therefore, attention to the technologies from Adobe (AIR), Microsoft (Silverlight), Sun (JavaFX) and Google (Gears), but they fail to mention other big companies with strong commitment to Open Web technologies, include most everything that comes out of Apple, Google, and IBM, and many of the big players in the mobile industry. The best place for discussions such as this is the Marketing WG (marketing at openajax.org). We don't have anything actively going on there now (except for OpenAjax Conformance), but maybe this will become a topic of discussion sometime soon. Do you want me to subscribe you to that list? Jon Sent by: To mobile-bounces at op enajax.org cc Subject 06/10/08 03:34 AM [OpenAjaxMobile] RIA - Ovum Report Please respond to OpenAjax Alliance discussion list on Mobile Ajax Hi All, My first post to the list so may well have been covered before, apologies if so. I've just been reading an OVUM report about RIA's and they state that there are 4 main initiatives in the RIA field across all devices: Microsoft with Silverlight Adobe with AIR Sun with JavaFX Google with Gears and leading the drive to open standards based and community tools Seems they are not aware of OpenAjax and the mobile initiatives however it is dated 22 May so the announcements on Ajaxian etc weren't out then were they? Kind Regards orange_logo Ian Hay Head of Emerging Technologies NSM/TECH/ISIR +44 7976 355070 ********************************* 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. ******************************** _______________________________________________ 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/20080610/0eea93e0/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/20080610/0eea93e0/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic11652.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://openajax.org/pipermail/mobile/attachments/20080610/0eea93e0/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/20080610/0eea93e0/attachment-0002.gif From ian.hay at orange-ftgroup.com Wed Jun 11 01:42:40 2008 From: ian.hay at orange-ftgroup.com (ian.hay at orange-ftgroup.com) Date: Wed, 11 Jun 2008 09:42:40 +0100 Subject: [OpenAjaxMobile] Korea Widget News Message-ID: Has there been any interest from Korean operators in OpenAjax before in this group? They are doing some interesting work Ian Re-Attention to Mobile Widget Service Mobile Widget is not just for decoration of idle screen any longer but being paid attention as the key player of revitalization of wireless internet. SKT is now performing beta test of T-Interactive 2.0, and KTF and LGT are preparing Multi-popup upgrade and 'Today 2.0', respectively. While 1st generation of widget is just for screen decoration like watch and calendar, 2nd generation expands service range with various applications and supports openness. It enables users to configure their own widget designed through interworking with PC into handset and it is expected that users can easily enjoy various contents on top of what is being provided by CP (Contents Provider) through wireless internet. Our comment: Mobile Widget has been ended in securing fewer users than expected due to closed policy but is now able to provide various applications through opening the network. Every mobile operator is developing services by establishing consortium with wireless internet solution providers. Kind Regards Ian Hay Head of Emerging Technologies +44 7976 355070 TECH/NSM/ISIR ********************************* 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/20080611/2dfd6199/attachment.html From jferrai at us.ibm.com Wed Jun 11 08:47:45 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Wed, 11 Jun 2008 08:47:45 -0700 Subject: [OpenAjaxMobile] Minutes 2008-06-05 (sorry about the delay) Message-ID: Hi everyone, Below are the minutes from last week's Mobile TF teleconference. Sorry it took me so long to post the minutes. Krishna took minutes and sent them to me right away, but I got distracted by other things before doing a little wiki editing on the minutes and posting them. Jon ------------------------ Mobile Minutes 2008-06-05 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-05 Attendees Andrew Sledd, Ikivo Guillermo Caudevilla, Vodafone Ian Hay, Orange John Hardy, Motricity Jon Ferraiolo, IBM Krishna Sankar, Cisco Nikunj Mehta, Oracle David Pollington, Vodafone Minutes Action Items remaining for the group review requirement page and use cases. Discussion followed and decided that this is optional. So moved to defer. Add video call as an alternate flow Discussed and decided to incorporate Rotan?s suggestion ? change title and add video call as a sub item. Nikunj to do. Fast-track exploratory phase post mortem Everybody agreed that the group exceeded expectations and the deliverables have value to the industry. The exploratory phase has come to a successful completion. Next Steps ? a) Start Open Source Shim layer, b) start a wg to develop API architecture and detailed specification Shim Layer Discussion Jon discussed the Shim layer The shim layer is a thin veneer- looks up the system provider, from the system provider looks up implementation for that platform, calls the native API Nikunj pointed out that this would need changes and might not work in existing browsers as they might not have the API support. A short discussion followed. Jon agreed that browser plug-ins or updates would be required. Nikunj pointed out that we need to set expectations on architecture techniques and evolution. Are we going to take a broad sweep across all APis or are we going to dig deeper on a few APis?? What will be the rate of evolution?? Jon said that we will take one (or two) scenarios and 2 or 3 APIs in the context of that use case and develop a prototype to be shown in September timeframe. Jon had sent out an e-mail on this ? location and Address APIs working together. Nikunj asked about the relationship of our open source effort with others. He mentioned the philosophy of Apache with regards to APIs external to Apache Andrew: We will have dialogs as and when necessary and do not plan to redo any work already done. Our goal is to identify important aspects, raise their awareness and provide a way forward Jon/Nikunj: Gears in particular. Google is a member. We also could possibly add adaptors and plug-ins Jon: Also need device manufacturers to write the underlying implementations Nikunj: Do we have device manufacturers willing to donate code?? Jon: Discussions Yes, Commitments not yet. No commitment from WebKit or Opera or others so far Andrew: they are monitoring. We should move forward, keep the momentum and lobby/evangelize Andrew: Is location the good API to start?? Jon: Discussed demo idea in the mailing list. It has location API as well as address book API Andrew: This is a good proposal that captures the spirit of the discussions. Discussion followed. The general consensus was to start working and then evolve. Setup is important. We should give extra weight to folks who are actually working. A discussion on stricture and process followed. Jon: Need to setup a project in sourceforge. It is important to pick the right name. device was suggested and accepted. A discussion on timeframe followed. Decided to kickoff in June and begin work in July. The demo is targeted for the open source in mobile conference in Sept 18. AJAXWorld in Oct 21-22 is another target. David said they might have couple of resources. Vodaphone offered possibility of mobilescript code ? need to check. Quick discussion on the specification work followed. A good goal is to start the specification work in parallel to the shim implementation. Need to document architectural aspects, structure of the APIs et al. Andrew/Jon: Let us start discussion in the e-mail list. Will reconvene 2 weeks from now i.e. June 19th 2008. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080611/878045e6/attachment-0001.html From nikunj.mehta at oracle.com Wed Jun 11 10:19:51 2008 From: nikunj.mehta at oracle.com (Nikunj Mehta) Date: Wed, 11 Jun 2008 10:19:51 -0700 Subject: [OpenAjaxMobile] Minutes 2008-06-05 (sorry about the delay) In-Reply-To: References: Message-ID: <48500937.2010009@oracle.com> I have updated the Device service API requirements around video calling. Please review. Regards, Nikunj Jon Ferraiolo wrote: > > Hi everyone, > Below are the minutes from last week's Mobile TF teleconference. Sorry > it took me so long to post the minutes. Krishna took minutes and sent > them to me right away, but I got distracted by other things before > doing a little wiki editing on the minutes and posting them. > Jon > > ------------------------ > > > > Mobile Minutes 2008-06-05 > > URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-05 > > Attendees > > Andrew Sledd, Ikivo > Guillermo Caudevilla, Vodafone > Ian Hay, Orange > John Hardy, Motricity > Jon Ferraiolo, IBM > Krishna Sankar, Cisco > Nikunj Mehta, Oracle > David Pollington, Vodafone > > Minutes > > > Action Items remaining for the group > > review requirement page and use cases. > Discussion followed and decided that this is optional. So moved to defer. > > > Add video call as an alternate flow > > Discussed and decided to incorporate Rotan?s suggestion ? change title > and add video call as a sub item. Nikunj to do. > > > Fast-track exploratory phase post mortem > > Everybody agreed that the group exceeded expectations and the > deliverables have value to the industry. The exploratory phase has > come to a successful completion. > Next Steps ? a) Start Open Source Shim layer, b) start a wg to develop > API architecture and detailed specification > > Shim Layer Discussion > > Jon discussed the Shim layer > > The shim layer is a thin veneer- looks up the system provider, from > the system provider looks up implementation for that platform, calls > the native API > > Nikunj pointed out that this would need changes and might not work in > existing browsers as they might not have the API support. > > A short discussion followed. > > Jon agreed that browser plug-ins or updates would be required. > > Nikunj pointed out that we need to set expectations on architecture > techniques and evolution. Are we going to take a broad sweep across > all APis or are we going to dig deeper on a few APis ? What will be > the rate of evolution ? > > Jon said that we will take one (or two) scenarios and 2 or 3 APIs in > the context of that use case and develop a prototype to be shown in > September timeframe. Jon had sent out an e-mail on this ? location and > Address APIs working together. > > Nikunj asked about the relationship of our open source effort with > others. He mentioned the philosophy of Apache with regards to APIs > external to Apache > > Andrew: We will have dialogs as and when necessary and do not plan to > redo any work already done. Our goal is to identify important aspects, > raise their awareness and provide a way forward > > Jon/Nikunj: Gears in particular. Google is a member. We also could > possibly add adaptors and plug-ins > > Jon: Also need device manufacturers to write the underlying > implementations > > Nikunj: Do we have device manufacturers willing to donate code ? > > Jon: Discussions Yes, Commitments not yet. No commitment from WebKit > or Opera or others so far > > Andrew: they are monitoring. We should move forward, keep the momentum > and lobby/evangelize > > Andrew: Is location the good API to start ? > > Jon: Discussed demo idea in the mailing list. It has location API as > well as address book API > > Andrew: This is a good proposal that captures the spirit of the > discussions. > > Discussion followed. The general consensus was to start working and > then evolve. Setup is important. We should give extra weight to folks > who are actually working. > > A discussion on stricture and process followed. > > Jon: Need to setup a project in sourceforge. It is important to pick > the right name. device was suggested and accepted. > > A discussion on timeframe followed. Decided to kickoff in June and > begin work in July. The demo is targeted for the open source in mobile > conference in Sept 18. AJAXWorld in Oct 21-22 is another target. David > said they might have couple of resources. Vodaphone offered > possibility of mobilescript code ? need to check. > > Quick discussion on the specification work followed. > > A good goal is to start the specification work in parallel to the shim > implementation. Need to document architectural aspects, structure of > the APIs et al. > > Andrew/Jon: Let us start discussion in the e-mail list. Will reconvene > 2 weeks from now i.e. June 19th 2008. > > ------------------------------------------------------------------------ > > _______________________________________________ > mobile mailing list > mobile at openajax.org > http://openajax.org/mailman/listinfo/mobile > From Andrew.Sledd at ikivo.com Wed Jun 18 02:06:56 2008 From: Andrew.Sledd at ikivo.com (Andrew Sledd) Date: Wed, 18 Jun 2008 11:06:56 +0200 Subject: [OpenAjaxMobile] Mobile TF Conf Call reminder: Thursday 19 June , 9amPT, noonET, 5pm London, 6pm Paris Message-ID: <234EB4699C751A4A95DF4FD8D041BBFDD77E34@SESTHSRV10.zoomon.local> Hi all, Reminder to join in the Mobile Task Force conf call tomorrow. Previous meeting was on June 5 and minutes can be found here: URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-05 We continue discussion of Shim Layer development and api specification work. Andy, co-chair Mobile TF 9amPT, noonET, 5pm London, 6pm Paris 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 [edit ] IRC channel * IRC channel: irc.freenode.net, #oaa-mobile * Free online IRC client: 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 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/20080618/4c733525/attachment.html From ksankar at cisco.com Wed Jun 18 04:45:36 2008 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Wed, 18 Jun 2008 04:45:36 -0700 Subject: [OpenAjaxMobile] Mobile TF Conf Call reminder: Thursday 19 June , 9amPT, noonET, 5pm London, 6pm Paris In-Reply-To: <234EB4699C751A4A95DF4FD8D041BBFDD77E34@SESTHSRV10.zoomon.local> References: <234EB4699C751A4A95DF4FD8D041BBFDD77E34@SESTHSRV10.zoomon.local> Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A04F848C7@xmb-sjc-219.amer.cisco.com> Am on the road this week, so won't be able to make it. Cheers From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org] On Behalf Of Andrew Sledd Sent: Wednesday, June 18, 2008 2:07 AM To: OpenAjax Alliance discussion list on Mobile Ajax Subject: [OpenAjaxMobile] Mobile TF Conf Call reminder: Thursday 19 June ,9amPT, noonET, 5pm London, 6pm Paris Hi all, Reminder to join in the Mobile Task Force conf call tomorrow. Previous meeting was on June 5 and minutes can be found here: URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-05 We continue discussion of Shim Layer development and api specification work. Andy, co-chair Mobile TF 9amPT, noonET, 5pm London, 6pm Paris 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 [edit ] IRC channel * IRC channel: irc.freenode.net, #oaa-mobile * Free online IRC client: 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 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/20080618/2175f14a/attachment-0001.html From jferrai at us.ibm.com Thu Jun 19 08:16:36 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Thu, 19 Jun 2008 08:16:36 -0700 Subject: [OpenAjaxMobile] Some ideas for how the shim layer might work Message-ID: For discussion today, I sketched out some ideas for how the shim layer might work on the following wiki page: * http://www.openajax.org/member/wiki/OpenAjax_Device_APIs Most of the ideas on that page represent rehashing of various techniques we have used at other JavaScript initiatives, particular OpenAjax Hub 1.0 and 1.1. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080619/75f0624d/attachment.html From jferrai at us.ibm.com Fri Jun 20 11:10:22 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Fri, 20 Jun 2008 11:10:22 -0700 Subject: [OpenAjaxMobile] Minutes 2008-06-19 Message-ID: Thanks to Ian for taking minutes yesterday. Mobile Minutes 2008-06-19 URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-06-19 Attendees Paddy Byers, Aplix Guillermo Caudevilla, Vodafone David Pollington, Vodafone Jon Ferraiolo, IBM Adam Peller, IBM Ian Hay, Orange/FT Andrew Sledd, Ikivo Troed Sandberg, Sony Ericsson Minutes Minutes from last call accepted Main purpose of the call is to discuss the new document outlining device APIs written by Jon http://www.openajax.org/member/wiki/OpenAjax_Device_APIs Produce something solid and tangible based on open discussion. Jon outlined the objective which everyone agreed with based on silence, the objective being to have a working demo by the end of the Summer in time for the next major conference events, tradeshows, in order to do this aim for one or two only to start with like Geo and Address book. Possible if we assume use of Mobilescript from Voda or WebVM from Aplix and add a shim layer. (Scribe says: I cant make much sense of my notes on the actual discussion now) During the walkthrough the discussion centred around several topics: Loader - use an existing one or build own? bubble it up to the shim layer (making it much larger) or push it to the adapters? Hesitant to take on a loaded project at this stage Paddy volunteered to write up and supply some examples for next call to discuss further User Agent - where does the sniffing take place to establish presence of OpenAjax Browsers - sticking to main 4 desktop (IE, Opera, Safari, Firefox) and not xHTML type OBJECT tag - number of methods and ideas explored Connhandles - perhaps overly complex for what is required at this point Providers should implement support per API Modular - don't load all APIs at each call, make modular, some discussion on asynchronous call, status and how to handle that Shim layer - try to keep it as thin as possible, some discussion of associative arrays providing a lookup per API, decision made to revisit discussion on modularisation later Provider provides a list of functions for each API shim does lookup then calls that function makes JS small & fast Paddy - Provider is the adaptor and shim is the selector ?? asked if a device has two ways to get Geo for example how would the shim know which one to pick? In the end it was decided to refine proposals by email over the next two weeks and revise at next meeting as the lengthy discussion raised a number of things that need to be resolved, the 2 main talking points identified were whether to be DYNAMIC / MODULAR or a LOADER / ConnHANDLES route and how the shim / API needs to be defined Next meeting 3rd July at the usual time -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080620/3ba78764/attachment.html From jferrai at us.ibm.com Tue Jun 24 14:42:00 2008 From: jferrai at us.ibm.com (Jon Ferraiolo) Date: Tue, 24 Jun 2008 14:42:00 -0700 Subject: [OpenAjaxMobile] Mobile perspective on what is needed in future browsers Message-ID: As many of you probably know, OpenAjax Alliance has a "Runtime Advocacy" initiative where we have create a a forum of leading Ajax industry people to build a prioritized list of features that Ajax developers need in future browsers. Our goal was to give the browser vendors a general idea about what features are most important to the Ajax community for their next-generation browsers (IE9, Safari4 (or 3.2), Firefox4, and Opera10). This first-version wishlist was built mainly by various leading Ajax desktop guys, but of course there is significant overlap between what browser features are good for mobile devices. We tried to do the whole thing in a lightweight, Web2.0 style by creating a wiki that anyone could join and participate. Even though it is public, we advertised it mostly to the leading Ajax folks. We have had about 70 people participate so far, mostly on the write-ups for the various features. We are now in the final stages ("Phase II") where people vote on their favorite features. Voting closes on July 10. It would be great if various people from this task force could share your points of view by casting votes. It's easy. Create a login as described at: * http://www.openajax.org/runtime/wiki/Main_Page#Who_can_participate_and_how_to_join_the_effort and then go to the following page to vote: * http://www.openajax.org/runtime/wiki/Phase_II_Voting To vote, just use the popup menus to rank the importance of each feature from 0 to 10 (highest). You can see how others voted at: * http://www.openajax.org/runtime/wiki/Phase_II_Voting_Details The feature list for the voting page is frozen, but new features can be added on the following wiki page (in the section "Recently Added Feature Requests"). * http://www.openajax.org/runtime/wiki/Feature_Requests_Summary_Page Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://openajax.org/pipermail/mobile/attachments/20080624/b7b9a8c6/attachment.html