from:"イアンフェッティ"

This thread seems to have languished, and I'm trying to figure out how to
move forward here.

My understanding, grossly simplified, of the current state of the world is
this:

1. Some people have a desire to show HTML / interactive notifications, to
support use cases like remind me of this calendar event again in 5 minutes
or Answer this call / hang up this call.
2. Some people have a concern that the proposed way to achieve 1, namely
allowing HTML, will result in certain platform notification systems (Growl,
NotifyOSD etc) not to be used.

I will disclose my biases up front and say that I do believe the use cases
that 1) tries to support are important. (I want to be able to interact with
a calendar notification to say remind me again or take me to the full
details of the event, for instance). I also am of the belief regarding #2,
being unable to find any actual data on how many users have and use growl,
that the user base falls into roughly two camps. There's the people who have
gone out and downloaded Growl (or another notification service) because they
want everything coalesced, and then there's the people who don't really
care, and if mail.app wants to tell them something vs their browser wants to
tell them something, they don't really think much of it.

I think that initially, we can do a lot more for this second group in terms
of functionality that we can provide, and would find it unfortunate if we
held up forward progress because of a current implementation detail. If that
functionality proves to be useful and desired by a number of users, I
believe that platforms like Growl and NotifyOSD will find a way to make it
work. In the meantime though, I think there are relatively simple things we
can do to not leave these users in the dark.

1, for the CreateHTMLNotification call, we could still allow a text version
of the notification to be provided. If there's a significant number of users
whose platforms don't support HTML Notifications, I think there's a
reasonable chance that would be filled out. If 20% of users didn't see
images, alt= text would be more prevalent.
2. For the case where there is no text alternative provided by the website
for the HTML notification, the UA can make a best effort at transforming the
HTML notification to a text notification, optionally with whatever markup
the UA provides for text notifications (bold, links, etc). Obviously things
may not be perfect and it would be preferable if the author of the page
provided a notification, but the world is not perfect.
3. Let the user decide which notification mechanism they prefer. If the user
prefers HTML notifications, then they get whatever the UA implements. If the
user has an alternate notification provider they prefer, then they live with
the constraints of that notification system, but either way it's a tradeoff
that the user can make. And yes, in the near term some of this may be
prohibitive on mobile devices, but so are many things (try as they might,
mobile browsers still aren't a pleasure to work with when it comes to
viewing large complex sites or sites that use flash, etc).

I strongly believe that web applications are increasing in number, in scope,
and are becoming an integral part of people's lives. As web applications
expand, I don't think it is unreasonable to believe that support for HTML in
the platform (e.g. HTML in notification providers) will happen some day.
It's not going to be immediate, and so I have outlined some ideas that I
hope may get us moving in the meanwhile, but I don't want us to fall victim
to the argument of well, right now it's hard so let's not do it.

My $0.02.

Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com:


 On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com wrote:

 On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote:



 On Feb 11, 2010, at 16:07, Jeremy Orlow wrote:

  As has been brought up repeatedly, growl and the other notification
 engines are used by a SMALL FRACTION of all web users.  I suspect a fraction
 of a percent.  Why are we bending over backwards to make this system work on
 those platforms?

 More seriously though: Virtually every user of an up-to-date Ubuntu
 installation has the notification engine installed. As for Growl, the kind
 of users who install Growl are presumably the kind of users who care about
 notifications of multiple concurrent things the most. Furthermore, it seems
 that notifications are becoming more a part of operating system platfroms.
 For example, it looks like Windows 7 has a system API for displaying
 notifications:
 http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx

 This is a useful data point. It does seem like the major platforms are
 conforming to a simple icon + title + text interface for ambient
 notifications. The microsoft API seems more aligned with NotifyOSD
 (non-interactable notifications with a transient status tray icon provided
 to allow the user to click). I

Re: Notifications

Doug -

I did not mean to be HTML centric, apologies. I'm currently going through a
debate in my mind (scary thing) about whether allowing an arbitrary mime
type and content would be good or bad. My gut sense here is that if the UA
is capable of displaying it, we should allow it, and it will be used or not
used (with fallbacks provided) based on the support of UAs, with more UAs
evolving to support it as user demand grows. Ideally we would provide
multiple fallbacks, e.g. allow someone to specify an ordered list in order
of preference, e.g. text/html representation followed by image/svg+xml
followed by text/plain (although perhaps text/plain is better left broken
out, so that it's more visible and people actually fill it in, as opposed to
being some option in a list of things you can provide).

e.g.

CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional]
in DOMString MimeType2, [Optional] NotificationFormat2, ...)

forgive my broken IDL, I'm sure there's a better way to express it, but you
get the idea.

At any rate, I'm not opposed to what you propose, just trying to think out
loud of how to best do that while still ensuring that a text fallback is
still reasonably simple (and obvious) to specify.

-Ian

Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org:

 Hi, Ian-

 I generally agree with you, and certainly with your sentiment.  Not to go
 all SVG on you, but why *HTMLNotification?  I understand that HTML is
 really common, and that increasingly SVG can be used as part of HTML, but
 there are lots of devices out there (TVs, mobiles, set-top boxes) that use
 SVG rather than HTML, which would benefit from these interactive
 notifications... shouldn't we define a more generic CreateWebNotification
 and pass an optional MIME Type parameter that defaults to text/html (or
 some similar mechanism)?

 I strongly agree with the sentiment that we should design for the future,
 in any case, and not limit ourselves to simple text notifications.

 Regards-
 -Doug Schepers
 W3C Team Contact, SVG and WebApps WGs


 Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM):

 This thread seems to have languished, and I'm trying to figure out how
 to move forward here.

 My understanding, grossly simplified, of the current state of the world
 is this:

 1. Some people have a desire to show HTML / interactive notifications,
 to support use cases like remind me of this calendar event again in 5
 minutes or Answer this call / hang up this call.
 2. Some people have a concern that the proposed way to achieve 1, namely
 allowing HTML, will result in certain platform notification systems
 (Growl, NotifyOSD etc) not to be used.

 I will disclose my biases up front and say that I do believe the use
 cases that 1) tries to support are important. (I want to be able to
 interact with a calendar notification to say remind me again or take
 me to the full details of the event, for instance). I also am of the
 belief regarding #2, being unable to find any actual data on how many
 users have and use growl, that the user base falls into roughly two
 camps. There's the people who have gone out and downloaded Growl (or
 another notification service) because they want everything coalesced,
 and then there's the people who don't really care, and if mail.app wants
 to tell them something vs their browser wants to tell them something,
 they don't really think much of it.

 I think that initially, we can do a lot more for this second group in
 terms of functionality that we can provide, and would find it
 unfortunate if we held up forward progress because of a current
 implementation detail. If that functionality proves to be useful and
 desired by a number of users, I believe that platforms like Growl and
 NotifyOSD will find a way to make it work. In the meantime though, I
 think there are relatively simple things we can do to not leave these
 users in the dark.

 1, for the CreateHTMLNotification call, we could still allow a text
 version of the notification to be provided. If there's a significant
 number of users whose platforms don't support HTML Notifications, I
 think there's a reasonable chance that would be filled out. If 20% of
 users didn't see images, alt= text would be more prevalent.
 2. For the case where there is no text alternative provided by the
 website for the HTML notification, the UA can make a best effort at
 transforming the HTML notification to a text notification, optionally
 with whatever markup the UA provides for text notifications (bold,
 links, etc). Obviously things may not be perfect and it would be
 preferable if the author of the page provided a notification, but the
 world is not perfect.
 3. Let the user decide which notification mechanism they prefer. If the
 user prefers HTML notifications, then they get whatever the UA
 implements. If the user has an alternate notification provider they
 prefer

Re: Notifications

Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:

 On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) 
 ife...@google.com wrote:

 CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
 DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
 [Optional]
 in DOMString MimeType2, [Optional] NotificationFormat2, ...)

 forgive my broken IDL, I'm sure there's a better way to express it, but
 you get the idea.


 I don't see why it cannot be just a URL. If the user agent supports the
 type it will render it and it will fail otherwise. There's no need for
 complex multi-level fallback here in my opinion, nobody is going to bother
 with that anyway.


video has multi-level fallback, so there is precedent for better or worse.
That said, specifying a (set of) URL(s) may be fine, but I think it would
still be nice for a UA to have fallback options. Is everyone going to use
it? Probably not, but I think people that actually care would. E.g. if I
have a property that I expect people on mobile devices to go to, I will make
sure that it works on mobile devices, exactly as we do with properties today
where we reasonably expect mobile users.

-Ian




 --
 Anne van Kesteren
 http://annevankesteren.nl/

Re: Notifications

Am 23. Februar 2010 13:44 schrieb Jonas Sicking jo...@sicking.cc:

 2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com:
  Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
 
  On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
  ife...@google.com wrote:
 
  CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
  DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
  [Optional]
  in DOMString MimeType2, [Optional] NotificationFormat2, ...)
 
  forgive my broken IDL, I'm sure there's a better way to express it, but
  you get the idea.
 
  I don't see why it cannot be just a URL. If the user agent supports
 the
  type it will render it and it will fail otherwise. There's no need for
  complex multi-level fallback here in my opinion, nobody is going to
 bother
  with that anyway.
 
  video has multi-level fallback, so there is precedent for better or
 worse.
  That said, specifying a (set of) URL(s) may be fine, but I think it would
  still be nice for a UA to have fallback options. Is everyone going to use
  it? Probably not, but I think people that actually care would. E.g. if I
  have a property that I expect people on mobile devices to go to, I will
 make
  sure that it works on mobile devices, exactly as we do with properties
 today
  where we reasonably expect mobile users.

 Yes, there are several features, such as video and img that have
 fallback. However this is because there is no alternative other than
 simply not introducing these features. I.e. we can't redesign video
 in such a way that fallback for blind people isn't needed, due to
 inherit visual properties of video.

 The same is not true for the suggest notification API. Several
 proposals have been put forward that do not rely on fallback.

 I'm sure that if you ask any blind person they will tell you that the
 amount of fallback provided for img is no where near enough. And I'm
 fairly certain this isn't due to the fact that the majority of web
 authors don't care about blind people.

 So while I agree with some of your arguments, I don't at all buy the
 argument that there are other features out there that use fallback,
 so it's ok here too, or if people care, they'll provide fallback.

 / Jonas


That's not really an accurate restating of my position. I am saying if no
text fallback is specified, let's try to create one from what is given to
us. Unlike with video and images, we actually have a reasonable chance of
being able to create something intelligible here. Not perfect, but a lot
different from the case of here's an image with no alt text, now I will
just cry.

Re: HTML5 File

http://www.w3.org/TR/file-writer-api/

On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@gmail.comwrote:

 I have been reading the specification on file section.
 I would like to ask why not propose that File interface allow a create
 method to let user save data for his use?

 Resume:

 Interface File extends Blob
 {
 attribute unsigned long long currentPosition;
 readonly attribute signed long long deviceSpaceLeft;
 readonly attribute unsigned short machineEndian;
 const unsigned short BIG_ENDIAN = 1;
 const unsigned short LITTLE_ENDIAN = 0;
 const unsigned short UNKNOW_SIZE = -1;
 File create( );
 File createBynary();
 signed long write( in DOMString text, optional in unsigned long long
 position,  optional DOMString fromCharset )
 signed long writeBinary( in DOMString blob, optional in unsgined long
 long position )
 }

 An web application in this way could for example create a list of computed
 values and allow the user to save the contents to a file without need send
 data for the server to pack contents and issue a file download request to
 client.
 Or implement an image editor in javascript code using the new canvas
 element and allow read, create, store to be done without server assistance.
 Work on offline mode too.

 About security on file creation:
 When the web application request this operation File.create() the browser
 could launch a confirm( save file) dialog so the user only could grant the
 rights for a file creation.
 This dialog( modal? ) would manage file overwrite and more stuff related to
 file access( user may write at selected folder ) so that returned file
 reference could be overwritten by client script without trouble.
 The return type for that function could be string or a File object.
 An empty name value or Exception signal that user denied the request.

 If there is concerns about absolute file paths been exposed to javascript
 code
 then the File.create method could return a boolean status indicating that
 the object is ready to write( true ) and no file paths would be exposed at
 all. Or only the basename of file without path information.

 For differences between binary and text modes a second method call could
 signal File object that the new file should be used on binary mode:
 File.createBinary() - same behavior like File.create above but in binary
 mode.

 The file object could have some read only properties for device space
 control:
 For example:
 readonly File.deviceSpaceLeft  - so when script is making write calls to
 file if would know in advance if space still available for writing. Or
 application could launch a warn that no space left to save data. If the
 implementer do not know how to tell the space left then a File.UNKNOWSIZE
 value should be returned.

 double File.currentPosition - traditional File pointer to know where in the
 file the client is writing to. Since size is readonly changing this property
 move the current position in file cursor. Negative values are invalid and
 ignored. A positive value greater then current value increase the file size
 to the new size( doing this at begin could be a way to reserve space needed
 on disk at once since the file would grow to this current size, and help
 filesystem reduce fragmentation ). Changing this attribute on a file opened
 for read does nothing and is ignored. The size atrribute should reflect the
 new size confirming that file size increased.

 May cause UI hangs on large move requests.
 User agents may show on the create dialog a max file size allowed to be
 created making impossible to script consume all space left on device.

 readonly boolean File.machineEndian - binary files on target machine could
 have data stored in different formats then the script reading would expect.
 This flag would tell the script how to pack unpack data to be used on client
 machine.

 Cristiano

Re: HTML5 File

I whole-heartedly agree, and have said as much in the past, both on public
MLs and to various W3C team contacts.

-Ian

On Wed, Jun 2, 2010 at 1:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 It keeps seeming to me that moving the file-writer spec to WebApps
 would make much more sense...

 / Jonas

 2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
  http://www.w3.org/TR/file-writer-api/
 
  On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@gmail.com
  wrote:
 
  I have been reading the specification on file section.
  I would like to ask why not propose that File interface allow a create
  method to let user save data for his use?
 
  Resume:
 
  Interface File extends Blob
  {
  attribute unsigned long long currentPosition;
  readonly attribute signed long long deviceSpaceLeft;
  readonly attribute unsigned short machineEndian;
  const unsigned short BIG_ENDIAN = 1;
  const unsigned short LITTLE_ENDIAN = 0;
  const unsigned short UNKNOW_SIZE = -1;
  File create( );
  File createBynary();
  signed long write( in DOMString text, optional in unsigned long long
  position,  optional DOMString fromCharset )
  signed long writeBinary( in DOMString blob, optional in unsgined
 long
  long position )
  }
 
  An web application in this way could for example create a list of
 computed
  values and allow the user to save the contents to a file without need
 send
  data for the server to pack contents and issue a file download request
 to
  client.
  Or implement an image editor in javascript code using the new canvas
  element and allow read, create, store to be done without server
 assistance.
  Work on offline mode too.
 
  About security on file creation:
  When the web application request this operation File.create() the
 browser
  could launch a confirm( save file) dialog so the user only could grant
 the
  rights for a file creation.
  This dialog( modal? ) would manage file overwrite and more stuff related
  to file access( user may write at selected folder ) so that returned
 file
  reference could be overwritten by client script without trouble.
  The return type for that function could be string or a File object.
  An empty name value or Exception signal that user denied the request.
 
  If there is concerns about absolute file paths been exposed to
 javascript
  code
  then the File.create method could return a boolean status indicating
 that
  the object is ready to write( true ) and no file paths would be exposed
 at
  all. Or only the basename of file without path information.
 
  For differences between binary and text modes a second method call could
  signal File object that the new file should be used on binary mode:
  File.createBinary() - same behavior like File.create above but in binary
  mode.
 
  The file object could have some read only properties for device space
  control:
  For example:
  readonly File.deviceSpaceLeft  - so when script is making write calls to
  file if would know in advance if space still available for writing. Or
  application could launch a warn that no space left to save data. If the
  implementer do not know how to tell the space left then a
 File.UNKNOWSIZE
  value should be returned.
 
  double File.currentPosition - traditional File pointer to know where in
  the file the client is writing to. Since size is readonly changing this
  property move the current position in file cursor. Negative values are
  invalid and ignored. A positive value greater then current value
 increase
  the file size to the new size( doing this at begin could be a way to
 reserve
  space needed on disk at once since the file would grow to this current
 size,
  and help filesystem reduce fragmentation ). Changing this attribute on a
  file opened for read does nothing and is ignored. The size atrribute
 should
  reflect the new size confirming that file size increased.
 
  May cause UI hangs on large move requests.
  User agents may show on the create dialog a max file size allowed to be
  created making impossible to script consume all space left on device.
 
  readonly boolean File.machineEndian - binary files on target machine
 could
  have data stored in different formats then the script reading would
 expect.
  This flag would tell the script how to pack unpack data to be used on
 client
  machine.
 
  Cristiano

Re: HTML5 File

I'm reaching out to some W3C team contacts to figure out logistics.

-Ian

On Wed, Jun 2, 2010 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote:

 I don't know who makes these decisions, but I'd imagine the editor
 holds a certain amount of sway. I'd imagine that it would get a lot
 more review and attention from browser companies on WebApps. Apple
 isn't on DAP at all, and everyone from mozilla that works on related
 APIs are not on the DAP list (I don't have time to join another list,
 I imagine the same holds true for others though I'm not sure).

 / Jonas

 2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
  I whole-heartedly agree, and have said as much in the past, both on
 public
  MLs and to various W3C team contacts.
  -Ian
 
  On Wed, Jun 2, 2010 at 1:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  It keeps seeming to me that moving the file-writer spec to WebApps
  would make much more sense...
 
  / Jonas
 
  2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
   http://www.w3.org/TR/file-writer-api/
  
   On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva 
 sumar...@gmail.com
   wrote:
  
   I have been reading the specification on file section.
   I would like to ask why not propose that File interface allow a
 create
   method to let user save data for his use?
  
   Resume:
  
   Interface File extends Blob
   {
   attribute unsigned long long currentPosition;
   readonly attribute signed long long deviceSpaceLeft;
   readonly attribute unsigned short machineEndian;
   const unsigned short BIG_ENDIAN = 1;
   const unsigned short LITTLE_ENDIAN = 0;
   const unsigned short UNKNOW_SIZE = -1;
   File create( );
   File createBynary();
   signed long write( in DOMString text, optional in unsigned long
   long
   position,  optional DOMString fromCharset )
   signed long writeBinary( in DOMString blob, optional in unsgined
   long
   long position )
   }
  
   An web application in this way could for example create a list of
   computed
   values and allow the user to save the contents to a file without need
   send
   data for the server to pack contents and issue a file download
 request
   to
   client.
   Or implement an image editor in javascript code using the new canvas
   element and allow read, create, store to be done without server
   assistance.
   Work on offline mode too.
  
   About security on file creation:
   When the web application request this operation File.create() the
   browser
   could launch a confirm( save file) dialog so the user only could
 grant
   the
   rights for a file creation.
   This dialog( modal? ) would manage file overwrite and more stuff
   related
   to file access( user may write at selected folder ) so that returned
   file
   reference could be overwritten by client script without trouble.
   The return type for that function could be string or a File object.
   An empty name value or Exception signal that user denied the request.
  
   If there is concerns about absolute file paths been exposed to
   javascript
   code
   then the File.create method could return a boolean status indicating
   that
   the object is ready to write( true ) and no file paths would be
 exposed
   at
   all. Or only the basename of file without path information.
  
   For differences between binary and text modes a second method call
   could
   signal File object that the new file should be used on binary mode:
   File.createBinary() - same behavior like File.create above but in
   binary
   mode.
  
   The file object could have some read only properties for device space
   control:
   For example:
   readonly File.deviceSpaceLeft  - so when script is making write calls
   to
   file if would know in advance if space still available for writing.
 Or
   application could launch a warn that no space left to save data. If
 the
   implementer do not know how to tell the space left then a
   File.UNKNOWSIZE
   value should be returned.
  
   double File.currentPosition - traditional File pointer to know where
 in
   the file the client is writing to. Since size is readonly changing
 this
   property move the current position in file cursor. Negative values
 are
   invalid and ignored. A positive value greater then current value
   increase
   the file size to the new size( doing this at begin could be a way to
   reserve
   space needed on disk at once since the file would grow to this
 current
   size,
   and help filesystem reduce fragmentation ). Changing this attribute
 on
   a
   file opened for read does nothing and is ignored. The size atrribute
   should
   reflect the new size confirming that file size increased.
  
   May cause UI hangs on large move requests.
   User agents may show on the create dialog a max file size allowed to
 be
   created making impossible to script consume all space left on device.
  
   readonly boolean File.machineEndian - binary files on target machine
   could
   have data stored in different

Re: HTML5 File

Also, for the sake of keeping things together, when we move this over we
should probably move FileSystem over as well.

-Ian

On Wed, Jun 2, 2010 at 3:27 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:

 I'm reaching out to some W3C team contacts to figure out logistics.

 -Ian


 On Wed, Jun 2, 2010 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote:

 I don't know who makes these decisions, but I'd imagine the editor
 holds a certain amount of sway. I'd imagine that it would get a lot
 more review and attention from browser companies on WebApps. Apple
 isn't on DAP at all, and everyone from mozilla that works on related
 APIs are not on the DAP list (I don't have time to join another list,
 I imagine the same holds true for others though I'm not sure).

 / Jonas

 2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
  I whole-heartedly agree, and have said as much in the past, both on
 public
  MLs and to various W3C team contacts.
  -Ian
 
  On Wed, Jun 2, 2010 at 1:14 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  It keeps seeming to me that moving the file-writer spec to WebApps
  would make much more sense...
 
  / Jonas
 
  2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
   http://www.w3.org/TR/file-writer-api/
  
   On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva 
 sumar...@gmail.com
   wrote:
  
   I have been reading the specification on file section.
   I would like to ask why not propose that File interface allow a
 create
   method to let user save data for his use?
  
   Resume:
  
   Interface File extends Blob
   {
   attribute unsigned long long currentPosition;
   readonly attribute signed long long deviceSpaceLeft;
   readonly attribute unsigned short machineEndian;
   const unsigned short BIG_ENDIAN = 1;
   const unsigned short LITTLE_ENDIAN = 0;
   const unsigned short UNKNOW_SIZE = -1;
   File create( );
   File createBynary();
   signed long write( in DOMString text, optional in unsigned long
   long
   position,  optional DOMString fromCharset )
   signed long writeBinary( in DOMString blob, optional in unsgined
   long
   long position )
   }
  
   An web application in this way could for example create a list of
   computed
   values and allow the user to save the contents to a file without
 need
   send
   data for the server to pack contents and issue a file download
 request
   to
   client.
   Or implement an image editor in javascript code using the new canvas
   element and allow read, create, store to be done without server
   assistance.
   Work on offline mode too.
  
   About security on file creation:
   When the web application request this operation File.create() the
   browser
   could launch a confirm( save file) dialog so the user only could
 grant
   the
   rights for a file creation.
   This dialog( modal? ) would manage file overwrite and more stuff
   related
   to file access( user may write at selected folder ) so that returned
   file
   reference could be overwritten by client script without trouble.
   The return type for that function could be string or a File object.
   An empty name value or Exception signal that user denied the
 request.
  
   If there is concerns about absolute file paths been exposed to
   javascript
   code
   then the File.create method could return a boolean status indicating
   that
   the object is ready to write( true ) and no file paths would be
 exposed
   at
   all. Or only the basename of file without path information.
  
   For differences between binary and text modes a second method call
   could
   signal File object that the new file should be used on binary mode:
   File.createBinary() - same behavior like File.create above but in
   binary
   mode.
  
   The file object could have some read only properties for device
 space
   control:
   For example:
   readonly File.deviceSpaceLeft  - so when script is making write
 calls
   to
   file if would know in advance if space still available for writing.
 Or
   application could launch a warn that no space left to save data. If
 the
   implementer do not know how to tell the space left then a
   File.UNKNOWSIZE
   value should be returned.
  
   double File.currentPosition - traditional File pointer to know where
 in
   the file the client is writing to. Since size is readonly changing
 this
   property move the current position in file cursor. Negative values
 are
   invalid and ignored. A positive value greater then current value
   increase
   the file size to the new size( doing this at begin could be a way to
   reserve
   space needed on disk at once since the file would grow to this
 current
   size,
   and help filesystem reduce fragmentation ). Changing this attribute
 on
   a
   file opened for read does nothing and is ignored. The size atrribute
   should
   reflect the new size confirming that file size increased.
  
   May cause UI hangs on large move requests.
   User agents may show on the create dialog a max file size

Re: HTML5 File

2010-06-03 Thread イアンフェッティ

Were it not for file* I, and perhaps Google as a whole, would likely leave
DAP (though I cannot speak for everyone). Nothing else there is of interest
to me right now.

On Jun 3, 2010 4:13 AM, Robin Berjon ro...@berjon.com wrote:
 On Jun 2, 2010, at 23:02 , Jonas Sicking wrote:
 I don't know who makes these decisions, but I'd imagine the editor
 holds a certain amount of sway.

 Decisions of what is in scope for a WG are made by the members (i.e. you)
when a WG is created. When DAP was created, people felt rather strongly
(personally, I disagreed, I know that Arun had similar concerns) that adding
deliverables to WebApps would be a bad idea as it already had many, and
because there was already a lot of traffic on its list. This was discussed
publicly in the months leading up to DAP being chartered (including with
involvement from Mozilla participants) but the eventual balance became the
one we have today. I think (though I do not know for sure) that one factor
in this was the fact that the File API which is so nicely alive today had,
while DAP was being chartered, not been updated since 2006 and was still
called the File Upload API.

 I'm not saying that the above is good, I'm just answering your question :)

 I'd imagine that it would get a lot
 more review and attention from browser companies on WebApps.

 Well, technically, whenever there's an update or important question, it's
discussed here anyway.

 Apple isn't on DAP at all

 Which makes one speculate whether IP issues might have weighed in the
balanced to have DAP's deliverables be in a separate group.

 and everyone from mozilla that works on related APIs are not on the DAP
list

 I think you mean not everyone rather than everyone are not. There are
Mozilla people working on APIs that are on DAP.

 --
 Robin Berjon - http://berjon.com/

Actually, I should take that back. Some of the device specs are definitely
relevant, though I have concerns about the direction they are heading.
Either way though, it seems strange for the filesystem apis to be split.

On Thu, Jun 3, 2010 at 8:22 AM, Ian Fette (イアンフェッティ) ife...@google.comwrote:

Were it not for file* I, and perhaps Google as a whole, would likely leave
DAP (though I cannot speak for everyone). Nothing else there is of interest
to me right now.

On Jun 3, 2010 4:13 AM, Robin Berjon ro...@berjon.com wrote:
On Jun 2, 2010, at 23:02 , Jonas Sicking wrote:
I don't know who makes these decisions, but I'd imagine the editor
holds a certain amount of sway.

Decisions of what is in scope for a WG are made by the members (i.e. you)
when a WG is created. When DAP was created, people felt rather strongly
(personally, I disagreed, I know that Arun had similar concerns) that adding
deliverables to WebApps would be a bad idea as it already had many, and
because there was already a lot of traffic on its list. This was discussed
publicly in the months leading up to DAP being chartered (including with
involvement from Mozilla participants) but the eventual balance became the
one we have today. I think (though I do not know for sure) that one factor
in this was the fact that the File API which is so nicely alive today had,
while DAP was being chartered, not been updated since 2006 and was still
called the File Upload API.

I'm not saying that the above is good, I'm just answering your question
:)

I'd imagine that it would get a lot
more review and attention from browser companies on WebApps.

Well, technically, whenever there's an update or important question, it's
discussed here anyway.

Apple isn't on DAP at all

Which makes one speculate whether IP issues might have weighed in the
balanced to have DAP's deliverables be in a separate group.

and everyone from mozilla that works on related APIs are not on the DAP
list

I think you mean not everyone rather than everyone are not. There are
Mozilla people working on APIs that are on DAP.

--
Robin Berjon - http://berjon.com/

Re: HTML5 File

2010-06-04 Thread イアンフェッティ

On Fri, Jun 4, 2010 at 8:53 AM, Robin Berjon ro...@berjon.com wrote:

 On Jun 3, 2010, at 19:29 , Ian Fette (イアンフェッティ) wrote:
  Actually, I should take that back. Some of the device specs are
 definitely relevant

 Right, and some of your colleagues just submitted Powerbox there, which
 seems like a non-negligible chunk of work to me ;-)


To be clear, Chrome-team is not involved in powerbox, nor is android team to
the best of my knowledge.


  though I have concerns about the direction they are heading

 I regularly hear people having concerns about the direction in which
 DAP specs are heading. The shame is, they never seem to want to provide any
 details.

  Either way though, it seems strange for the filesystem apis to be split.

 As I said, it's historical, and due to no one pushing strong to correct
 that during chartering. Speaking personally, I don't really care much either
 way.


I recall pushing strongly to correct that at TPAC in san jose. I don't think
it's purely historical.



 --
 Robin Berjon - http://berjon.com/

Re: FileSystem API - overwrite flag for copy/move?

2010-09-09 Thread イアンフェッティ

I think recursive copy/remove is a very valid use case. As for overwrite, is
a flag necessary? On most OSes you already get overwrite as the default
behaviour (at least from APIs, many interactive UAs such as Explorer on
windows will prompt), is there a compelling argument why it should be
different for a web api?

On Thu, Sep 9, 2010 at 12:22 AM, Kinuko Yasuda kin...@chromium.org wrote:

 On Thu, Sep 9, 2010 at 12:12 AM, Kinuko Yasuda kin...@chromium.orgwrote:

 On Tue, Sep 7, 2010 at 6:12 PM, Eric Uhrhane er...@google.com wrote:

 On Mon, Aug 30, 2010 at 9:27 PM, Kinuko Yasuda kin...@chromium.org
 wrote:
  Hi,
  I have a question about Entry.moveTo/copyTo behavior defined in
  the File API: Directories and System [1].
  Currently the API doesn't specify how Entry.moveTo() and copyTo()
 should
  behave
  when a source entry is a file and there's *already* a file at the
  destination path.
  Should UAs overwrite the existing file at the destination path or not?
  Or maybe we should add an 'overwrite' flag to indicate if the script
 wants
  to overwrite an existing file or not?

 I'm open to a flag.  We're already up to 4 parameters to each of those
 methods, though...5 is a bit ungainly.  I'm concerned that we might
 find another flag to add at some point, and we'd then be up to 6.
 What about adding an flags object, as in getFile, to allow for
 expansion?


 Adding a flag or flags object (suppose the other thread about Flags will
 be settled) sounds good to me.

 Or I think it's also ok to explicitly disallow overwriting copy/move, i.e.
 specify that 'it is an error to copy or move a file or directory if there's
 already an entry'.  In this case it might be better to have another error
 code like ENTRY_EXISTS_ERR so that the user script can act differently.
  (But in general having a handy option would make programming much easier in
 async context where every operation requires one or two callbacks.)

 If we're going to add 'overwrite' flag, there'll be a few more things to
 be made clear.
 For example I wonder how the overwriting copy/move should behave when
 there's already a **directory** at the destination path/name.

 Should the UA remove the existing directory and create a new entry at the
 same path?
 This sounds reasonable but it'll also provide a handy alternative way to
 remove a directory recursively.


 By the way how do you think about recursive remove?
 Is there a reason (or past discussion) not to have recursive option in
 remove?  (I mean, other than the fact that adding more and more options to
 every method doesn't look very clean.)

 I found that it's not very easy to remove a directory when there're
 children in it -- it requires multiple DirectoryReader.readEntries and
 Entry.remove in a nested way.

 Thanks,

 Or should the UA create a new entry *under* the directory?
 This behavior doesn't sound like 'overwriting'.  The resulting path will
 be like 'destParentPath/name/name' which doesn't sound quite consistent with
 the spec either.


  Similarly I wondered if we'd want to have a 'recursive' flag for
  moveTo/copyTo.
  I think for directories we can simply assume that the user wants to
  move/copy
  them recursively, but it might be good to add some notion about that in
 the
  spec.

 How about I add a note indicating that directory copies are always
 recursive?
 I don't think we need anything for move.


 This sounds good to me.  Thanks!



   Thanks,
  [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html

Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

2011-02-03 Thread イアンフェッティ

I'm not sure FileSystem is necessarily any trickier from a user's
perspective -- it's all storage that is taking up space on my HD (at least,
for now the filesystem is just a directory under the user's profile in
Chrome). I think it fits fine in the unified quota model. (And FWIW we are
looking at replacing the SQLite backend for Indexed DB in Chrome, so it's
not generally safe to make such assumptions about how implementations
currently work remaining the same as you have below ;-) Still though, as an
end user or developer using the API, I really shouldn't have to care about
such details.)

As for our plans in Chrome, currently we are planning to give 5GB quota when
the site asks for persistent storage space, provided the site has asked for
between 0 and 5GB (there will be a user prompt that simply states X wants
to store data on your computer permanently. If the site asks for more than
5GB we will show a prompt X wants to store a large amount of data on your
computer permanently and grant that amount, both cases after user consent.
Still something of an open question as to what happens when a site hits the
limit, whether we go the FF model or try something else. It's not clear to
me that we actually have to prompt the user, or whether we can make
inferences from user actions. For instance, if a user has been using a site
for months, uses it frequently, and the site hits its 5GB limit but there's
still 300GB free on the drive, perhaps we just give the site another 5GB and
give the user a passive indication that we've done so, and let them do
something if they actually care. I suspect most user's probably won't care,
except perhaps on constrained (mobile) devices.

I think there is a lot of room for innovation beyond just ask the user :)

-Ian

On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchard ch...@visc.us wrote:

 I rather like the prompt in the new FF builds; it's similar to the prompt
 on Mobile Safari;
 when you get into the site, it asks you if you're ok storing data, and it
 allows you to specify a quota stepping.

 FF does a great job on applicationCache + quota in that area.

 The FileSystem API is a tricky thing.

 indexedDB is more straightforward.

 Let's take localStorage off the table for quota control: it's set at 5 megs
 in practice,
 and it's a very different storage mechanism.

 In practice, websql, appCache and indexeddb are backed by the public domain
 sqlite library
 and they share a quota on implementations.

 I'd like to discuss FileSystem permissions as a distinct item,
 as localStorage is distinct.

 Use case for the quota API:

 When a user wants to download a large set of data for offline use,
 Scripting needs permission unlimited space.
 unlimited is often set at 100 megs.

 The user has to stick around until their quota is full,
 if they've set a low quota amount.

 Scripting should not have to require 100 megs explicitly
 when a user first lands on a page.

 The user should only see an increase quota request
 following an input action (such as clicking a link or button).


 -Charles


 On 2/3/2011 5:08 PM, Shawn Wilsher wrote:

 On 2/3/2011 4:35 PM, João Eiras wrote:

 Or adding unnecessary complication to the implementation.

 I'm not looking to make my job easier (as an implementer); I'm looking to
 make it easy to use.  At least with IndexedDB, we generally choose the
 option that is easier for the consumer as long as it isn't extremely
 difficult to implement (which I do not see this being the case for quotas).

 Cheers,

 Shawn

Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

2011-02-03 Thread イアンフェッティ

On Thu, Feb 3, 2011 at 10:07 PM, Charles Pritchard ch...@visc.us wrote:

 On 2/3/2011 9:39 PM, Ian Fette (イアンフェッティ) wrote:

 I'm not sure FileSystem is necessarily any trickier from a user's
 perspective -- it's all storage that is taking up space on my HD (at least,
 for now the filesystem is just a directory under the user's profile in
 Chrome). I think it fits fine in the unified quota model. (And FWIW we are
 looking at replacing the SQLite backend for Indexed DB in Chrome, so it's
 not generally safe to make such assumptions about how implementations
 currently work remaining the same as you have below ;-) Still though, as an
 end user or developer using the API, I really shouldn't have to care about
 such details.)


 Thanks for sharing. I'm sure you'll see good results replacing the backend.

 indexedDB can be more efficient than FileSystem.
 FileSystem is an API to the OS service, idb is not.

 There are no issues with idb keynames, innodes are not an issue:
 idb can be optimized for target platforms, which is good when
 the underlying file system is a bad match for the file sizes / dir lengths
 / file names.

 FileSystem is useful when you want OS-recognized files.
 It's great for moving files in and out of the browser sandbox; OS indexing
 services, and so on.

 That's been my experience:

 We're using file system, as we do want individual files to be show up to
 the OS,
 but for generated content, especially thumbnails of images, that data would
 be better
 stored in idb. Lots of small files which would be better stashed in a data
 store.


I'd rather not de-rail the thread, that said I am surprised you see this
behaviour. It should be the exact opposite - we should be able to deliver
much better performance from the filesystem api for binary data. Test cases
where that's not the case are always welcome.




 -Charles

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-21 Thread イアンフェッティ

Ian,

I understand this point of view. That said, there is a lot of disagreement
in the IETF WG about deflate-stream. The extension basically breaks all
other extensions, framing, etc. It's a bit of a mess and a lot of us want to
just yank it out entirely. There was a much better proposal by yoshino-san
(deflate-frame) that basically did compression but still properly framed the
compressed result. I think that at least in Chrome we are hoping
deflate-frame will take off. That will be in a separate document though as
the current protocol doc is in last call, and you are undoubtedly familiar
with the logistical considerations of such things.

-Ian

On Thu, Jul 21, 2011 at 12:33 PM, Ian Hickson i...@hixie.ch wrote:

 On Thu, 21 Jul 2011, Adrian Bateman wrote:
 
  For platform features that directly affect web developers' pages that
  might sometimes be true. However, compression is also optional in HTTP
  and it doesn't appear to have caused problems or made some sites work
  and others not based on some dominant implementation.

 Optional features in HTTP have caused no end of trouble and are amongst
 the many reasons I avoid optional features so much.

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL
 http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread イアンフェッティ

We are talking about it at IETF81 this week.

That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
If we can get that through the process I could live with Chrome being
required to support that. As for the protocol doc, the protocol lists
deflate-stream as an example, not a requirement, so the mere fact that I
don't want to support that particular extension isn't necessarily the
strongest argument for taking it out of the protocol as the protocol doesn't
require that it be supported. The API should not require the support of that
particular extension either, as that extension is particularly bad.

-Ian

On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote:

 On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com
 wrote:

 So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//*
 *.


 HTML5 is mostly transport-layer agnostic.

 I am not sure why we are going through this theoretical side-quest on where
 we should state what browsers are required to implement from HTTP to
 function. The HTTP protocol has its own set of problems and this is all
 largely orthogonal to what we should do with the WebSocket protocol and API.

 If you do not think this particular extension makes sense raise it as a
 last call issue with the WebSocket protocol and ask for the API to require
 implementations to not support it. Lets not meta-argue about this.



 --
 Anne van Kesteren
 http://annevankesteren.nl/

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread イアンフェッティ

I don't think we want to forbid any extensions. The whole point of
extensions is to allow people to do something that doesn't necessarily have
consensus by a broad enough group to be in the base protocol. That said, I
think a lot of people would be happier if deflate-stream were an independent
document as opposed to being the only extension included in the core
specification as a known extension.

-Ian

2011/7/27 James Robinson jam...@google.com

 On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) 
 ife...@google.comwrote:

 We are talking about it at IETF81 this week.

 That said, I think either way browsers should not require deflate-stream.
 I am hoping we can make forward progress on deflate-application-data (
 http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
 If we can get that through the process I could live with Chrome being
 required to support that. As for the protocol doc, the protocol lists
 deflate-stream as an example, not a requirement, so the mere fact that I
 don't want to support that particular extension isn't necessarily the
 strongest argument for taking it out of the protocol as the protocol doesn't
 require that it be supported. The API should not require the support of that
 particular extension either, as that extension is particularly bad.


 Sounds like the consensus is to forbid this extension at the API layer,
 then.

 - James


 -Ian

 On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote:

 On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com
 wrote:

 So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5/
 /**.


 HTML5 is mostly transport-layer agnostic.

 I am not sure why we are going through this theoretical side-quest on
 where we should state what browsers are required to implement from HTTP to
 function. The HTTP protocol has its own set of problems and this is all
 largely orthogonal to what we should do with the WebSocket protocol and API.

 If you do not think this particular extension makes sense raise it as a
 last call issue with the WebSocket protocol and ask for the API to require
 implementations to not support it. Lets not meta-argue about this.



 --
 Anne van Kesteren
 http://annevankesteren.nl/

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread イアンフェッティ

I agree we shouldn't require deflate-stream it in the API. I don't agree the
API should specify an exact set of extensions, as that would prevent any
future versions/developments. A minimum baseline would be reasonable though,
once we have that minimum baseline in place (e.g. a stable set of extensions
that are well tested, such as compression and multiplexing). I don't think
we should put the cart before the horse.

-Ian

2011/7/27 James Robinson jam...@google.com

 On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) 
 ife...@google.comwrote:

 I don't think we want to forbid any extensions.


 At the protocol level, sure. At the API level we have to pick which
 functionality user agents are required to support and which they are
 required not to support, having 'optional' stuff is not an option.  It
 sounds like you are saying that deflate-stream is bad, so we should not have
 it in the API.

 - James


 The whole point of extensions is to allow people to do something that
 doesn't necessarily have consensus by a broad enough group to be in the base
 protocol. That said, I think a lot of people would be happier if
 deflate-stream were an independent document as opposed to being the only
 extension included in the core specification as a known extension.


 -Ian


 2011/7/27 James Robinson jam...@google.com

 On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.com
  wrote:

 We are talking about it at IETF81 this week.

 That said, I think either way browsers should not require
 deflate-stream. I am hoping we can make forward progress on
 deflate-application-data (
 http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
 If we can get that through the process I could live with Chrome being
 required to support that. As for the protocol doc, the protocol lists
 deflate-stream as an example, not a requirement, so the mere fact that I
 don't want to support that particular extension isn't necessarily the
 strongest argument for taking it out of the protocol as the protocol 
 doesn't
 require that it be supported. The API should not require the support of 
 that
 particular extension either, as that extension is particularly bad.


 Sounds like the consensus is to forbid this extension at the API layer,
 then.

 - James


 -Ian

 On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren 
 ann...@opera.comwrote:

 On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino 
 tyosh...@google.com wrote:

 So, let me correct my text by s/XHR/HTML5 
 http://www.w3.org/TR/html5//**.


 HTML5 is mostly transport-layer agnostic.

 I am not sure why we are going through this theoretical side-quest on
 where we should state what browsers are required to implement from HTTP to
 function. The HTTP protocol has its own set of problems and this is all
 largely orthogonal to what we should do with the WebSocket protocol and 
 API.

 If you do not think this particular extension makes sense raise it as a
 last call issue with the WebSocket protocol and ask for the API to require
 implementations to not support it. Lets not meta-argue about this.



 --
 Anne van Kesteren
 http://annevankesteren.nl/

Adding Web Intents to the Webapps WG deliverables

2011-09-19 Thread イアンフェッティ

I'm forwarding this on behalf of a colleague whose message seems caught up
in a moderation queue. Apologies if it results in a duplicate message for
anyone.

-- Forwarded message --
From: James Hawkins jhawk...@google.com
Date: Mon, Sep 19, 2011 at 1:27 PM
Subject: Adding Web Intents to the Webapps WG deliverables
To: public-webapps@w3.org

I am the tech lead for the team designing and implementing Web Intents [1]
for Chrome at Google.  Web Intents is a web platform feature modeled after
the similarly named feature in Android OS.  Web Intents enables client sites
to request high-level functionality, e.g. share, edit, pick, upload, auth,
from an unknown (to the client) provider.  The UA enumerates the list of
registered providers that the user has already accepted as Intent handlers,
allowing the user to pick which provider she wants to use for the particular
action.

This feature is not a panacea, nor do we envision it as a 'meta API';
however, the use cases we've focused on will make web apps much more
connected and useful for users.  Take the NASCAR problem: with Web Intents,
publishers can get rid of maintaining an ever-growing list of 'share'
providers, replacing them with one share button that kicks off the 'share'
action.  The user only sees the sites that she actively uses.

Note: we're actively working with Mozilla on the API, and the draft I have
prepared has been agreed upon by both vendors.

I've read through the Webapps charter, and I believe Web Intents fits the
goals and scope of the WG.

Goals
* Promote universal access to Web applications across a wide range of
devices.
  - Web Intents can be implemented in browsers on all devices, and more
importantly, the feature is a perfect conduit for hooking into platform
functionality (Android Intents, iOS API, a scalable
registerProtocolHandler).
* Promote creation of tutorials and other educational material.
  - Check out http://examples.webintents.org where we have example
clients/providers of Web Intents using a JS shim that works across all
current browsers.
  - The action string in the API is suggested to be a URL pointing to
documentation for the action, e.g., http://webintents.org/share is both the
string for the 'share' action and the URL of the documentation for said
action.

Scope
* Markup vocabularies for describing and controlling client-side application
behavior.
  - Web Intents provides an intent tag that allows provider sites to
declare which intent actions they handle.
* Programming interfaces for client-side development: platform interaction.
  - As stated above, this feature can easily be extended to hook into the
platform to, say, allow the UA to notify providers of platform events or
data sources, e.g., plugging in a camera.
The developers of this API, from both Mozilla and Google, believe Webapps is
the right home for Web Intents.  I'd like to open discussion on the topic
and get your feedback.  Ultimately we'd like to take the next steps towards
getting Web Intents officially out in the open, actively developed by the
larger Webapps community.

Thanks,
James Hawkins

[1] http://dev.chromium.org/developers/design-documents/webintentsapi

Re: Adding Web Intents to the Webapps WG deliverables

With all due respect, I think that if we have to re-charter or create a new
working group each time a new API comes up we are all doomed. The overhead
of creating and monitoring so many WGs is not appealing to many of us.

On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote:

 Hi James,

 thanks for bringing this forward, it is indeed a very interesting approach.

 On Sep 19, 2011, at 22:27 , James Hawkins wrote:
  I've read through the Webapps charter, and I believe Web Intents fits the
 goals and scope of the WG.

 It does fit the goal and scope, but then most web client technology does ;)
 Where you may run into issues is that it does not fit in the deliverables
 list. Since that is what members makes their IP commitment on, a new
 deliverable of non-negligible content might require rechartering. Last time
 we did that, it wasn't very pleasant.

 Thankfully, there is already a group that was chartered with Intents (or,
 in the poetic phrasing of charters, with an API that allows web
 applications to register themselves as handlers/providers based on data
 string identifiers and an API that enables other web applications to
 discover these handlers/providers and gain permission to interact with them
 — but Intents is what that means): the Device APIs group,
 http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the
 bureaucracy and allow us all to just go straight to work.

 We'd certainly be happy to accept your draft input. The new DAP is meant to
 be completely flexible in how it is organised. Notably, if you prefer to
 conduct work on this spec without necessarily getting all the email from the
 rest of the group we can setup a dedicated Task Force with its own mailing
 list and chair (if there's a volunteer, otherwise I'll do it). TFs can
 decide whether they want to have telcons or not.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

I don't get it. The overhead of getting all the other browsers to join the
WG you mention is just as high, especially when there's no indication that a
number of browsers intend to join that group. I don't think it's a random
process question, I think it's rather fundamental issue. If we agree that
the right way forward is to create a new WG for each API and we have to get
people to join each WG to get any IP considerations, it would be much more
effective just to do things in WHATWG and mail out a please sign this and
return letter. It would probably get the same number of responses and be a
hell of a lot lower overhead, while effectively offering as much (or rather,
as little) benefit as we get from being forced to start a new group for each
API.

-Ian

On Tue, Sep 20, 2011 at 7:21 AM, Robin Berjon ro...@berjon.com wrote:

 Hi Ian,

 On Sep 20, 2011, at 16:04 , Ian Fette (イアンフェッティ) wrote:
  With all due respect, I think that if we have to re-charter or create a
 new working group each time a new API comes up we are all doomed. The
 overhead of creating and monitoring so many WGs is not appealing to many of
 us.

 That's a recurring theme, with the following constraints:

   • people with IP don't want wildcard groups because the IP risks for
 them are hard to evaluate;
   • people who want to get work done don't want to have to jump through the
 bureaucratic hoops of creating new groups;
   • people who are focused on a single topic complain about monster
 groups that cover too many topics.

 So there probably isn't an option that will make everyone happy, though
 improvements are being discussed.

 Thankfully those problems don't apply here. There is an existing group so
 there's no need for bureaucratic hoops — those have been handled and
 everything is primed to go. The overhead involved in monitoring it involves
 clicking the form to join it and filtering the related list somewhere
 convenient — which can be the same mailbox as an existing one if there's too
 much overhead involved in reading from two mailboxes.

 So can we quit the process discussion and just get to work?

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com wrote:

 Hi Charles,

 On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
  There is certainly some overlap between DAP and WebApps. Is that the
 issue here, Robin?

 If you ask me, there isn't any issue at all :) James suggested that WebApps
 take over Intents. Since it isn't in WebApps's deliverables, this could
 require some process mongering which I think we can all agree is an annoying
 waste of time. As it happens however, DAP already has Intents in its
 charter, so getting to work right now rather than walking the bureaucratic
 path is a simple matter of doing the work there.


There's process mongering to get relevant parties to join DAP. This is not
free. If you can guarantee me that the other browsers will join DAP then
let's talk (namely MSFT who just announced a similar spec for Metro, and it
would be very important to get their input here.)



 I'm advocating a JFDI approach over politicking and bureaucracy. That's all
 there is to it.

 Put another way, I too would like there to be just one huge Web APIs
 group that would handle all of WebApps, DAP, Web Events, Geolocation, and a
 bunch of other groups. But we don't have that and there's opposition to the
 notion. So instead of lamenting that issue, let's just use the tools we have
 that in this case happen to be both in place and perfectly serviceable.

  I don't have much of a solution for it: I've been looking at DAP as an
 incubator with a broad
  scope and a good history of experimentation.

 Yeah, DAP has been very fluid in its approaches and is certainly a group in
 which this proposed spec can just hit the ground running. That's why I'm
 offering this solution over jumping through process hoops, which I really
 don't see the entertainment value in.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: Adding Web Intents to the Webapps WG deliverables

On Tue, Sep 20, 2011 at 10:15 AM, Marcos Caceres w...@marcosc.com wrote:

 On Tuesday, September 20, 2011 at 7:09 PM, Ian Fette (イアンフェッティ) wrote:
  On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com (mailto:
 ro...@berjon.com) wrote:
Hi Charles,
  
On Sep 20, 2011, at 17:15 , Charles Pritchard wrote:
There is certainly some overlap between DAP and WebApps. Is that the
 issue here, Robin?
  
   If you ask me, there isn't any issue at all :) James suggested that
 WebApps take over Intents. Since it isn't in WebApps's deliverables, this
 could require some process mongering which I think we can all agree is an
 annoying waste of time. As it happens however, DAP already has Intents in
 its charter, so getting to work right now rather than walking the
 bureaucratic path is a simple matter of doing the work there.
 
  There's process mongering to get relevant parties to join DAP. This is
 not free. If you can guarantee me that the other browsers will join DAP then
 let's talk (namely MSFT who just announced a similar spec for Metro, and it
 would be very important to get their input here.)
 That presupposes that Microsoft would have anything to say even in this WG.
 Obviously, I can't speak for Microsoft (and I won't), but just because
 someone is part of the WG doesn't mean that they will say anything … or
 worst, they will just exclude patents willy-nilly like Apple did with
 Widgets. That's a much crappier situation, so careful for what you wish for
 :)


While issuing a ton of patent exclusions for something like this would be
rather poor, I would frankly rather have that then a spec that doesn't get
any attention from a party that's clearly relevant only to have patents come
up /after/ the spec is published and implemented.

Re: Adding Web Intents to the Webapps WG deliverables