[OpenAjaxMobile] Minutes 2008-07-17

[Jon Ferraiolo]

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

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





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


Minutes

OMTP report from Paddy


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


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



General process going forward


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


Andy: Yes



Loader


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


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


Andy: Just now


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


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


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


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


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


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


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


Adam: With loader approach, chance of race conditions.


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


Adam: Yes


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


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


Paddy: But everything could have been loaded beforehand


Adam: Yes, that's how dojo works


Paddy: Need to look how this aligns with existing frameworks


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


Adam: Most toolkits put the burden on the developer


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


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


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


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


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


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


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


Andy: There is the advantage of parsing parameters.


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


Andy/Paddy: Network latencies will dominate.


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


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


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


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



Jon's API proposals


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


Adam: How about getters and setters?


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


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


Jon: Do we need a transaction approach with callbacks?


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


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


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


Paddy: Yes, allows extensibility. Interesting approach.


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


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


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


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


Paddy: Good to sketch out some examples.


Jon: Yes


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


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


Andy: A principle, not a requirement


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


Jon: Yes


Paddy: Better to be consistent


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

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