On Mon, Feb 22, 2010 at 11:21 AM, Peter Kasting <pkast...@google.com> wrote:
> On Mon, Feb 22, 2010 at 12:02 AM, Aaron Boodman <a...@google.com> wrote:

>> * It would be neat if the keyword ("gtalk" in your example) were
>> derived automatically from the extension name, and if the omnibox were
>> clever about matching. So if you have an extension named "Google
>> Talk", typing "gt" or "gtalk" or "googletalk" would all match. This
>> also elegantly handles the issue of conflicts.

>> * It would be cool if the extension could interact with the omnibox
>> session, rather than just accepting all the input. The way I imagine
>> this working is that if you type "gtalk", you get all the usual
>> suggestions, from your history, bookmarks, etc, along with an
>> additional suggestion for the "Google Talk" extension you have
>> installed which declares it interacts with the omnibox:

>> [☆| gt ]
>> -----------------------------------------------------
>> [ icon | http://www.google.com/talk ]
>> [ icon | gtalk ]
>> [ icon | Google Talk ]
>> ...

>> If you select the "Google Talk" entry and press "Tab", you enter a new
>> mode where you've accepted that you're only dealing with the
>> extension. At this point, the extension could expose additional
>> information to help the user enter the query. For example, it could
>> expose how many arguments it wants, or help with autocompleting, or
>> whatever. So, for the gtalk extension, maybe it takes one argument
>> which is the person to talk to. The omnibox might change to:

>> [ icon | Google Talk: <contact name> ]
>> -----------------------------------------------------
>> [ icon | Google Talk: b...@gmail.com ]
>> [ icon | Google Talk: na...@gmail.com ]
>> [ icon | Google Talk: s...@gmail.com ]
>> ...

>> And of course as you type, the system could keep sending the current
>> query to the extension, which could refine the suggestions.

> The devil is in the details here.  The current omnibox code is not
> particularly amenable to extensions, and any interface we design would have
> two major problems:
> * Very fragile w.r.t. interactions with the rest of the omnibox items
> * May destroy our ability to modify and fix ranking functions

> The basic issue is that minimizing the first problem would be most easily
> done by allowing extensions to register as AutocompleteProviders using the
> existing internal interface, but that means exposing our (currently very
> strange) ranking functions to extensions, which causes the second problem.
>  Any other solution to the first problem has lots of vexing edge cases
> around how the omnibox knows what is supposed to happen and displays it to
> the user.  Consider if the user already has a keyword "gtalk", for example;
> which action takes priority?

> There are numerous other issues that would need to be solved as well, such
> as what to do when there are a large number of entries shown by extensions,
> how to deal with extensions that both want to handle the same input, how to
> ensure that extensions don't break inline autocompletion by having differing
> rankings synchronously versus asynchronously (or by doing a blocking
> operation during the synchronous pass), etc.

> For this reason, I suggest that anyone wanting to design an API here become
> familiar with how the existing system works in enough detail to understand
> the pitfalls involved.

> PK

> --
> Chromium Developers mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev