RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Wonsuk Lee]

Hi. Marcos.

> -Original Message-
> From: Marcos Caceres [mailto:w...@marcosc.com]
> Sent: Friday, November 01, 2013 12:24 AM
> To: Nilsson, Claes1
> Cc: Arthur Barstow; public-webapps; public-sysa...@w3.org
> Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting
> at TPAC?
> 
> 
> 
> On Thursday, October 31, 2013 at 3:04 PM, Nilsson, Claes1 wrote:
> 
> > I want to say that we are interested in implementing the JSON manifest
> and also to discuss additions to the manifest. Content security policies
> have already been mentioned and we are looking at something similar to
> http://developer.chrome.com/extensions/contentSecurityPolicy.html, which
> allows inclusion of content security policies to support secure hosted
> apps by defining schemes (https:) that are allowed to use for whitelisting
> secure origins from which scripts should be accepted.
> 
> This is orthogonal to the manifest, as web apps can already do this.
> Adding this to the manifest would only be sugar to allow developers to
> tighten the CSP.
> > I would also like to better understand what a meta tag solution would
> mean.
> 
> 
> See:
> https://developer.apple.com/library/safari/documentation/AppleApplications
> /Reference/SafariHTMLRef/Articles/MetaTags.html
> 
> And:
> https://developers.google.com/chrome/mobile/docs/installtohomescreen
> 
> So, some standardized thing of the above (without the proprietary prefixes,
> of course).
> 
> > However, as the manifest specification editor Marcos unfortunately is
> not able to participate in TPAC I am not sure on the most efficient way to
> discuss the manifest, a joint SysApps-WebApps session with Marcos calling
> in or a mailing list discussion.
> 
> I’m happy to dial in, but would like to know specially what people want to
> discuss about it.
> 
> > My main point is to stress our interest in the manifest specification
> and additions to it.
> >
> 
> I think it’s more important to understand the use cases, and then we can
> evaluate if the manifest is the appropriate place to address those.
> 

I think one of big benefit with manifest format is we can use hyperlink for 
that. User can install a web app with manifest format, no need to visit a site. 
 So manifest can provide more smooth way of installation to user. They can 
install apps via links in blogs, twitter, facebook, extra. What do you think?

Kr, Wonsuk.

Re: CfC: publish WD of Streams API; deadline Nov 3

[Rob Manson]

Sounds good.

Thanks.

roBman


On 1/11/13 4:43 PM, Feras Moussa wrote:

Yes, WebSockets was missing - I've gone ahead and updated the spec to include 
it.

Thanks for sharing the links, the content is well thought out. In particular, 
your diagram does a good job summarizing some of the key consumers and 
producers that come to play regarding Streams. I'll review it in detail.

DataChannels also seem like a possible candidate, although I'm not yet very 
familiar with them. This can be something reviewed and thought through, and 
added accordingly.


  Who is coordinating each group that should get involved? MediaStream for 
example should be based on the Stream interface and all related streams 
proposals.

Once we come to a consensus in the WG what Streams look like and their role, we 
can begin to coordinate what the impact is on other groups.

Thanks,
Feras




Date: Fri, 1 Nov 2013 16:05:22 +1100
From: rob...@mob-labs.com
To: public-webapps@w3.org
Subject: Re: CfC: publish WD of Streams API; deadline Nov 3

Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are
also missing.

And I think Aymeric's point about MediaStream is important too...but
there is very strong push-back from within the Media Capture & Streams
TF that they don't think this is relevant 8/

Also, here's a couple of links for things I've shared/proposed recently
related to this.

public message
http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html

presentation
http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13

code
https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml


All thoughts and feedback welcome.


roBman


On 29/10/13 10:22 PM, Aymeric Vitte wrote:

I have suggested some additions/changes in my latest reply to the
Overlap thread.

The list of streams producers/consumers is not final but obviously
WebSockets are missing.

Who is coordinating each group that should get involved? MediaStream
for example should be based on the Stream interface and all related
streams proposals.

Regards,

Aymeric

Le 28/10/2013 16:29, Arthur Barstow a écrit :

Feras and Takeshi have begun merging their Streams proposal and this
is a Call for Consensus to publish a new WD of Streams API using the
updated ED as the basis:



Please note the Editors may update the ED before the TR is published
(but they do not intend to make major changes during the CfC).

Agreement to this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support of the contents of
the WD.

If you have any comments or concerns about this proposal, please
reply to this e-mail by November 3 at the latest. Positive response
to this CfC is preferred and encouraged and silence will be assumed
to mean agreement with the proposal.

-Thanks, ArtB

RE: CfC: publish WD of Streams API; deadline Nov 3

[Feras Moussa]

Yes, WebSockets was missing - I've gone ahead and updated the spec to include 
it.

Thanks for sharing the links, the content is well thought out. In particular, 
your diagram does a good job summarizing some of the key consumers and 
producers that come to play regarding Streams. I'll review it in detail.

DataChannels also seem like a possible candidate, although I'm not yet very 
familiar with them. This can be something reviewed and thought through, and 
added accordingly.

> Who is coordinating each group that should get involved? MediaStream for 
>example should be based on the Stream interface and all related streams 
>proposals.

Once we come to a consensus in the WG what Streams look like and their role, we 
can begin to coordinate what the impact is on other groups.

Thanks,
Feras



> Date: Fri, 1 Nov 2013 16:05:22 +1100
> From: rob...@mob-labs.com
> To: public-webapps@w3.org
> Subject: Re: CfC: publish WD of Streams API; deadline Nov 3
>
> Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are
> also missing.
>
> And I think Aymeric's point about MediaStream is important too...but
> there is very strong push-back from within the Media Capture & Streams
> TF that they don't think this is relevant 8/
>
> Also, here's a couple of links for things I've shared/proposed recently
> related to this.
>
> public message
> http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html
>
> presentation
> http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13
>
> code
> https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml
>
>
> All thoughts and feedback welcome.
>
>
> roBman
>
>
> On 29/10/13 10:22 PM, Aymeric Vitte wrote:
>> I have suggested some additions/changes in my latest reply to the
>> Overlap thread.
>>
>> The list of streams producers/consumers is not final but obviously
>> WebSockets are missing.
>>
>> Who is coordinating each group that should get involved? MediaStream
>> for example should be based on the Stream interface and all related
>> streams proposals.
>>
>> Regards,
>>
>> Aymeric
>>
>> Le 28/10/2013 16:29, Arthur Barstow a écrit :
>>> Feras and Takeshi have begun merging their Streams proposal and this
>>> is a Call for Consensus to publish a new WD of Streams API using the
>>> updated ED as the basis:
>>>
>>> 
>>>
>>> Please note the Editors may update the ED before the TR is published
>>> (but they do not intend to make major changes during the CfC).
>>>
>>> Agreement to this proposal: a) indicates support for publishing a new
>>> WD; and b) does not necessarily indicate support of the contents of
>>> the WD.
>>>
>>> If you have any comments or concerns about this proposal, please
>>> reply to this e-mail by November 3 at the latest. Positive response
>>> to this CfC is preferred and encouraged and silence will be assumed
>>> to mean agreement with the proposal.
>>>
>>> -Thanks, ArtB
>>>
>>
>
> 

Re: CfC: publish WD of Streams API; deadline Nov 3

[Rob Manson]

Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are 
also missing.


And I think Aymeric's point about MediaStream is important too...but 
there is very strong push-back from within the Media Capture & Streams 
TF that they don't think this is relevant 8/


Also, here's a couple of links for things I've shared/proposed recently 
related to this.


public message
http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html

presentation
http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13

code
https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml 



All thoughts and feedback welcome.


roBman


On 29/10/13 10:22 PM, Aymeric Vitte wrote:
I have suggested some additions/changes in my latest reply to the 
Overlap thread.


The list of streams producers/consumers is not final but obviously 
WebSockets are missing.


Who is coordinating each group that should get involved? MediaStream 
for example should be based on the Stream interface and all related 
streams proposals.


Regards,

Aymeric

Le 28/10/2013 16:29, Arthur Barstow a écrit :
Feras and Takeshi have begun merging their Streams proposal and this 
is a Call for Consensus to publish a new WD of Streams API using the 
updated ED as the basis:




Please note the Editors may update the ED before the TR is published 
(but they do not intend to make major changes during the CfC).


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of 
the WD.


If you have any comments or concerns about this proposal, please 
reply to this e-mail by November 3 at the latest. Positive response 
to this CfC is preferred and encouraged and silence will be assumed 
to mean agreement with the proposal.


-Thanks, ArtB

RE: publish WD of Streams API; deadline Nov 3

[Feras Moussa]

Agreed. Some of the points listed appear to be things already addressed. 
Takeshi and I have some feedback on the initial mail, but will wait and provide 
thoughts on the proposal instead. Looking forward to seeing it.


> From: tyosh...@google.com 
> Date: Fri, 1 Nov 2013 12:18:47 +0900 
> To: ann...@annevk.nl 
> CC: dome...@domenicdenicola.com; art.bars...@nokia.com; public-webapps@w3.org 
> Subject: Re: publish WD of Streams API; deadline Nov 3 
> 
> OK. There seems to be some disconnect, but I'm fine with waiting for 
> Domenic's proposal first. 
> 
> Takeshi 
> 
> 
> On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren 
> mailto:ann...@annevk.nl>> wrote: 
> On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola 
> mailto:dome...@domenicdenicola.com>> wrote: 
>> I have concrete suggestions as to what such an API could look 
> like—and, more importantly, how its semantics would significantly 
> differ from this one—which I hope to flesh out and share more broadly 
> by the end of this weekend. However, since the call for comments phase 
> has commenced, I thought it important to voice these objections as soon 
> as possible. 
> 
> Given how long we have been trying to figure out streams, waiting a 
> little longer to see Domenic's proposal should be fine I think. No 
> need to start rushing things through the process now. (Although on the 
> flipside at some point we will need to start shipping something.) 
> 
> 
> -- 
> http://annevankesteren.nl/ 
> 
> 

Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)

[Takeshi Yoshino]

On Thu, Oct 31, 2013 at 4:48 PM, François REMY <
francois.remy@outlook.com> wrote:

>  Since JavaScript does not provide a way to check if an object implements
> an interface, there should probably exist a way to check that from the API,
> like:
>

Basically it should be sufficient if each API can check type, but yeah
probably useful.


> var stream = InputStream(s) // returns “s” if it’s an input stream,
> convert is into a stream if possible, or return null
>if(stream) { … } else { … }
>
> That’s a great way to convert a string into a stream, for example, in the
> case of an API that requires an InputStream and must integrate with older
> code that returns a String or a Blob.
>

Interesting. Maybe also accept an array of strings?

Re: publish WD of Streams API; deadline Nov 3

[Takeshi Yoshino]

OK. There seems to be some disconnect, but I'm fine with waiting for
Domenic's proposal first.

Takeshi


On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren  wrote:

> On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola
>  wrote:
> > I have concrete suggestions as to what such an API could look like—and,
> more importantly, how its semantics would significantly differ from this
> one—which I hope to flesh out and share more broadly by the end of this
> weekend. However, since the call for comments phase has commenced, I
> thought it important to voice these objections as soon as possible.
>
> Given how long we have been trying to figure out streams, waiting a
> little longer to see Domenic's proposal should be fine I think. No
> need to start rushing things through the process now. (Although on the
> flipside at some point we will need to start shipping something.)
>
>
> --
> http://annevankesteren.nl/
>
>

[Bug 23431] File API should say what to do with the query string in blob: URLs

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23431

Glenn Maynard  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||gl...@zewt.org
 Resolution|FIXED   |---

--- Comment #4 from Glenn Maynard  ---
I don't think it needs to say anything.  Specs say what to do, not what not to
do; if it doesn't say to do anything with the query parameter, then nothing is
done with the query parameter.

The language now in the spec is confusing: it doesn't clearly mean anything,
and might be interpreted to mean something wrong.  For example, if you parse a
blob URL with new URL(blobURL), clearly the .search attribute of the result
should include the query, even if it's a blob URL.  The vague language "must
ignore a query string" might be interpreted to contradict that, as if the file
API spec is implicitly monkey-patching the URL spec.

If the intent is to ensure that appending "?foo" to a blob URL doesn't affect
resolving the resource, then you probably just want to define which parts of
the parsed URL are the unique identifier.  With the URL spec's terminology, it
looks like the identifying part is the "scheme data" (which doesn't include the
query or the fragment).

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

[Bug 23310] bugs in WebIDL fragments

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23310

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Arun  ---
Fixed.

Will ask bzbarsky and heycam about the remaining error using constant methods.

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

[Bug 23416] Introduce new concept of neutered

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23416

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Arun  ---
(In reply to Ian 'Hixie' Hickson from comment #11)
> The concept of "neutered" in the Transferable sense is "this can't be
> transferred any more". Anything that isn't Transferable is always in that
> state, so it doesn't make sense to talk about other things being neutered in
> the Transferable sense.
> 
> If File and Blob should be Transferable (meaning they can't be cloned, or
> that cloning them is an expensive operation), then that's a different
> matter. My understanding is that that is not the case currently.
> 
> 
> I really don't understand the problem here. It's fine to be able to send the
> object into a different state. Lots of objects do this. WebSocket objects
> can get closed. Windows can get closed. XMLHttpRequest objects can go into
> several states. And so on.

Blobs aren't going to be Transferable -- they don't need to be.

You're right: it isn't a big deal to roll a new one. 
http://dev.w3.org/2006/webapi/FileAPI/#dfn-close

Marking this fixed.

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

[Bug 23431] File API should say what to do with the query string in blob: URLs

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23431

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Arun  ---
Fixed.
http://dev.w3.org/2006/webapi/FileAPI/#queryString

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

[widgets] Widget Interface is a W3C Recommendation

[Arthur Barstow]

A Recommendation of "Widget Interface" was published today:

  <http://www.w3.org/TR/2013/REC-widgets-apis-20131031/>

Congratulations Marcos!

This publication means that of WebApps' 7 widget related documents, 5 
are now Recommendations and the other 2 are WG Notes. As such, the 
group's widget spec work is `completed`.


I added the following to the group's `Charter Updates` wiki as a 
reminder that if/when WebApps' charter is updated, we have a decision 
point re widgets:


[[
<http://www.w3.org/wiki/Webapps/Charter#Potential_Deletions>

* Widgets - WebApps published 5 widget-related Recommendations ^1. When 
the group next updates the charter, should the widget specs all be 
removed? What about their maintenance?

]]

-AB

^1 <http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications>

RfC: LCWD of Pointer Lock; deadline November 28

[Arthur Barstow]

This is a Request for Comments for the Last Call Working Draft of 
Pointer Lock:


  <http://www.w3.org/TR/2013/WD-pointerlock-20131031/>

If you have any comments, please send them to public-webapps @ w3.org by 
November 28 using a Subject: header of "[pointerlock]".


-Thanks, AB

[Bug 23451] Error Attribute Setting and Error Event Firing Currently Have Backwards Order

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23451

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Arun  ---
Fixed.

http://dev.w3.org/2006/webapi/FileAPI/#dfn-error-steps

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

[Bug 23319] 第6.4.1.节,多了个右括号

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23319

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Arun  ---
Fixed this in editor's draft.

http://dev.w3.org/2006/webapi/FileAPI/#slice-method-algo

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

Re: [FileAPI]

[Arun Ranganathan]

Note that all LC Commentary, including that sent on this listserv, is tracked 
here: 
http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912

-- A*
On Oct 31, 2013, at 9:12 AM, Arthur Barstow wrote:

> Hi,
> 
> For the purposes of tracking your comments for the September 12 File API Last 
> Call Working Draft, please let us know if Arun's reply is satisfactory or 
> not. In the absence of a reply from you by November 7, we will assume Arun's 
> reply is OK with you.
> 
> -Thanks, ArtB
> 
> On 10/23/13 6:04 PM, ext Arun Ranganathan wrote:
>> Hi there!
>> 
>> 
>> On Oct 23, 2013, at 12:32 PM, psweatte wrote:
>> 
>>> 7.2 Interface File:
>>> -add creationDate property
>> 
>> Thanks for your feedback.  *Most* filesystems don't really have a creation 
>> time.  While Windows does, Unix-style OS return the *change time" or last 
>> modified time.  Since we want fidelity with OS filesystems wherever 
>> possible, I'm not sure this is a viable property to add.
>> 
>> 
>>> -add size property
>> This already exists via the inheritance relationship with Blob.
>> 
>> 
>>> -If the last modification date and time are not known, the attribute must 
>>> return an empty string
>> 
>> Currently the spec says to return the current date and time.  It's a Date 
>> not a String.
>> 
>> 
>>> 8.3. Event Handler Attributes
>> 
>> I think the current set of event handler attributes is sufficient, 
>> especially given the backdrop of event models in general not being the best 
>> way to asynchronously access large data sets such as File and Blob.
>> 
>> 
>>> -add onNotfounderror event handler
>>> -add onReaderror event handler
>>> -add onSecurityerror event handler
>>> -add onHTTPerror event handler
>>> -add onSelectfrombrowse event handler
>>> 
>>> 
>>> 
>> 
> 
> 

Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Marcos Caceres]

On Thursday, October 31, 2013 at 3:04 PM, Nilsson, Claes1 wrote:

> I want to say that we are interested in implementing the JSON manifest and 
> also to discuss additions to the manifest. Content security policies have 
> already been mentioned and we are looking at something similar to 
> http://developer.chrome.com/extensions/contentSecurityPolicy.html, which 
> allows inclusion of content security policies to support secure hosted apps 
> by defining schemes (https:) that are allowed to use for whitelisting secure 
> origins from which scripts should be accepted.

This is orthogonal to the manifest, as web apps can already do this. Adding 
this to the manifest would only be sugar to allow developers to tighten the 
CSP.  
> I would also like to better understand what a meta tag solution would mean.


See:  
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html

And:
https://developers.google.com/chrome/mobile/docs/installtohomescreen

So, some standardized thing of the above (without the proprietary prefixes, of 
course).  

> However, as the manifest specification editor Marcos unfortunately is not 
> able to participate in TPAC I am not sure on the most efficient way to 
> discuss the manifest, a joint SysApps-WebApps session with Marcos calling in 
> or a mailing list discussion.

I’m happy to dial in, but would like to know specially what people want to 
discuss about it.  
  
> My main point is to stress our interest in the manifest specification and 
> additions to it.
>  

I think it’s more important to understand the use cases, and then we can 
evaluate if the manifest is the appropriate place to address those.   

Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Anders Rundgren]

On 2013-10-31 16:04, Nilsson, Claes1 wrote:
> I want to say that we are interested in implementing the JSON manifest and 
> also to discuss additions to the manifest. Content security policies have 
> already been mentioned and we are looking at something similar to 
> http://developer.chrome.com/extensions/contentSecurityPolicy.html, which 
> allows inclusion of content security policies to support secure hosted apps 
> by defining schemes (https:) that are allowed to use for whitelisting secure 
> origins from which scripts should be accepted.

http://developer.chrome.com/extensions/manifest.html

The definition of the signature seems to be missing here.
If JSON still is the choice, JWS 
(http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17) or JCS 
(https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf)
 are the two hottest candidates.

Cheers
Anders

> 
> I would also like to better understand what a meta tag solution would mean.
> 
> However, as the manifest specification editor Marcos unfortunately is not 
> able to participate in TPAC I am not sure on the most efficient way to 
> discuss the manifest, a joint SysApps-WebApps session with Marcos calling in 
> or a mailing list discussion.
> 
> My main point is to stress our interest in the manifest specification and 
> additions to it.
> 
> BR
>   Claes
> 
>> -Original Message-
>> From: Marcos Caceres [mailto:w...@marcosc.com]
>> Sent: den 31 oktober 2013 15:20
>> To: Arthur Barstow
>> Cc: public-webapps; public-sysa...@w3.org
>> Subject: Re: [coord] Is there still a need for WebApps + SysApps
>> meeting at TPAC?
>>
>> On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote:
>>> [ My apologies in advance for cross-posting but I think it's needed
>>> for this coordination topic. ]
>>>
>>> Hi All,
>>>
>>> Last June, the Chairs of WebApps and SysApps agreed to allocate a
>> time
>>> slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday
>>> November 11 [1].
>>>
>>> The one topic currently identified for that slot is the Manifest spec.
>>>
>>> Marcos - would you please summarize the overall `state` of the
>>> Manifest spec (f.ex. the status, next steps, blockers, and such)? I
>>> would also like to know if you think there are some related issues
>>> that could potentially benefit from some meeting time, or if we can
>>> use the list server instead.
>>
>>
>> I’m trying to figure out (or get agreement amongst those interested in
>> implementing) if we should have a JSON manifest or go with the meta tag
>> solution (or both) - this is a blocker. Current steps are for me to
>> investigate the solutions and usage on teh Webs.
>>
>> No significant work has been done on the spec since it moved over to
>> WebApps.
>>
>> I don’t mind if we do it on the list. But if others want me to dial in
>> to discuss, I’m ok to do that.
>>
>>> All - are there any other topics to discuss?
>>>
>>
>>
>> Not from me.
>>
>> --
>> Marcos Caceres
>>
>>
>>
> 

RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Nilsson, Claes1]

I want to say that we are interested in implementing the JSON manifest and also 
to discuss additions to the manifest. Content security policies have already 
been mentioned and we are looking at something similar to 
http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows 
inclusion of content security policies to support secure hosted apps by 
defining schemes (https:) that are allowed to use for whitelisting secure 
origins from which scripts should be accepted.

I would also like to better understand what a meta tag solution would mean.

However, as the manifest specification editor Marcos unfortunately is not able 
to participate in TPAC I am not sure on the most efficient way to discuss the 
manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing 
list discussion.

My main point is to stress our interest in the manifest specification and 
additions to it.

BR
  Claes

> -Original Message-
> From: Marcos Caceres [mailto:w...@marcosc.com]
> Sent: den 31 oktober 2013 15:20
> To: Arthur Barstow
> Cc: public-webapps; public-sysa...@w3.org
> Subject: Re: [coord] Is there still a need for WebApps + SysApps
> meeting at TPAC?
> 
> On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote:
> > [ My apologies in advance for cross-posting but I think it's needed
> > for this coordination topic. ]
> >
> > Hi All,
> >
> > Last June, the Chairs of WebApps and SysApps agreed to allocate a
> time
> > slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday
> > November 11 [1].
> >
> > The one topic currently identified for that slot is the Manifest spec.
> >
> > Marcos - would you please summarize the overall `state` of the
> > Manifest spec (f.ex. the status, next steps, blockers, and such)? I
> > would also like to know if you think there are some related issues
> > that could potentially benefit from some meeting time, or if we can
> > use the list server instead.
> 
> 
> I’m trying to figure out (or get agreement amongst those interested in
> implementing) if we should have a JSON manifest or go with the meta tag
> solution (or both) - this is a blocker. Current steps are for me to
> investigate the solutions and usage on teh Webs.
> 
> No significant work has been done on the spec since it moved over to
> WebApps.
> 
> I don’t mind if we do it on the list. But if others want me to dial in
> to discuss, I’m ok to do that.
> 
> > All - are there any other topics to discuss?
> >
> 
> 
> Not from me.
> 
> --
> Marcos Caceres
> 
> 
> 

Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Marcos Caceres]

On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote:
> [ My apologies in advance for cross-posting but I think it's needed for  
> this coordination topic. ]
>  
> Hi All,
>  
> Last June, the Chairs of WebApps and SysApps agreed to allocate a time  
> slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday  
> November 11 [1].
>  
> The one topic currently identified for that slot is the Manifest spec.
>  
> Marcos - would you please summarize the overall `state` of the Manifest  
> spec (f.ex. the status, next steps, blockers, and such)? I would also  
> like to know if you think there are some related issues that could  
> potentially benefit from some meeting time, or if we can use the list  
> server instead.

  
I’m trying to figure out (or get agreement amongst those interested in 
implementing) if we should have a JSON manifest or go with the meta tag 
solution (or both) - this is a blocker. Current steps are for me to investigate 
the solutions and usage on teh Webs.  

No significant work has been done on the spec since it moved over to WebApps.   

I don’t mind if we do it on the list. But if others want me to dial in to 
discuss, I’m ok to do that.  

> All - are there any other topics to discuss?
>  


Not from me.  

--  
Marcos Caceres

Re: [FileAPI]

[Arthur Barstow]

Hi,

For the purposes of tracking your comments for the September 12 File API 
Last Call Working Draft, please let us know if Arun's reply is 
satisfactory or not. In the absence of a reply from you by November 7, 
we will assume Arun's reply is OK with you.


-Thanks, ArtB

On 10/23/13 6:04 PM, ext Arun Ranganathan wrote:

Hi there!


On Oct 23, 2013, at 12:32 PM, psweatte wrote:


7.2 Interface File:
-add creationDate property


Thanks for your feedback.  *Most* filesystems don't really have a creation time.  
While Windows does, Unix-style OS return the *change time" or last modified 
time.  Since we want fidelity with OS filesystems wherever possible, I'm not sure 
this is a viable property to add.



-add size property

This already exists via the inheritance relationship with Blob.



-If the last modification date and time are not known, the attribute must 
return an empty string


Currently the spec says to return the current date and time.  It's a Date not a 
String.



8.3. Event Handler Attributes


I think the current set of event handler attributes is sufficient, especially 
given the backdrop of event models in general not being the best way to 
asynchronously access large data sets such as File and Blob.



-add onNotfounderror event handler
-add onReaderror event handler
-add onSecurityerror event handler
-add onHTTPerror event handler
-add onSelectfrombrowse event handler

[coord] Is there still a need for WebApps + SysApps meeting at TPAC?

[Arthur Barstow]

[ My apologies in advance for cross-posting but I think it's needed for 
this coordination topic. ]


Hi All,

Last June, the Chairs of WebApps and SysApps agreed to allocate a time 
slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday 
November 11 [1].


The one topic currently identified for that slot is the Manifest spec.

Marcos - would you please summarize the overall `state` of the Manifest 
spec (f.ex. the status, next steps, blockers, and such)? I would also 
like to know if you think there are some related issues that could 
potentially benefit from some meeting time, or if we can use the list 
server instead.


All - are there any other topics to discuss?

(I'm trying to get a sense if this meeting should be canceled or perhaps 
reduced to 30 mins.)


-Thanks, AB

[1] 
 

Re: publish WD of Streams API; deadline Nov 3

[Anne van Kesteren]

On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola
 wrote:
> I have concrete suggestions as to what such an API could look like—and, more 
> importantly, how its semantics would significantly differ from this one—which 
> I hope to flesh out and share more broadly by the end of this weekend. 
> However, since the call for comments phase has commenced, I thought it 
> important to voice these objections as soon as possible.

Given how long we have been trying to figure out streams, waiting a
little longer to see Domenic's proposal should be fine I think. No
need to start rushing things through the process now. (Although on the
flipside at some point we will need to start shipping something.)


-- 
http://annevankesteren.nl/

Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)

[François REMY]

Yes, having the InputStream and OutputStream interfaces would be great, and the 
“Stream” class could inherit from both. The important thing is that an external 
API can return either a readable or a writable stream, depending on what make 
sense for it.



Since JavaScript does not provide a way to check if an object implements an 
interface, there should probably exist a way to check that from the API, like:


   var stream = InputStream(s) // returns “s” if it’s an input stream, convert 
is into a stream if possible, or return null

   if(stream) { … } else { … }


That’s a great way to convert a string into a stream, for example, in the case 
of an API that requires an InputStream and must integrate with older code that 
returns a String or a Blob.









De : Takeshi Yoshino
Envoyé : ‎jeudi‎ ‎31‎ ‎octobre‎ ‎2013 ‎04‎:‎45
À : François REMY
Cc : Arthur Barstow, public-webapps@w3.org





Hi François



On Thu, Oct 31, 2013 at 6:16 AM, François REMY  
wrote:


- Streams should exist in at least two fashions: InputStream and OutputStream. 
Both of them serve different purposes and, while some stream may actually be 
both, this remains an exceptional behavior worth being noted. Finally, a 
"Stream" is not equal to a InMemoryStream as the constructor may seem to 
indicate. A stream is a much lower-level concept, which may actually have 
nothing to do with InMemory operations.




Yes. I initially thought it'll be clearer to split in/out interface. E.g. a 
Stream obtained from XHR to receive a response should not be writable. It's 
reasonable to make network-to-Stream transfer happen in background 
asynchronously to JavaScript, and then it doesn't make much sense to keep it 
writable from JavaScript.




It has a unified IDL now but I'm designing write side and read side 
independently. We could decouple it into two separate IDLs? concepts? if it 
make sense. Stream would inherit from both and provides a constructor.