[IndexedDB] Full text indexing
Hi. Just wondering if anyone could take a few moments to provide an update on the state of full-text indexing in IndexedDB? A quick google indicated that the question had been raised before, Jeremy Orlow suggesting support for inverted indexes (back in February) and there was a reference to ongoing discussions on the subject in June. The current working draft doesn't appear to mention inverted indexes or full text, and it was updated fairly recently. Cheers.
Re: [IndexedDB] Full text indexing
We haven't looked at it much since there were many bigger issues to be resolved first. But now that those issues are largely resolved, maybe now is a good time to start talking about this seriously. I think most people were down on the idea of adding complete full text search because it'd be a _lot_ of API surface area. But, everyone I've talked to seems to think that native inverted index support + JS for the rest should be a reasonable compromise for v1. Hopefully by end of year, we'll be ready to start experimenting with such support in Chrome/WebKit. If someone wanted to push this forward on the spec side or in another implementation in the mean time, that'd be great though. J On Mon, Aug 23, 2010 at 11:03 AM, Nathan Kitchen w...@nathankitchen.comwrote: Hi. Just wondering if anyone could take a few moments to provide an update on the state of full-text indexing in IndexedDB? A quick google indicated that the question had been raised before, Jeremy Orlow suggesting support for inverted indexes (back in February) and there was a reference to ongoing discussions on the subject in June. The current working draft doesn't appear to mention inverted indexes or full text, and it was updated fairly recently. Cheers.
Re: Lifetime of Blob URL
I agree with Dmitry: window.createBlobUrl() makes it clearer. Querying blob.url shouldn't have side effects. As Jonas points out, we should keep the creation and destruction methods near each other, so window.destroyBlobUrl() would be the opposite function. As for getBlobUrl vs. createBlobUrl: the latter sounds like it returns a new URL each time. The former is less explicit. If we're returning a unique URL per call, then create is clearly better. Are we requiring that each call to xxxBlobUrl have a matched destroyBlobUrl, even if we're returning the same URL? I think BlobError and BlobException make a bit more sense, but I'm not too adamant about it. On Sat, Aug 21, 2010 at 1:00 PM, Jian Li jia...@google.com wrote: I do not see any more discussions on blob URL API in recent days. Any more thoughts or conclusion? In addition, do we want to rename FileError and File Exception to BlobError and BlobException to match with BlobReader naming, or rather keep them intact? On Mon, Aug 2, 2010 at 3:22 PM, Dmitry Titov dim...@chromium.org wrote: It feels developers will make less errors with window.getBlobUrl(blob) kind of API, because, unlike blob.url, it doesn't violate pretty common programming assumptions (like querying a property of the same object should return the same value if nothing was done to the object, or that value of property should not depend on what is a global object in the context of the query if the blob is the same). The spec language describing why and when blob.url returns different values with different lifetimes would be a bit hairy... Agree though that functionally they are the same. On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman micha...@google.com wrote: On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Jonas, Just to clarify some details we had while discussing this, could you confirm if this matches with your thinking (or not): 1. If blob was created in window1, blob.url was queried, then passed (as JS object) to window2, and window1 was closed - then the url gets invalidated when window1 is closed, but immediately re-validated if window2 queries blob.url. The url string is going to be the same, only there will be a time interval between closing window1 and querying blob.url in window2, during which loading from the url returns 404. Actually, it might make sense to make blob.url, when queried by window2, return a different string. This makes things somewhat more consistent as to when a URL is working an when not. Now suppose window2 queries the .url attribute before window1 is closed? I think most people would expect the same value as returned in window1 (yes?). Having the same or different value depending on whether the attribute was queried before or after another window was closed seems confusing. I think having the .url remain consistent from frame to frame/window to window could help with debugging. The idea would be that we *always* return different urls depending on which window queries a url. This gives the most consistent behavior in that every url given is always limited to the lifetime of the current window. No matter what windows around it does. If that's the idea, then I would vote for a non-instance method somewhere to provide the context specific URL. Having a simple attribute accessor return different values depending on which context its being accessed in is very unusual behavior. Can't say that its ideal, but window.getBlobUrl(blob) and window.revokeBlobUrl(...) would be an improvement. I can't say that I'm a big fan of this syntax given that I think the current syntax works fine in most cases. I'm definitely curious to hear what others think though. / Jonas
Re: Possible addition to file API
Take a look at this discussion of XHR.responseBlob: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0536.html Eric On Sat, Aug 21, 2010 at 12:39 PM, J David Eisenberg jdavid.eisenb...@gmail.com wrote: At present, the only way a web page can read a file's binary data via the File API (http://dev.w3.org/2006/webapi/FileAPI) is if the person reading the page enters the file name in an input type=file/. The API applies to only local files, if I read it correctly. Is it possible to extend the spec to allow a script to read any file that can been loaded as part of the HTML page, such as an img/? This extension would let web pages read the EXIF data of an image that is part of an img element; a very useful capability for web apps. Similarly, you could access metadata from a file destined for an audio or video element. The spec seems to suggest that this is possible: http://dev.w3.org/2006/webapi/FileAPI/#url , but is it implemented in any browsers? I understand there are good security reasons for restricting file reads; you don't want someone else's web page to be able to go willy-nilly through your local hard disk and send all the information back to the Bad Guys. But this scenario is different; if you have loaded an img/, you must already have read permission for it, and its data is there in the browser. I'm just asking to be able to access its bits. Precedent: think of link rel=stylesheet href=blah.css/; you have access to all the elements in that file via the DOM, and there's no security issue involved, even if it's a cross-domain href. That's because it is *not* an arbitrary file on the user's local file system; it's one that the author has explicitly specified and is allowed to read. I think my suggestion here meets the same criteria. Am I missing something obvious on the security front? The back story for this idea (you may safely skip this portion if you are not interested): My brother and I have just spent the past few days looking over several large boxes of photos that my mom had stored away. Most of them had nothing written on the back, so we had no idea of where or when the pictures were taken, nor who the people in them were, nor what the picture meant to Mom. Obviously, metadata matters. This told me that I need to start using the comments feature in GIMP to add descriptions to my photos. A few days ago, some of our family got together and I told my cousin George that I'm going to start doing this. He said that was nice, but the only way to get the data out is to use a program similar to the one that you used when editing the image, and most people won't have that. So I thought, You know, it would be great if you could get access to an img/'s EXIF data from the browser.
[IndexedDB] Let's remove IDBDatabase.objectStore()
Hi folks,
We originally included IDBDatabase.objectStore() as a convenience
function because we figured that everyone would hate typing
|myDatabase.transaction('myObjectStore').objectStore('myObjectStore')|.
Unfortunately I think we should remove it - too many developers have
used the function without realizing that the returned object was tied
to a particular transaction. Any objections?
-Ben
Re: [widgets] widget tests for view mode media feature
Update: based on feedback, we have rewritten the tests. The tests no longer assume a default view mode, and no longer use any javascript. Again, please review and send feedback. On Sat, Aug 21, 2010 at 7:36 PM, Marcos Caceres marc...@opera.com wrote: Hi, Opera has completed the first draft of the widget-based tests for the view-mode media feature. These tests are designed to be run in the context of a widget user agent (we might need a completely different test suite for browsers in general, for which we might need to coordinate with the CSS WG). For the purposes of testing, the tests assume the default mode that widgets will be run in is floating. I don't know if this is a problem or not... so please let us know ASAP if we need to change the tests. The overview of the test suite is available from the link below (note that the Overview document is just a copy/paste from another test suite, so contains errors... just scroll to the bottom of the page and click on Product ua to access the tests): http://dev.w3.org/2006/waf/widgets-vmmf/test-suite/ Comments welcomed... Kind regards, Marcos -- Marcos Caceres Opera Software -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
