Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Having thought about this some more, I see that there is a fingerprinting
concern if we tie this closely into the available applications/OS capabilities.
Also I understand that the API would be relevant for drag and drop (thought I'm
not quite sure how it would work). Hence I think the method should be on the
DataTransfer.prototype object, and usable only inside event handlers:
if(event.clipboardData.isTypeSupported('foo/bar')) ...
"Supported" means: if you give me data labelled as this type, I know the OS
description and (if applicable) the relevant meta data and formatting for this
type, and can write it to the clipboard so that other native apps can make use
of it. If data labelled with the OS's native name or constant for this type is
on the clipboard, I can map it to the mime type and extract the data in a way
the script can use. Additionally, if a blob of data in this format is dropped
on my window, I'll know what to do about it, and if you drag this data *from*
my window to another application on the system, I can format and label it in a
way the targe app will understand."
Paul Libbrecht wrote:
> I have one concern: media-types are likely to be insufficient
> and "flavour names", whatever they are on the host platform
> should be allowed I think. Almost arbitrary strings on Windows
> and Uniform Type Identifiers on Mac should be allowed, I think.
No, I really don't think it is a good idea to make scripts on the web have to
sniff the OS to determine what argument to pass to isTypeSupported().. If MIME
types aren't sufficient, maybe we need to mint more MIME types as we go? :)
--
Hallvord R. M. Steen
Core tester, Opera Software
(aside) MIME type (was> Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard)
> Hallvord, it should be called media-types btw, or? IMHO the term "MIME type" is more widely used and also less ambiguous than "media type", so I'd definitely prefer using the former if I can get away with it :) -- Hallvord R. M. Steen Core tester, Opera Software
[Bug 15509] Define HTTP handling of data URLs (and maybe other URLs)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15509 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Anne 2012-02-17 22:40:21 UTC --- Done: http://dvcs.w3.org/hg/xhr/rev/d9af8c30a79a -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
On Fri, Feb 17, 2012 at 11:15 AM, Paul Libbrecht wrote: > > Le 17 févr. 2012 à 19:23, Daniel Cheng a écrit : > > Any MIME type support restrictions that apply to clipboard MIME types will > almost certainly apply to DnD MIME types as well. Therefore, it wouldn't > make sense to tie it to ClipboardEvent. > > > Not sure to understand what "lie" means. > "tie", not "lie". Also, what does it mean to be "supported"? In new versions of Chrome, any > kind of MIME type is supported in the sense that you can set data for any > arbitrary type, and it can be understood by any browser that uses the same > native conventions (I'd be happy to work with any other developers > interested in making sure this works across different browsers on the same > computer). > > > This sounds like a huge security leak. What if trusted web-site > docs.google.com receives a paste of easy.cms.com that just got hacked > with a hack that a kind html containing a script that reads the cookie when > executed? > In general, it's websites' responsibility to sanitize data they get from getData. On Fri, Feb 17, 2012 at 11:18 AM, Paul Libbrecht wrote: > > Le 17 févr. 2012 à 19:25, Ryosuke Niwa a écrit : > > Yes, it does happen: I think I know that in Windows the supported >> flavour-names depend on the launched applications. On Mac it depends on the >> applications whose descriptor has been loaded (by the Finder I think, it >> might also be those that have been launched once). At least an >> application download and launch can cause a change in the supported >> media-types of the OS. >> > > Right. These will become problems if we decide to expose all platform > types. > > However, would the browsers be informed of such a change? Would they be >> able to consider a given type as being safe and not needing a sanitization? >> > > I don't think that's possible without some sort of pre-knowledge about how > the data is processed. In practice, we always hard-code this kind of > information somewhere so I'm even not sure if such an elaborate behavior > can be implemented. > > If anyone is willing to consider trusted web-sites (and MSIE already > does?) then it is worth included. > Yeah, I think it's worth paying attention to this case. - Ryosuke
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Le 17 févr. 2012 à 19:25, Ryosuke Niwa a écrit : > On Fri, Feb 17, 2012 at 10:10 AM, Paul Libbrecht wrote: > I have one concern: media-types are likely to be insufficient and "flavour > names", whatever they are on the host platform should be allowed I think. > Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac > should be allowed, I think. > > Realistically, I don't think we'll ever let the wild Web get/set arbitrary > data like that. But maybe we can do that for privileged websites (ones that > the user trusts). I'm easy here. I sure do not want to slow down progress of this spec. I think it makes sense but well... (I find UTIs rather sexy since they have inheritance which media-types do not have). Hallvord, it should be called media-types btw, or? > Yes, it does happen: I think I know that in Windows the supported > flavour-names depend on the launched applications. On Mac it depends on the > applications whose descriptor has been loaded (by the Finder I think, it > might also be those that have been launched once). At least an application > download and launch can cause a change in the supported media-types of the OS. > > Right. These will become problems if we decide to expose all platform types. > > However, would the browsers be informed of such a change? Would they be able > to consider a given type as being safe and not needing a sanitization? > > I don't think that's possible without some sort of pre-knowledge about how > the data is processed. In practice, we always hard-code this kind of > information somewhere so I'm even not sure if such an elaborate behavior can > be implemented. If anyone is willing to consider trusted web-sites (and MSIE already does?) then it is worth included. paul
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Le 17 févr. 2012 à 19:23, Daniel Cheng a écrit : > Any MIME type support restrictions that apply to clipboard MIME types will > almost certainly apply to DnD MIME types as well. Therefore, it wouldn't make > sense to tie it to ClipboardEvent. Not sure to understand what "lie" means. Maybe you mean that it is a lie to use flavour names that are native names? Can you please explain? > Also, what does it mean to be "supported"? In new versions of Chrome, any > kind of MIME type is supported in the sense that you can set data for any > arbitrary type, and it can be understood by any browser that uses the same > native conventions (I'd be happy to work with any other developers interested > in making sure this works across different browsers on the same computer). This sounds like a huge security leak. What if trusted web-site docs.google.com receives a paste of easy.cms.com that just got hacked with a hack that a kind html containing a script that reads the cookie when executed? paul
[webcomponents]: Progress updates
Hi all! I've been publishing a steady stream of progress updates on the Web Components work here: https://plus.google.com/103330502635338602217/posts. Should I also summarize and post them here weekly? Monthly? Happy to do whatever is the most convenient thing for y'alls. :DG<
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
On Fri, Feb 17, 2012 at 10:10 AM, Paul Libbrecht wrote: > > I have one concern: media-types are likely to be insufficient and "flavour > names", whatever they are on the host platform should be allowed I think. > Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac > should be allowed, I think. > Realistically, I don't think we'll ever let the wild Web get/set arbitrary data like that. But maybe we can do that for privileged websites (ones that the user trusts). Le 17 févr. 2012 à 18:53, > Ryosuke Niwa > Software Engineer > Google Inc. > > > a écrit : > > Also, I'm thinking if there are cases where the supported mime types > change dynamically without reloading the page. > > (I hope I patched correctly) > Yes. Yes, it does happen: I think I know that in Windows the supported > flavour-names depend on the launched applications. On Mac it depends on the > applications whose descriptor has been loaded (by the Finder I think, it > might also be those that have been launched once). At least an > application download and launch can cause a change in the supported > media-types of the OS. > Right. These will become problems if we decide to expose all platform types. However, would the browsers be informed of such a change? Would they be > able to consider a given type as being safe and not needing a sanitization? > I don't think that's possible without some sort of pre-knowledge about how the data is processed. In practice, we always hard-code this kind of information somewhere so I'm even not sure if such an elaborate behavior can be implemented. - Ryosuke
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Any MIME type support restrictions that apply to clipboard MIME types will
almost certainly apply to DnD MIME types as well. Therefore, it wouldn't
make sense to tie it to ClipboardEvent.
Also, what does it mean to be "supported"? In new versions of Chrome, any
kind of MIME type is supported in the sense that you can set data for any
arbitrary type, and it can be understood by any browser that uses the same
native conventions (I'd be happy to work with any other developers
interested in making sure this works across different browsers on the same
computer).
Daniel
On Fri, Feb 17, 2012 at 10:10, Paul Libbrecht wrote:
> Hello Hallvord,
>
> I think it is a very good idea if such a method would be available from
> the point of view of a web-app author.
>
> I have one concern: media-types are likely to be insufficient and "flavour
> names", whatever they are on the host platform should be allowed I think.
> Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac
> should be allowed, I think.
>
>
> Le 17 févr. 2012 à 18:53, Ryosuke Niwa a écrit :
>
> I like the idea of letting authors dynamically detectthe supported mime
> types. But providing methods on the interface object seems rather unusual.
>
>
> It sounds like ok to me. An alternative would be to have a Capabilities
> object...
>
> Also, I'm thinking if there are cases where the supported mime types
> change dynamically without reloading the page.
>
> (I hope I patched correctly)
>
> Yes, it does happen: I think I know that in Windows the supported
> flavour-names depend on the launched applications. On Mac it depends on the
> applications whose descriptor has been loaded (by the Finder I think, it
> might also be those that have been launched once).
> At least an application download and launch can cause a change in the
> supported media-types of the OS.
>
> However, would the browsers be informed of such a change?
> Would they be able to consider a given type as being safe and not needing
> a sanitization?
>
> paul
>
>
>
>
>
> Le 17 févr. 2012 à 14:23, Hallvord R. M. Steen a écrit :
>
> Hi,
> I have an open issue noted in the spec - seems no implementor has worked
> on this yet so I'm throwing it out here to see what you all think.
>
> Given that
> a) We can't give a random script access to every format on the clipboard
> for security/privacy reasons (per earlier feedback from Chrome/WebKit devs
> and common sense)
> b) Certain clipboard formats have meta data or special formatting
> requirements that mean the implementation needs to do a bit of processing
> on reading/writing (thinking of Windows' CF_HTML)
> c) Text may apparently be placed on the clipboard in different encodings,
> an implementation may have to do conversions
> d) Clipboard contents can also be file references, in which case we'll
> make the *file* and not the actual clipboard data available
>
> - it's obvious that the implementation needs to do a bit of work to
> "support" reading/writing given types of data from/to the native clipboard.
>
> Hence, there should be a way a script can check if a clipboard format is
> registered and whether the implementation allows writing this format to the
> clipboard.
>
> My idea (at the moment) is to define a method on an interface (not on
> instances, on the interface object itself) like this:
>
> ClipboardEvent.isTypeSupported('mime/type')
>
> or, perhaps:
>
> DataTransfer.isTypeSupported('mime/type')??
>
> (but it's more clipboard-specific and maybe it's confusing to mix it with
> the DnD stuff?)
>
> An application can then for example do something like
>
> if( ClipboardEvent.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
> // prepare fancyformat content and place on clipboard
> }else{
> // fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
> }
>
> I'm suggesting to define this method on the interface object because it
> helps web applications do feature detection early. It could of course be
> defined on instances
>
> addEventListener('copy', function(e){
> if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
> // prepare fancyformat content and place on clipboard
> }else{
> // fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
> }
> })
>
> but then a feature/compatibility test would have to be deferred until a
> point where the user potentially has done a lot of work in the web
> application.
>
> Thoughts?
>
> --
> Hallvord R. M. Steen
> Core tester, Opera Software
>
>
>
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Hello Hallvord,
I think it is a very good idea if such a method would be available from the
point of view of a web-app author.
I have one concern: media-types are likely to be insufficient and "flavour
names", whatever they are on the host platform should be allowed I think.
Almost arbitrary strings on Windows and Uniform Type Identifiers on Mac should
be allowed, I think.
Le 17 févr. 2012 à 18:53, Ryosuke Niwa a écrit :
> I like the idea of letting authors dynamically detectthe supported mime
> types. But providing methods on the interface object seems rather unusual.
It sounds like ok to me. An alternative would be to have a Capabilities
object...
> Also, I'm thinking if there are cases where the supported mime types change
> dynamically without reloading the page.
(I hope I patched correctly)
Yes, it does happen: I think I know that in Windows the supported flavour-names
depend on the launched applications. On Mac it depends on the applications
whose descriptor has been loaded (by the Finder I think, it might also be those
that have been launched once).
At least an application download and launch can cause a change in the supported
media-types of the OS.
However, would the browsers be informed of such a change?
Would they be able to consider a given type as being safe and not needing a
sanitization?
paul
Le 17 févr. 2012 à 14:23, Hallvord R. M. Steen a écrit :
> Hi,
> I have an open issue noted in the spec - seems no implementor has worked on
> this yet so I'm throwing it out here to see what you all think.
>
> Given that
> a) We can't give a random script access to every format on the clipboard for
> security/privacy reasons (per earlier feedback from Chrome/WebKit devs and
> common sense)
> b) Certain clipboard formats have meta data or special formatting
> requirements that mean the implementation needs to do a bit of processing on
> reading/writing (thinking of Windows' CF_HTML)
> c) Text may apparently be placed on the clipboard in different encodings, an
> implementation may have to do conversions
> d) Clipboard contents can also be file references, in which case we'll make
> the *file* and not the actual clipboard data available
>
> - it's obvious that the implementation needs to do a bit of work to "support"
> reading/writing given types of data from/to the native clipboard.
>
> Hence, there should be a way a script can check if a clipboard format is
> registered and whether the implementation allows writing this format to the
> clipboard.
>
> My idea (at the moment) is to define a method on an interface (not on
> instances, on the interface object itself) like this:
>
> ClipboardEvent.isTypeSupported('mime/type')
>
> or, perhaps:
>
> DataTransfer.isTypeSupported('mime/type')??
>
> (but it's more clipboard-specific and maybe it's confusing to mix it with the
> DnD stuff?)
>
> An application can then for example do something like
>
> if( ClipboardEvent.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
> // prepare fancyformat content and place on clipboard
> }else{
> // fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
> }
>
> I'm suggesting to define this method on the interface object because it helps
> web applications do feature detection early. It could of course be defined
> on instances
>
> addEventListener('copy', function(e){
> if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
> // prepare fancyformat content and place on clipboard
> }else{
> // fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
> }
> })
>
> but then a feature/compatibility test would have to be deferred until a point
> where the user potentially has done a lot of work in the web application.
>
> Thoughts?
>
> --
> Hallvord R. M. Steen
> Core tester, Opera Software
>
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
I meant to say *if* there are cases. On Feb 17, 2012 9:53 AM, "Ryosuke Niwa" wrote:
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
I like the idea of letting authors dynamically detectthe supported mime
types. But providing methods on the interface object seems rather unusual.
Also, I'm thinking there are cases where the supported mime types change
dynamically without reloading the page.
- Ryosuke
On Feb 17, 2012 5:25 AM, "Hallvord R. M. Steen" wrote:
> Hi,
> I have an open issue noted in the spec - seems no implementor has worked
> on this yet so I'm throwing it out here to see what you all think.
>
> Given that
> a) We can't give a random script access to every format on the clipboard
> for security/privacy reasons (per earlier feedback from Chrome/WebKit devs
> and common sense)
> b) Certain clipboard formats have meta data or special formatting
> requirements that mean the implementation needs to do a bit of processing
> on reading/writing (thinking of Windows' CF_HTML)
> c) Text may apparently be placed on the clipboard in different encodings,
> an implementation may have to do conversions
> d) Clipboard contents can also be file references, in which case we'll
> make the *file* and not the actual clipboard data available
>
> - it's obvious that the implementation needs to do a bit of work to
> "support" reading/writing given types of data from/to the native clipboard.
>
> Hence, there should be a way a script can check if a clipboard format is
> registered and whether the implementation allows writing this format to the
> clipboard.
>
> My idea (at the moment) is to define a method on an interface (not on
> instances, on the interface object itself) like this:
>
> ClipboardEvent.**isTypeSupported('mime/type')
>
> or, perhaps:
>
> DataTransfer.isTypeSupported('**mime/type')??
>
> (but it's more clipboard-specific and maybe it's confusing to mix it with
> the DnD stuff?)
>
> An application can then for example do something like
>
> if( ClipboardEvent.**isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
>// prepare fancyformat content and place on clipboard
> }else{
>// fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
> }
>
> I'm suggesting to define this method on the interface object because it
> helps web applications do feature detection early. It could of course be
> defined on instances
>
> addEventListener('copy', function(e){
>if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
>// prepare fancyformat content and place on clipboard
>}else{
>// fall back to for example put xml-data-as-plain-text or
> json-data-as-plain-text
>}
> })
>
> but then a feature/compatibility test would have to be deferred until a
> point where the user potentially has done a lot of work in the web
> application.
>
> Thoughts?
>
> --
> Hallvord R. M. Steen
> Core tester, Opera Software
>
>
[Bug 16017] New: [IndexedDB] editorial changes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16017 Summary: [IndexedDB] editorial changes Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: odi...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Looking through the spec with Joao Eiras, we found a few editorial changes. It's just lots of small stuff, so I'm just putting it all here in one bug :-) --- 1 deleteDatabase change: > When invoked, this method must create a request and return it. The created > request has no source. to: > When invoked, this method must create a request and return it. The created > request must implement the IDBOpenDBRequest interface and have its source > set to null. 2 deleteDatabase I'm a bit unsure what the text is doing now, but I've written it to how I understand it: change: > If the steps above are successful, the implementation must set the result of > the request to null and fire a success event at the request. The request will > be an IDBVersionChangeRequest returned by those steps. to: > If the steps above are successful, the implementation must set the result of > the request to null and fire a success event at the request. The event MUST > implement the IDBVersionChangeEvent interface and have oldVersion set to > database version and have the newVersion property set to null. 3 open I don't understand this text. I think it must be wrong. If it's not wrong, it should be much clearer. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBFactory-open-IDBOpenDBRequest-DOMString-name-unsigned-long-long-version > If an error is returned from the steps above, the implementation must set the > error attribute of the request to a DOMError whose type is the same as the > error returned, of the request to null, and dispatch an event at request. The > event must use the Event interface and have its type set to "error". The > event does bubble but is not cancelable. The propagation path of the event > is just the request. > > If the steps above are successful, the implementation must set the error > attribute of the request to a DOMError whose type is the same as the error > returned, to the connection created by the steps above and dispatch an event > at request. The event must use the Event interface and have its type set to > "success". The event does not bubble and is not cancelable. The propagation > path of the event is just the request. If the steps above resulted in a > VERSION_CHANGE transaction being run, then firing the "success" event must > be done in the same task as was used Waat? I would just delete the second talk about errors and write: > If the steps above are successful, the implementation must dispatch an event > at request. The event must use the Event interface and have its type set to > "success". The event does not bubble and is not cancelable. The propagation > path of the event is just the request. If the steps above resulted in a > VERSION_CHANGE transaction being run, then firing the "success" event must > be done in the same task as was used 4 IDBTransaction.abort, typo http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBTransaction-abort-void change: > steps for aborting a transaction with with the error attribute to: > steps for aborting a transaction with the error attribute 5 IDBTransaction.objectStore, typo http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBTransaction-objectStore-IDBObjectStore-DOMString-name change: > that is part of the to the scope of this transaction. to: > that is part of the scope of this transaction. 6 the the typos Change all 'the the' to 'the'. 7 Transaction Creation steps http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#transaction-creation-steps step 8: change 'synchrnously' to 'synchronously'. 8 Steps for committing a transaction, steps for aborting a transaction Change all occurences of: > All the changes made to the database the transaction uses to: > All the changes made to the database by the transaction 9 Steps for abort a transaction Change 'two parameter' to 'two parameters' 10 Steps for extracting a key from a value using a key path Change, in step 3, 'assignattribute' to 'assign attribute'. 11 VERSION_CHANGE transaction steps change: > This algorithm takes two required parameters - a connection object > which is used to update the database a new version to be set for the > database. The algorithm also takes two optional arguments, a request > which represents a request used when the asynchronous API is used, > or a upgrade callback which represents the callback used when the > synchronous API is used. to: >
[Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Hi,
I have an open issue noted in the spec - seems no implementor has worked
on this yet so I'm throwing it out here to see what you all think.
Given that
a) We can't give a random script access to every format on the clipboard
for security/privacy reasons (per earlier feedback from Chrome/WebKit devs
and common sense)
b) Certain clipboard formats have meta data or special formatting
requirements that mean the implementation needs to do a bit of processing
on reading/writing (thinking of Windows' CF_HTML)
c) Text may apparently be placed on the clipboard in different encodings,
an implementation may have to do conversions
d) Clipboard contents can also be file references, in which case we'll
make the *file* and not the actual clipboard data available
- it's obvious that the implementation needs to do a bit of work to
"support" reading/writing given types of data from/to the native clipboard.
Hence, there should be a way a script can check if a clipboard format is
registered and whether the implementation allows writing this format to
the clipboard.
My idea (at the moment) is to define a method on an interface (not on
instances, on the interface object itself) like this:
ClipboardEvent.isTypeSupported('mime/type')
or, perhaps:
DataTransfer.isTypeSupported('mime/type')??
(but it's more clipboard-specific and maybe it's confusing to mix it with
the DnD stuff?)
An application can then for example do something like
if( ClipboardEvent.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
// prepare fancyformat content and place on clipboard
}else{
// fall back to for example put xml-data-as-plain-text or
json-data-as-plain-text
}
I'm suggesting to define this method on the interface object because it
helps web applications do feature detection early. It could of course be
defined on instances
addEventListener('copy', function(e){
if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
// prepare fancyformat content and place on clipboard
}else{
// fall back to for example put xml-data-as-plain-text or
json-data-as-plain-text
}
})
but then a feature/compatibility test would have to be deferred until a
point where the user potentially has done a lot of work in the web
application.
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
[Bug 16013] New: objectStoreNames order should be specified (alphabetic?)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16013 Summary: objectStoreNames order should be specified (alphabetic?) Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: odi...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should probably specify objectStoreNames order. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabase-objectStoreNames http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabaseSync-objectStoreNames I suggest changing: > On getting, this attribute must return a list of names of the object stores > currently in the connected database. To: > On getting, this attribute must return a list of names of the object stores > currently in the connected database sorted in ascending order. Should also specify what we mean by sorted in ascending order here. Probably the same as is already said for comparing DOMStrings in keys. E.g. step 5 of http://es5.github.com/#x11.8.5 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Installing Web Apps
The problem is we're framing the discussion in terms of "installing" web apps. We're answering the wrong question. The real question is whether we want to start seeing powerful applications running in the browser. If we do, then we'll figure out a way to get there. Be it "installing", "permissions", or letting apps use as much storage as they need, but just giving me a way to keep tabs on what they're using so I can uninstall them if I want. Or letting apps use as much bandwidth or CPU or whatever they need, but just giving me a way to keep tabs. Or if I'm really security conscious there could be a firewall to let me as user defend certain "system calls" or whitelist specific apps but only if I want. But none of that is really the issue now. The issue now is that some are unimaginatively saying "what, browser in a browser?". It's the "nobody would ever want a personal computer" attitude and this needs to change so that the next unforeseen innovation can take place. What do you want to build in the browser? 1. Dropbox (e.g. drag and drop files into the browser, click a link in the app to open them in native applications such as Excel, poll the file for changes from the browser and sync the chunks that changed)? 2. Web browser? 3. Proxyless POP and SMTP clients that don't waste server bandwidth and let users go direct? 4. Spotify client? 5. Skype client? I want to be building all of the above.
