Так не будет ли этот самый plugin тем самым, что нужно “скачивать и устанавливать”? Это первая проблема (самопротиворечие, свидетельствующее о том, что вы сами толком не понимаете, зачем именно все это нужно).
Вторая проблема - что такой plugin придется писать для каждой ОС отдельный - везде ведь способ общения с устройствами - разный.
Если изобретать велосипед и таки пытаться сделать не так, а как-то иначе - сулит обязательно, при том результат вовсе не обязательно достижим вообще.
Если стандартным путем - то тоже, в общем, сулит, хотя и иного рода.
“Ничего не устанавливать” - это идея ради идеи, никакой ценности и смысла не имеющая. Web стэк умеет всё, что необходимо для написания полноценного навигатора - как онлайн, так и полностью standalone, но начнём с того что пока он в разы, если не на порядки проигрывает по производительности нативным приложениям, тогда как для мобильных устройств энергопотребление - критический фактор. Далее, реальность такова, что если на web стеке либо у вас будет standalone приложение, его также придётся так или иначе устанавливать и обновлять (причём нестандартным для системы способом). Если же будет сервис, это будет означать, во-первых, недоступность в нужный момент (связь ужасна даже в городе, не говоря уже о замкадье. пшик, и нет у вас навигатора), во-вторых, необходимость поддержки (кем-то) инфраструктуры этого сервиса, а значит вас будут доить платными возможностями или показывать рекламу, в-третьих, полную зависимость от хозяев сервиса, у которых будет свой, единственно правильный взгляд на юзабилити, и в случае несовпадения его с вашим, вы даже не сможете остаться на предыдущую версию. Наконец, сервис может закрыться, и у вас не останется вообще ничего. К слову, последние два пункта верны и для standalone web приложения.
В то же время у соседа на нативном приложении всё будет быстро, не будет зависеть от качества связи, не будет сажать батарейку за полчаса и при этом бесплатно.
Правильное замечание. Количество пользователей использующих навигацию со стационарного компьютера не велико. Поэтому можно на них забить. Но тут встает другая проблема - как (лично мне) разрабатывать приложение использующее геолокацию?
Нашел, что в Опере можно указать “Location Provider URL”. Поставил туда свой сайт. Опера туда при каждом определении местоположения стучится. Но что она хочет получить в ответ - я так и не нашел.
А я кстати понял чего хочет топик-стартер. Просто (как обычно) средства и цели перепутаны. Попробую объяснить.
Например, скайп умеет устанавливаться как плагин к браузеру и звонить по найденным в тексте страниц телефонам. Outlook умеет подниматься по ссылкам на mailto://. Что говорить, даже josm умеет подниматься по ссылкам с веб-страниц!
Так вот, для адресов это тоже было бы крайне логично. Увидел на вебстранице адрес, щелкнул по нему, открылся навигатор, с точкой финиша из адреса. Особенно это было бы логично на мобильном устройстве, на котором есть и браузер и навигатор. Наверняка есть навигаторы, которые так и работают))
Что касается браузера и небраузера.
Разница между браузером и небраузером постепенно стирается. Большая часть современных приложений общается с сервером по протоколу http, а установка приложений для того же андроида не сложнее “установки” закладки в браузере.
Думаю это бы взлетело на мобильниках, когда адреса влом вводить с виртуальной клавиатуры. Но врятли оно осуществимо без какой нибудь adressto://, да навигаторские проги не поддреживаю адрес из командной строки, да и API в них не наблюдается.
Но ТС говорил про маршрутизацию в браузере, а не запуск навигатора.
Да. Потому что javascript, на котором пишутся плагины, например, к firefox, не умеет работать ни с какими портами. Для этого нужна, например, вот такая хреновина: http://activexperts.com/serial-port-component/howto/firefox/
А для MS IE, например, придется писать другой. То же для Оперы и хрома. И под каждую ОС.