Mobile Minutes 2008-05-01

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-05-01

Contents

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

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

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

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.

Personal tools