Suggesstions on Widgets 1.0: Packaging and Configuration document
Hi, I have read the the following document: Widgets 1.0: Packaging and Configuration W3C Candidate Recommendation 14 July 2009 http://dev.w3.org/2006/waf/widgets/ Please find below my suggestions. Best regards, Oguz Kupusoglu Suggestion 1 Using a separate XML file named “proprietarty.xml” for specifying all the proprietary extensions to the Configuration Document. It will be found at the place of the Configuration Document. Rationale * Keeping the config.xml file fully standard. * Easier maintenance by combining all non-standard stuff separately.. * Allowing reviewers see the proprietary stuff quickly and cleanly. * However, From i18n point of view maintaining one more file may be a burden. Suggestion 2 Using a separate XML file named “preferences.xml” for persistently saving the user preferences. It will be found at the place of the Configuration Document. Rationale * When the related Widget is updated or reset, the Widget Engine can easily check or restore the preferences. * Allowing reviewers see the preferences quickly and cleanly. * However, From i18n point of view maintaining one more file may be a burden. Suggestion 3 Assume each widget has a complaint line: by simply activating it, preferably adding some text, the user will inform the widget author and widget host, widget gallery or AppStore, that something is wrong with the widget. The complaint proceeding depends on the widget host policy. For example, if the number of complaints hit a pre-defined threshold the widget host may remove the problematic widget or can simply record the number of complaints. In fact, this idea is already proposed by Marcos Caceres, see Position on Widget Security ( http://datadriven.com.au/ ). Rationale * If a widget is used by technically illiterate people, there should be an easy-to-use method for them to inform somebody that something is wrong with a widget before they remove the widget. I don't expect these people to go to the original place where they downloaded the widget to take action. However, if such an easy-to-use built-in complaint line is available, such people will take action. I am working on some widgets to be used on TV's by ordinary people, and ease of use with a remote controller is a prime concern for me. Suggestion 4 From marketing point of view download rankings are important. For example, Download rankings are key to success since users trawl the most-popular lists for games.* Assume each widget has a rating option. By activating it, the user will send a rating between 0 and 5. Hence, the widget hosts may maintain two separate listings: one is download ranking and the other is user rating. * Washington Post, Gabriel Madway, Big game publishers muscle in on iPhone's upstarts, 15 July 2009 Rationale * If a widget is used by technically illiterate people, there should be an easy-to-use method for them to inform somebody their verdict on the widget. * At any moment t, the widget users while looking for new widgets have more listing to check. This will reduce the pressure on the “download ranking” list.
RE: [widgets] conformance requirements review
Hi Dom, It's fairly straightforward to extract the WebIDLs from W3C specs (e.g. using XSLT), and I can also imagining annotating these with doxygen comments by more auto-extracting work. My checkers also tries to verify that the Web IDL and documentation match semantically. For this we need a format within the doxygen or surrounding HTML. I think this could be agreed as part of the DAP. Is it possible that BONDI specs, together with widl format specification are taken as basis in DAP? Who, when and how takes this decision? Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Dominique Hazael-Massieux [mailto:d...@w3.org] Sent: Wednesday, July 15, 2009 3:43 PM To: Marcin Hanclik Cc: public-webapps@w3.org; public-device-a...@w3.org Subject: RE: [widgets] conformance requirements review Le lundi 13 juillet 2009 à 13:38 +0200, Marcin Hanclik a écrit : I cannot publish the source code now, also due to the immaturity of the tool. I personally wouldn't mind that immaturity and would be happy to contribute in making it more mature. The tool was developed to fit the format used within BONDI, it does not understand the HTML format used in W3C (HTML is the output, input is WebIDL + doxygen). It's fairly straightforward to extract the WebIDLs from W3C specs (e.g. using XSLT), and I can also imagining annotating these with doxygen comments by more auto-extracting work. Thanks, Dom Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] conformance requirements review
On Jul 17, 2009, at 15:04 , Marcin Hanclik wrote: Is it possible that BONDI specs, together with widl format specification are taken as basis in DAP? Who, when and how takes this decision? That would be a decision for the DAP WG to take, once there are enough participants signed up (it takes a little while for people to sign up in the summer, alas) for the WG to make a decision that won't be revisited later. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
RE: DataCache API - editor's draft available
On Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote: On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote: I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. There is a tradeoff when adding the complexity of unreliable networks - either more complex client application code, or more complex client interception code. In our experience, we have found the latter to be actually more manageable for cases where the interception and off-line serving is done in a relatively application-independent manner. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally. DataCache's interception pattern has existed for a while. A good survey of mobile data management and transaction support has covered this pattern [1]. The discussion there is not limited to Web browsers, though. I scanned through the paper you cite but it isn't clear to me which part of that is equivalent to your proposal. Is it possible to point out which section I should read more closely? The pattern that isn't familiar to me is one where it appears that application logic is provided by interception. Given the generic nature of the Mobile Transactions paper you focus on application independence, are you proposing that the DataCache is part of a solution with no application specific code? In other words is there some platform component, whether that be a JavaScript library or otherwise server-provided infrastructure, that operates generally at the interception point. Alternatively, is it application specific code that will be hand written for my use case every time? When Jonas asks the question about how do you expect people to use this, what comes to mind for me is a question about a scenario. I'm a web developer and I've built an application that makes XHR calls to exchange data with my server. I'd like to provide access to this application in situations where I am occasionally disconnected because of intermittent network connectivity. Do I now sit down and try to figure out what network requests I need to intercept and write JavaScript code for handling all of those requests? Or is there a library I can just plug in that, with some configuration, does that for me? Or is this something my server infrastructure should already support and if it does I just turn it on but otherwise I'm out of luck? Does the situation change if I am building an application from scratch that wants to deal with network disconnections? On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that? Yes. I certainly considered window.applicationCache. I have previously proposed including additional things in HTML5, but the feedback was that the application cache could not be broken down in to any further primitives due to bootstrapping requirements [3]. I certainly feel that applicationCache can be composed with the primitives of DataCache + versioning. On the other hand, the converse is not possible due to ApplicationCache's: a. strictly static manifest serving, b. lack of support for version-free resources, and c. missing authorization checks. [1] http://portal.acm.org/citation.cfm?id=992378 [2] http://o-micron.blogspot.com/2009/04/how-is-bitsy-different-from- html-dojo.html [3] http://lists.w3.org/Archives/Public/public-html/2008Nov/0224.html I understand that your DataCache proposal provides different functionality to AppCache. I wasn't suggesting that they were equivalent. However, the AppCache as specified is getting implemented today (it is in Safari and Firefox with other implementations on the way). The problem I have is that I can't go implement AppCache and then add on some new methods and alternative interception-path to get DataCache-like features - I have to write a completely independent mechanism. If I propose that we build AppCache and then DataCache, someone will say, Hang on, didn't we just build this - why do we need two? While it might not be the perfect solution (we know the web far from ideal and is a lot of compromise), this type of proposal would be a lot more compelling to me if I could say This is what we have to add, this is how, and here are the use cases that make it valuable with a roadmap for extending what people are already building instead of something brand new. Cheers, Adrian.
[widgets] Wookie accepted into Apache Incubator
Hi everyone, Wookie - which I demonstrated at the Paris F2F - has just been accepted into the Apache Incubator. Wookie implements the W3C Widgets draft specifications as a web service supporting web applications, in a manner similar to (and compatible with) Apache Shindig for OpenSocial gadgets. We've been tracking and contributing to the Widgets family of specifications, and we look forward to working with the rest of the community in helping make sure Wookie conforms to the specs, with the potential to act as a reference implementation (at least for server- based UAs). Once we've sorted out the infrastructure at ASF and moved the existing code our focus will be to ensure that we have a broad community of developers actively contributing to the project. There's a blog post by Ross Gardler at ASF giving some more details here: http://osswatch.jiscinvolve.org/2009/07/17/wookie-accepted-into-apache-incubator/ Cheers, S /-/-/-/-/-/ Scott Wilson Assistant Director, JISC CETIS University of Bolton Projects: FeedForward: http://getfeedforward.org Wookie: http://getwookie.org scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott smime.p7s Description: S/MIME cryptographic signature
Re: DataCache API - editor's draft available
On Thu, Jul 16, 2009 at 4:17 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote:
On Jul 16, 2009, at 3:54 PM, Jonas Sicking wrote:
I do understand how Interceptor/DataCache works. And understand that
it's seamless and can (based on a decision made by the browser)
seamlessly intercept both XHR requests and img src=.. requests.
What is not entirely clear to me is how you envision that authors will use
it.
Authors will use it in all three kinds of use cases I explained earlier -
XHR, form, and hyperlinked data. DataCache is designed to support all three.
The intention is to accommodate any use case arising from the issuance of a
network request when the device is off-line.
I.e. are you expecting authors to want to intercept XHR requests?
For data driven applications, I expect this usage scenario.
Or
img src=... requests? Or script src=... requests?
script src=... should be adequately supported by HTML5 (ApplicationCache),
unless the src value is dynamic in nature. For the static case, I don't
expect to see much usage of DataCache.
Ok that answers my question.
See, what I don't fully understand is what the use cases are. For
static resources like static images, scripts, plugins etc, it seems to
me that the HTML5 ApplicationCache should work, as you point out.
For dynamic images, I think canvas is what you'd want to use anyway
since generating encoded png images and serving it through the http
Interceptor is a whole lot more complicated.
For loading data using XHR, or submitting data using a form, it seems
like if the web application is abstracted at a higher level, then http
interception isn't strictly needed. If you currently have code like:
function readData(callback) {
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == 4 xhr.status == 200)
callback(xhr.responseText);
}
xhr.open(...);
xhr.send();
}
Then in order to support offline you could do:
function readData(callback) {
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == 4 xhr.status == 200)
callback(xhr.responseText);
}
xhr.onerror = function() {
text = readDataFromLocalStore();
callback(text);
}
xhr.open(...);
xhr.send();
}
So I'm not sure what new use cases we are solving.
What I do agree this new API does is that it allows a *different* way
to deal with offline. One that could be argued to be simpler (I
haven't looked into it enough to have an opinion on if it's simpler or
not).
So rather than solving new use cases, it seems like this is providing
another way to solve them.
Is that correct?
/ Jonas
Re: [widgets] Wookie accepted into Apache Incubator
On Friday, July 17, 2009, Scott Wilson scott.bradley.wil...@gmail.com wrote: Hi everyone, Wookie - which I demonstrated at the Paris F2F - has just been accepted into the Apache Incubator. congratulations! Wookie implements the W3C Widgets draft specifications as a web service supporting web applications, in a manner similar to (and compatible with) Apache Shindig for OpenSocial gadgets. it's great to see W3C widgets being compatible with that technology. Thanks for all your help making that happen. We've been tracking and contributing to the Widgets family of specifications, and we look forward to working with the rest of the community in helping make sure Wookie conforms to the specs, with the potential to act as a reference implementation (at least for server-based UAs). Excellent! I will be sure to mention wookie during the W3C transition request to CR (this Tuesday). It will strengthen the case for the document transitioning to CR. Once we've sorted out the infrastructure at ASF and moved the existing code our focus will be to ensure that we have a broad community of developers actively contributing to the project. There's a blog post by Ross Gardler at ASF giving some more details here: http://osswatch.jiscinvolve.org/2009/07/17/wookie-accepted-into-apache-incubator/ will take a look! Thanks for the update. Cheers, S /-/-/-/-/-/ Scott Wilson Assistant Director, JISC CETIS University of Bolton Projects: FeedForward: http://getfeedforward.org Wookie: http://getwookie.org scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott -- Marcos Caceres http://datadriven.com.au
