Re: Web Widgets, Where Art Thou?

2013-07-30 Thread Marcos Caceres
Hi Daniel, 

On Monday, July 29, 2013 at 8:22 PM, Daniel Buchner wrote:

 FWIW, I ran a dev poll last week: ~95% of respondents

What was the sample size? Who were the developers? Where was the poll run? 

 preferred a simple, separate HTML document specifically for their widget and 
 use all the existing DOM APIs and modules from across the web for things like 
 storage, localization, etc. In fact, of the only 2 respondents opposed to the 
 idea, one fundamentally misunderstood the widget concept and the other 
 accidentally selected the wrong option. Here are some of their qualitative 
 responses:

How did you select the sample of responses you sent us? 
 
Can I have access to the complete questionnaire? I need to check the validity 
and reliability of the questions as well as the overall design of the poll - as 
the ordering of the questions can influence answers as well as how the 
questions are phrased, etc.   

If it's a non-probabilistic sample (as it appears to be), we can't conclude 
anything definitive from it because it's not representative - though it can be 
indicative of something descriptively, but not inferentially. 
 Given the miniscule level of adoption/use of the current widget scheme, and 
 the fact the proposed addition of a lighter declaration via the app manifest 
 wouldn't affect use of the old spec, I'm having trouble understanding why 
 this proposal is facing such stop energy.

Please don't confuse questions for stop energy - the costs of standardization 
(social/monetary) is extremely high - specially so if we don't do it right, so 
there will be a lot of scrutiny on anything being proposed. 




Re: [widgetsapi] reference to WebIDL

2013-07-30 Thread Marcos Caceres



On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:

 Hi,
 In the PR [1], the text referencing WebIDL is not using one of the three 
 conformance clauses defined in WebIDL [2].
 
 Could
 This specification uses [WebIDL] to specify application programming 
 interfaces. be clarified using one of the proposed wordings from WebIDL?
 (likely 'Conforming IDL Fragments' per reading of the spec).
 Thanks,
 


Sure, I can add that if you think it will be helpful. 

-- 
Marcos Caceres






IndexedDB: Thoughts on implementing IndexedDB

2013-07-30 Thread Austin William Wright
I've been meaning to implement IndexedDB in some fashion for a while.
Earlier this month, shortly after the call for implementations, I realized
I should be getting on that. I've been working on an in-memory ECMAScript
implementation with fast data structures and the like. I also intend to
experiment with new features like new types of indexes (hash tables that
can't be iterated, and index values calculated by expression/function,
which appears to have been discussed elsewhere).

I've had a few thoughts, mostly about language:

(1) Is there no way to specify an arbitrary nested path? I want to do
something like ['menus', x] where `x` is some token which may be anything,
like an empty string or a string with a period in it. This is especially
important if there are structures like {http://example.com/URI: value}
in documents, which is especially common in JSON-LD. From what I can tell,
IndexedDB essentially makes it impossible to index JSON-LD documents.

It appears the current behavior instead allows you to index by multiple
keys, but it's not immediately obvious this is the rationale.

How *would* one include a property whose key includes a period? This seems
to be asking for security problems, if authors need to implement an
escaping scheme for their keys, either when constructing a key path or when
constructing objects. Database names can be anything, why not key names?


(2) There are still a few references to *Sync terms from the old
synchronous API. Specifically, IDBDatabaseSync and IDBCursorWithValueSync.


(3) I had trouble deciphering the exact behavior of multiple open
transactions on one another. I eventually realized the definition of
IDBTransactionMode describes the behavior.

Still, however, this document appears to talk in terms of what is written
to the database. But this isn't well defined. If something is written to
the database, wouldn't it affect what is read in a readonly transaction?
(No.)

And the language seems inconsistent. The language for `abort` says that
changes to the database must be rolled back (as if every operation writes
to storage), but the language for `Steps for committing a transaction`
specifies it is at that time the data is written (as if all write
operations up to this point are kept in memory). There's not strictly a
contradiction here, but perhaps more neutral language could be used.


(4) The section Steps for asynchronously executing a request says Set
/transaction/ to the `transaction` associated with `source`.

Perhaps it should instead say Let /transaction/ be the `transaction` which
is associated with `source`

Because /transaction/ is previously undefined.


(5) I found the language for iterating and creating a Cursor hard to
understand being nested in multiple layers of algorithms. Specifically,
where an IDBCursor instance was actually exposed to the user. But now it
makes sense, and I don't really see how it might be improved. An
(informative) example on iterating a cursor may be helpful.


(6) The document refers to the HTML5 Structured Clone Algorithm. It's a bit
concerning that it has to refer to ECMAScript algorithms defined in a
specification that defines a markup language. I don't think referring to a
markup language should be necessary (I don't intend on using my
implementation in an (X)HTML environment, just straight XML if anything at
all), though perhaps this is just a modularity problem with the HTML5 draft
(or rather, lack thereof).


Finally, is there a good test suite? I can't seem to find anything in the
way of regression tests. I'll perhaps publish my own, if not.


Austin Wright.


Re: IndexedDB: Thoughts on implementing IndexedDB

2013-07-30 Thread pira...@gmail.com
 Finally, is there a good test suite? I can't seem to find anything in the
 way of regression tests. I'll perhaps publish my own, if not.

+1, I've developed my own In-Memory implementation as a polyfill to
ignore a bug on Chrome regarding to files storage and I'm also
thinking about develop one for Node.js, and this would be really
useful. I believe there are some tests on W3C GitHub account, but
didn't have time to check them myself.


-- 
Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix.
– Linus Tordvals, creador del sistema operativo Linux



Re: IndexedDB: Thoughts on implementing IndexedDB

2013-07-30 Thread Arthur Barstow

On 7/30/13 4:37 AM, ext pira...@gmail.com wrote:

Finally, is there a good test suite? I can't seem to find anything in the
way of regression tests. I'll perhaps publish my own, if not.


+1, I've developed my own In-Memory implementation as a polyfill to
ignore a bug on Chrome regarding to files storage and I'm also
thinking about develop one for Node.js, and this would be really
useful. I believe there are some tests on W3C GitHub account, but
didn't have time to check them myself.


Some IDB tests have been submitted 
https://github.com/w3c/web-platform-tests/tree/master/IndexedDB/submissions 
and [1] contains some information about the review status of these 
submissions.


([2] contains general information about WebApps' testing effort.)

-AB

[1] 
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jul/.html

[2] http://www.w3.org/wiki/Webapps/Testing






Re: IndexedDB: Thoughts on implementing IndexedDB

2013-07-30 Thread pira...@gmail.com
That were just the tests I was talking about, thanks :-) Unluckily it
seems they are not prepared to just give them to your IndexedDB
implementation and run them all at once, but it's a good starting
point.

2013/7/30 Arthur Barstow art.bars...@nokia.com:
 On 7/30/13 4:37 AM, ext pira...@gmail.com wrote:

 Finally, is there a good test suite? I can't seem to find anything in the
 way of regression tests. I'll perhaps publish my own, if not.

 +1, I've developed my own In-Memory implementation as a polyfill to
 ignore a bug on Chrome regarding to files storage and I'm also
 thinking about develop one for Node.js, and this would be really
 useful. I believe there are some tests on W3C GitHub account, but
 didn't have time to check them myself.


 Some IDB tests have been submitted
 https://github.com/w3c/web-platform-tests/tree/master/IndexedDB/submissions
 and [1] contains some information about the review status of these
 submissions.

 ([2] contains general information about WebApps' testing effort.)

 -AB

 [1]
 http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jul/.html
 [2] http://www.w3.org/wiki/Webapps/Testing






-- 
Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix.
– Linus Tordvals, creador del sistema operativo Linux



Re: Web Widgets, Where Art Thou?

2013-07-30 Thread Charles McCathie Nevile
On Mon, 29 Jul 2013 21:22:38 +0200, Daniel Buchner dan...@mozilla.com  
wrote:



FWIW, I ran a dev poll last week: ~95% of respondents preferred


Sorry Daniel, but without a clear statement of methodology, selection of  
respondents, and the actual questions, this is equivalent to my friends  
tend to agree with me on issues we think are important. I.e.  
unsurprising, but not very informative about any group other than people  
like me.



a simple, separate HTML document specifically for their widget and use
all the existing DOM APIs and modules from across the web for things
like storage, localization, etc. In fact, of the only 2 respondents
opposed to the idea, one fundamentally misunderstood the widget concept
and the other accidentally selected the wrong option.


[a bunch of stuff snipped since it isn't given with sufficient context to  
interpret usefully]



 This user misunderstood a few things, and seemed to believe that
widgets are somehow bound to Web Components*


That's not very surprising. The name was badly chosen, since the same word  
has been used for about three times as long to describe the things that  
Web Components allow - objects that provide some kind of conventional  
interactive behaviour.



Given the miniscule level of adoption/use of the current widget scheme,


Please define your terms a bit more clearly.

The TV industry is relatively slow-moving since like it or not they don't  
have easily upgradeable firmware and users upgrade TVs only very slightly  
faster than fridges. But there is a high (to mimic the approach to  
quantitative measurement we have so far in this discussion) level of  
widget uptake in smart TV. Some ecosystems like Blackberry and Sencha  
are well-known, but it is not so obvious that they are using the existing  
widget stack basically as-is. There are digital signs all over the place,  
from supermarket tags in poor old spain to Times Square, Picadilly Circus,  
and more or less all of Tokyo - and again this industry has a high level  
of widget uptake.


These are stacks that are converging with the Web. Like mobile, we can  
expect the collective weight of these players to have a serious impact on  
the industry as a whole - although it will probably take some a few years  
to catch up.



and the fact the proposed addition of a lighter declaration via the app
manifest wouldn't affect use of the old spec,


Divergence - providing developers with two ways to do the same thing -  
either means that one system will die and be replaced (requiring everyone  
who relied on it to retool from the ground up), or that implementors will  
end up supporting two systems, and every small semantic divergence between  
the two (names for a term, parameters required, …) will end up being a  
minefield of error-correction and bugtrapping.



I'm having trouble understanding why this proposal is facing such stop
energy.


I don't think there is any stop energy - I don't see anyone saying let's  
not work on making it easier to build apps that work whether installed or  
online, whether built as responsive to their environment or rebuilt each  
time. I see a bunch of poeple warning you that they have been doing this  
work for many years already, that there are real deployments and there is  
a lot of experience with real user feedback (e.g. I'd like a faster horse  
please) and the sort of things that are and aren't problems at a higher  
level (e.g. digital signatures are really hard or Apple's claimed  
patent on auto-update systems is a non-issue if you implement the way  
everyone else does, otherwise it might have to be looked at more deeply if  
you don't want to invite a lawyer-fest into your ecosystem).


Please, continue the discussion, but it is reasonable to expect that  
people will question things quite closely if you expect a global industry  
to invest millions of dollars in something...


cheers

Chaals


On Tue, Jul 23, 2013 at 8:12 AM, Marcos Caceres w...@marcosc.com wrote:





On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:


 On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres  
w...@marcosc.com(mailto:

w...@marcosc.com) wrote:
 
  On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote:
 
   To clarify, I am proposing that we make a simple app manifest  
entry
the only requirement for widget declaration: widget: { launch_path: ...  
}.

The issue with viewMode (https://github.com/w3c/manifest/issues/22), is
that it hard-binds a widget's launch URL to the app's launch URL,  
forever

tying the widget to the full app. I'd like to give devs the option to
provide a completely different launch path for widgets, if they choose.  
As

for the finer points of widget declaration, why force developers to
generate two separate files that regurgitate much of the same  
information?
-- this looks a lot more complex than adding a launch path to an  
existing

file and a few media queries for styling:

Re: [widgetsapi] reference to WebIDL

2013-07-30 Thread Yves Lafon

On Tue, 30 Jul 2013, Marcos Caceres wrote:





On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:


Hi,
In the PR [1], the text referencing WebIDL is not using one of the three
conformance clauses defined in WebIDL [2].

Could
This specification uses [WebIDL] to specify application programming
interfaces. be clarified using one of the proposed wordings from WebIDL?
(likely 'Conforming IDL Fragments' per reading of the spec).
Thanks,




Sure, I can add that if you think it will be helpful.


Yes, that would be helpful (hence the report), thanks.

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves




Re: [widgetsapi] reference to WebIDL

2013-07-30 Thread Marcos Caceres



On Tuesday, July 30, 2013 at 2:20 PM, Yves Lafon wrote:

 On Tue, 30 Jul 2013, Marcos Caceres wrote:
 
  
  
  
  On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:
  
   Hi,
   In the PR [1], the text referencing WebIDL is not using one of the three
   conformance clauses defined in WebIDL [2].
   
   Could
   This specification uses [WebIDL] to specify application programming
   interfaces. be clarified using one of the proposed wordings from WebIDL?
   (likely 'Conforming IDL Fragments' per reading of the spec).
   Thanks,
  
  
  
  
  Sure, I can add that if you think it will be helpful.
 
 Yes, that would be helpful (hence the report), thanks.

Done. Spec now sez:
Implementations that use ECMAScript to implement the APIs defined in this 
specification must implement them in a manner consistent with the ECMAScript 
Bindings defined in the Web IDL specification [WebIDL], as this specification 
uses that specification and terminology.

 

-- 
Marcos Caceres






Re: [widgetsapi] reference to WebIDL

2013-07-30 Thread Marcos Caceres


On Tuesday, July 30, 2013 at 5:46 PM, Marcos Caceres wrote:

 
 
 
 On Tuesday, July 30, 2013 at 2:20 PM, Yves Lafon wrote:
  
  Yes, that would be helpful (hence the report), thanks.
 
 Done. Spec now sez:
 Implementations that use ECMAScript to implement the APIs defined in this 
 specification must implement them in a manner consistent with the ECMAScript 
 Bindings defined in the Web IDL specification [WebIDL], as this specification 
 uses that specification and terminology.
 


Whoops. Seems I misunderstood. The spec actually now says:
The IDL blocks in this specification are conforming IDL fragments as defined 
by the WebIDL specification. 









[Bug 22840] New: JSON response and user defined JSON.parse

2013-07-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22840

Bug ID: 22840
   Summary: JSON response and user defined JSON.parse
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: a...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

http://xhr.spec.whatwg.org/#json-response-entity-body

Should we use the original JSON.parse? Right now it seems to imply that we will
just call any JSON.parse, allowing users to override it if they want.

-- 
You are receiving this mail because:
You are on the CC list for the bug.