Mobile Minutes 2008-07-17
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-07-17
Contents |
Attendees
- Paddy Byers, Aplix
- Jon Ferraiolo, IBM
- Adam Peller, IBM
- Andrew Sledd, Ikivo (co-chair)
- Ian Hay, Orange France-Telecom
Minutes
OMTP report from Paddy
Paddy: We are talking about how to respond to W3C Widget Requirements. We are thin on the ground due to summer holidays. We should have public working drafts from both the arch/security committee and the interfaces committee. Mostly mid-level requirements that states the functionality that we want. There will be some low-level requirements that are moving towards actual low-level APIs but those are embryonic.
Paddy: I forwarded Jon's proposed APIs to the OMTP list. Not fully consistent with what we have been working on. In general, the set of principles are good but I don't agree on all of the details.
General process going forward
Jon: What I am thinking is that we discuss high-level approaches in the phone call, but work out the details such as the exact APIs in the open source effort
Andy: Yes
Loader
Paddy: I don't want to monopolize the call with the loader. We talked about it for most of the call last week
Jon: Andy, Adam, have you looked at Paddy's loader JavaScript?
Andy: Just now
Adam: Looks similar to Dojo, which uses two mechanisms, both dynamic script and xhr
Paddy: If we go for the loader, then we want the ability for a particular loader to add its own private implementation components. Works like Browser Plus. Then have a fallback behavior that is portable. Resolve name and version into a URI is the standard case.
Paddy: Regarding Jon's question, the name is a URI. Could be opaque like a URN or an http URI to which you append parameters. But the script could be more intelligent.
Adam: Sorry, I missed earlier discussion, but can we back up? Why not just load script manually?
Paddy: We talked about a number of advantages to a standard loader. Among the advantage, you can tell if a module is already loaded. Also, provides the ability to pass parameters and satisfy particular requests.
Adam: There are pitfalls. The latency issue of loading script tags separately. Prevents the ability to put inline JavaScript. You can use async requests but that has possibility of race conditions. If you use synchronous XHR, it blocks everything else. It is difficult to know when a script has been loaded.
Paddy: In our model, things key off of onload. But without a loader, chance of more roundtrips.
Adam: With loader approach, chance of race conditions.
Paddy: What does loader do in dojo? Hide things from the programmer?
Adam: Yes
Paddy: Individual toolkits can optimize on the proposed approach, such as dojo offering a more advanced loader. My code is just an illustration of functionality, not exactly how it would work.
Adam: But I don't think this would slide into dojo
Paddy: But everything could have been loaded beforehand
Adam: Yes, that's how dojo works
Paddy: Need to look how this aligns with existing frameworks
Jon: We need to study this against dojo and other toolkits
Adam: Most toolkits put the burden on the developer
Andy: Given our fast-track approach, which will give developers what they need?
Adam: We don't want to do something that has performance problems
Jon: Yes, if it isn't optimal in performance, it won't get adopted
Paddy: What we want to avoid is load, then go get more things, which isn't good. Need to trigger before doc load. Provided you do that, you have contained any damage. Need to be optimized away.
Adam: May have to promote this approach to a best practice. Dojo has to wait for onload to avoid race conditions
Andy/Adam/Jon: We have to assume that anything that is problematic on desktop will be worse on mobile due to increased fragmentation.
Paddy: Not always the case that a script element will be added.
Andy: There is the advantage of parsing parameters.
Adam: Of course it is possible to add parameters to the URI. I love the benefits but it raises questions. Also, may load a library (DLL) which adds more timing issues and latency issues.
Andy/Paddy: Network latencies will dominate.
Jon: Let's close discussion and have someone study dojo.
Andy: Adam, can you write up why loader isn't winning favor in desktop browser world?
Adam: I'm not against a loader, I just want to see how well things will fit in. Dojo provides quick development but offers various optimizations for deployment.
Jon: I'll take the action to work with Adam to study dojo and other libraries
Jon's API proposals
Jon: Just a starting point for discussion. I proposed CRUD-like method names just arbitrarily to align with something that exists in industry. If there are other approaches, bring them up. I'm not tied to the CRUD method names.
Adam: How about getters and setters?
Jon: I have proposed you retrieve the whole property bag. But maybe we should add getters and setters for particular properties.
Adam: Dojo data has CRUD-like APIs. Maybe a batch approach.
Jon: Do we need a transaction approach with callbacks?
Paddy: Only needed if API itself has a transaction notion.
Paddy: Let's talk about the one-arg proposal. All args as an associative array. Haven't seen that before. Is that usual? Versus numbered args.
Adam: Sort of leverages the whole JSON movement. I've seen it used for complex methods and flexibility.
Paddy: Yes, allows extensibility. Interesting approach.
Paddy: A disadvantage is increased garbage for collection. Naive usage would create garbage.
Andy: Need modularity at the right level so you don't load too much.
PaddY: Some callbacks may not be clear relative to success versus failure. Seems arbitrary. Also, what is the parameter list for callbacks? Also, sometimes you want to pass the original object to the callback function.
Jon: My proposal takes the approach used by the OpenAjax Hub which sends both publisher and subscriber data to the callback.
Paddy: Good to sketch out some examples.
Jon: Yes
Paddy: Back to shadow objects. But sometimes you will pass a real object with APIs. For example, file object with a but of methods
Jon: Yes, right, by saying always shadow objects, that's too extreme
Andy: A principle, not a requirement
Paddy: API doc should be clear whether pure shadow or pure references
Jon: Yes
Paddy: Better to be consistent
Jon: Will update the spec to reflect comments from this phone call
Next phone call
- No Andy
- Maybe Paddy
- Try for 2 weeks from now. Backup is 3 weeks from now
