Re: SearchBox API
On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Hi all, Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. So, why does the search page need any data? Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? Also, would be great to see some examples where all of features of the API are being used. -Olli Since then it has been implemented by Google web search and Chrome. You can demo it by checking Enable Instant for faster searching and browsing in Chrome's preferences. Some suggested this list might be a better place to poll for interest and discuss the API. Are there any user agents or search providers who are interested in working to standardize this interface[2]? Any feedback is welcome as well. -Tony [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-October/028818.html [2] http://dev.chromium.org/searchbox
[IndexedDB] Design Flaws: Not Stateless, Not Treating Objects As Opaque
On 20 Mar 2011, at 4:54 AM, Jonas Sicking wrote: I don't understand what you are saying about application state though, so please do start that as a separate thread. At present, there's no way for an application to tell IDB what indexes to modify w.r.t. an object at the exact moment when putting or deleting that object. That's because this behavior is defined in advance using createIndex in a setVersion transaction. And then how IDB extracts the referenced value from the object is done using an IDB idea of key paths. But right there, in defining the indexes in advance (and not when the index is actually modified, which is when the object itself is modified), you've captured application state (data relationships that should be known only to the application) within IDB. Because this is done in advance (because IDB seems to have inherited this assumption that this is just the way MySQL happens to do it), there's a disconnect between when the index is defined and when it's actually used. And because of key paths you now need to spec out all kinds of things like how to handle compound keys, multiple values. It's becoming a bit of a spec-fest. That this bubble of state gets captured in IDB, it also means that IDB now needs to provide ways of updating that captured state within IDB when it changes in the application (which will happen, so essentially you now have your indexing logic stuck in the database AND in the application and the application developer now has to try and keep BOTH in sync using this awkward pre-defined indexes interface), thus the need for a setVersion transaction in the first place. None of this would be necessary if the application could reference indexes to be modified (and created if they don't exist, or deleted if they would then become empty) AT THE POINT of putting or deleting an object. Things like data migrations would also be better served if this were possible since this is something the application would need to manage anyway. Do you follow? The application is the right place to be handling indexing logic. IDB just needs to provide an interface to the indexing implementation, but not handle extracting values from objects or deciding which indexes to modify. That's the domain of the application. It's a question of encapsulation. IDB is crossing the boundaries by demanding to know ABOUT the data stored, and not just providing a simple way to put an object, and a simple way to put a reference to an object to an index, and a simple way to query an index and intersect or union an index with another. Essentially an object and its index memberships need to be completely opaque to IDB and you are doing the opposite. Take a look at the BDB interface. Do you see a setVersion or createIndex semantic in there? Take a look at Redis and Tokyo and many other things. Do you see a setVersion or createIndex semantic in there? Do these databases have any idea about the contents of objects? Any concept of key paths? No, and that's the whole reason these databases were created in the first place. I'm sure you have read the BDB papers. Obviously this is not the approach of MySQL. But if IDB is trying to be MySQL but saying it wants to be BDB then I don't know. In any event, Firefox would be brave to also embed SQLite. Let the better API win. How much simpler could it be? At the end of the day, it's all objects and sets and sorted sets, and see Redis' epiphany on this point. IDB just needs to provide transactional access to these sets. The application must decide what goes in and out of these sets, and must be able to do it when it wants to, not some time in advance. I bring this up because I once wrote the exact same kind of database that you are writing now (where one thinks it would be good if the database did NOT treat objects as opaque... that the database should be smart about the contents of objects and share control for how objects relate to each other etc.) and I have since seen how much better, simpler, faster the alternative is. So unless you have formidable reasons for maintaining the status quo in light of the above, even if you don't understand this concept of application state getting stuck in IDB, and even though you advocate that WebSQL is not deprecated and that we can consider LocalStorage to be an alternative, then it is my hope that you will heed this and make something of it. I'm sorry if this is not the kind of feedback you want to hear at this stage, but IDB needs to be good for more than just HTML 5 todo list demos.
Re: SearchBox API
[Re-sending to the correct list.] On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. The instant search feature has a bunch of different components. One aspect is URL preloading, which happens when the browser thinks you're typing something navigational (like a URL) into the omnibox and is not related to the SearchBox API. Another aspect is what happens when the browser thinks you're tying something search-like (like potato) into the omnibox. In that case, the browser displays a search engine results page. So, why does the search page need any data? The SearchBox API has a two-way flow of information between the search engine results page (SERP) and the browser's search field. (In Chrome's case, that's the omnibox, but it would work just as sensibly for browsers with a dedicated search box.) Essentially, the browser tells the SERP various information about what the user has typed in the search field (much like the web site would learn if the user typed into a text input field in the web site) and the SERP tells the browser some suggested completions for what the user has typed so far (e.g., so the browser can display those suggestions to the user). Additionally, the browser can tell the SERP about the geometry of the search field (if it overlaps the SERP), which lets the SERP move its UI out from underneath the search field, if desired. Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I wasn't involved in the design, but I suspect there are latency and synchronization challenges with that approach. Most modern browsers use that approach for showing search suggestions in their search fields today, but with this UI, it's important to synchronize the browser's search field with the SERP. Using JavaScript events to communicate removes some of the network latency. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? As a general principle, Chrome shouldn't have an special integrations with google.com. For example, bing.com should be able to use any Chrome feature, and other browsers, such as Safari and Firefox, should be able to use any google.com feature. Now, the project doesn't always live up to that principle, but that's the reasoning behind implementing and specifying a general-purpose API. Also, would be great to see some examples where all of features of the API are being used. My understanding is that Google's SERP uses all the features of the API. Tony designed the API in coordination with the folks who work on Google's SERP. For example, if you enable the instant feature in Chrome and type potato in the omnibox, you should see similar search suggestions in the autocomplete dropdown as you'd see if you typed potato into the google.com search box (assuming you have Google set as your default search provider). Similarly, if you type a character, the SERP should react immediately to the change event instead of waiting for network latency. Finally, you'll notice that the autocomplete dropdown does not overlap with the search results because of the geometry information provided by the SearchBox API. Adam
Re: [public-webapps] SearchBox API
On Sun, Mar 20, 2011 at 5:26 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 03/21/2011 01:23 AM, Adam Barth wrote: On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettayolli.pet...@helsinki.fi wrote: On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. The instant search feature has a bunch of different components. One aspect is URL preloading, which happens when the browser thinks you're typing something navigational (like a URL) into the omnibox and is not related to the SearchBox API. Another aspect is what happens when the browser thinks you're tying something search-like (like potato) into the omnibox. In that case, the browser displays a search engine results page. So, why does the search page need any data? The SearchBox API has a two-way flow of information between the search engine results page (SERP) and the browser's search field. (In Chrome's case, that's the omnibox, but it would work just as sensibly for browsers with a dedicated search box.) Essentially, the browser tells the SERP various information about what the user has typed in the search field (much like the web site would learn if the user typed into a text input field in the web site) and the SERP tells the browser some suggested completions for what the user has typed so far (e.g., so the browser can display those suggestions to the user). Additionally, the browser can tell the SERP about the geometry of the search field (if it overlaps the SERP), which lets the SERP move its UI out from underneath the search field, if desired. Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I wasn't involved in the design, but I suspect there are latency and synchronization challenges with that approach. Most modern browsers use that approach for showing search suggestions in their search fields today, but with this UI, it's important to synchronize the browser's search field with the SERP. Using JavaScript events to communicate removes some of the network latency. One of the problems with this API I have is that either browser implements the UI the API expects (rectangular dropdown list) or just doesn't support the API. AFAIK, every user agent occludes the content area with a rectangular (or roughly rectangular) region as part of the search field interaction. If you've got examples of non-rectangular occlusion, I suspect Tony would be willing to update the API to support other geometries. Of course, you could implement the API to always report no occlusion and still make use of the other features. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with such API? As a general principle, Chrome shouldn't have an special integrations with google.com. For example, bing.com should be able to use any Chrome feature, and other browsers, such as Safari and Firefox, should be able to use any google.com feature. Now, the project doesn't always live up to that principle, but that's the reasoning behind implementing and specifying a general-purpose API. Sure, but that isn't still the reasoning for the API design. (Btw, I sure hope the API is still somehow prefixed.) Perhaps I misunderstood your question. As described on http://dev.chromium.org/searchbox, the API is exposed on the window.chrome object, but likely a better long-term place for the API is on window.navigator. So, yes, it is currently vendor-prefixed. Also, would be great to see some examples where all of features of the API are being used. My understanding is that Google's SERP uses all the features of the API. Tony designed the API in coordination with the folks who work on Google's SERP. For example, if you enable the instant feature in Chrome and type potato in the omnibox, you should see similar search suggestions in the autocomplete dropdown as you'd see if you typed potato into the google.com search box (assuming you have Google set as your default search provider). The only difference I can see when enabling instant search in Chrome and typing potato is that the current web page gets dimmed somehow. The web page is not updated in any way (it doesn't matter if the current web page is the default search or some other page). The dropdown list under omnibox contains exactly the same entries with and
