Каждый флажок соответствует одному или нескольким объектам недвижимости, информация о которых получается с помощью Javascript-робота, один из которых работает незаметно в фоне, пока вы пользуетесь картой. Добавляя новый объект в базу и, соответственно, новый флажок на карту.
По поводу актуальности: этот общий вопрос для всех поисковых систем. Информация из каталога может устареть, как устаревает страница в кэше обычного поисковика. Решение одно: чаще запускать робот.
Под www.maperty.ru в iframe запущен робот. Робот живет на домене maperty-robot.appspot.com, на котором также находится прокси. URL, который вы указали, это URL страницы одного из агентств недвижимости, которую робот загрузил через прокси для анализа. Эта страница обращается к top. Это её право, зачем-то это им видать нужно. Но top (www.maperty.ru) находится для неё в кросс-домене. Очевидно, такой доступ запрещен. Но только роботу это нисколько не мешает. В консоли могут быть и другие сообщения, например о незакрытых тегах, но эти же сообщения вы увидите, если откроете анализируемую страницы напрямую без прокси. Здесь нет никаких проблем.
Почти всё. Сервер просто раздает задачи и собирает результаты. В большинстве случаев, чтобы подключить новый каталог, нужно открыть специальную страницу и просто указать его URL. Этот URL отправляется на сервер который, пускает его «по этапу»: выделяет сам каталог от прочей ненужной информации, выделяет его элементы и ссылки на них, делает много разных действий, и в конечном счете распознает о отправляет на сервер данные. Всё это делается на клиенте, но на Maperty пользователи сейчас могут наблюдать и участвовать только в последнем из перечисленных действий. Всё остальное пока закрыто.
> это просто жесточайшее нецелесообразное использование компьютерного времени
Это использование времени, когда компьютер простаивает, поэтому оно не может быть нецелесообразным, невыгодным или ещё каким-то в этом роде. К тому же, время указано сильно приблизительно и зависит от многого: от канала пользователя, производительности его машины и активности самого пользователя и в может сокращаться до нескольких секунд. А главное, что параллельно свои задачи может выполнять любое число пользователей, что позволяет масштабировать систему в очень широких пределах.
> А уж вирусораспространителям такой сайт просто радость — делай сайты с вирусованным Javascript тоннами, и натравливай Ваших посетителей на них.
Система не открывает произвольные сайты, «натравить» кого-либо на них не получится. Есть, конечно, техническая возможность взломать сайт какого-нибудь агентства недвижимости, внедрить туда вредоносный код и ждать, пока его кто-нибудь откроет. Но для этого и предназначен Google Safe Browsing API. К тому же, точно так же вы можете получить «подарочек» на любом сайте, который был взломан, в том числе и на сайте агентства недвижимости.
> 2) Вы не можете защититься от того, что пользователь Вам вернет ядовитые данные, вместо реальной обработоки целевого URLа (Снять квартиру в районе «buy viagra www_spam-site.spam» за «buy viagra» рублей в месяц).
> 2а) Вам вообще могут не те резльутаты возвращать
Конечно, пользователь может попытаться подменить результат. Правда произвальный текст передать не получится, но можно, например, попытаться передать в 10 раз большую цену. Но как было написано в статье, в систему встроена защита от такой ситуации. Каждая задача (разбор одной и той же страницы) отдается на выполнение разным пользователям (с разными IP-адресами), и сервер проверяет чтобы их вычисления совпадали. Робот сам выбрать задачу не может, их раздает сервер (в случайном порядке).
>3) Вас могут (справедливо) занести в тот же Safe Browsing API за то, что во фрейме какой-нибудь вирус откроется
Как опять же написано в статье, всё, что загружается во фрейм, проходит через нашу web-прокси и следовательно это можно контролировать.
> не видел я сайтов (особенно крупных и которые имеет смысл парсить) которые бы не были в достаточной степени видны, БЕЗ Javascript
vashdom-spb.ru/arenda.php — это то, что просто навскидку в голову пришло, из ресурсов, которые мы обрабатывали. Выдача данных полностью формируется с помощью AJAX. Разумеется, это не единственный пример.
> Далее, Вы не можете спокойно запустить 100 компьютеров вместо того чтобы ждать 10 посетителей
Тут даже говорить не о чем: сколько стоит поставить и обслуживать 100 компьютеров? А если 100 станет мало? Посетители не стоят ничего.
> а когда поток посетителей кончится
Если нет посетителей, то и данные обрабатывать не для кого. Ресурс же существует не для того, чтобы просто существовать.
Подключить к Maperty новый источник сейчас можем только мы — разработчики. Maperty это пока эксперимент, и полигон для проверки наших идей. Мы прежде всего работаем над технологией, чтобы можно было обрабатывать как можно более разнообразные сайты и не только про недвижимость. Штука в том, что тема может быть любой.
Давайте внесём ясность в созданную мной путаницу. UiBinder это фреймворк, входящий в состав GWT, который позволяет создавать части интерфейса используя HTML и CSS. Эти самые части и называются UiBinder-шаблонами (UiBinder templates), потому что их можно использовать в интерфейсе сколько угодно раз. Чтобы статья была проще, я намеренно старался не приплетать UiBinder, поэтому «UI-шаблон» нужно понимать как «UiBinder template». Так что вы хотите узнать о UiBinder и/или о UiBinder-шаблонах?
Я вас неправильно понял, вы говорите о квотах CPU в минуту. К счастью, их больше нет. Об этом Nick Johnson (из команды App Engine в Google) писал не раз, например, вот тут. А документация опять отстает.
По поводу актуальности: этот общий вопрос для всех поисковых систем. Информация из каталога может устареть, как устаревает страница в кэше обычного поисковика. Решение одно: чаще запускать робот.
Это использование времени, когда компьютер простаивает, поэтому оно не может быть нецелесообразным, невыгодным или ещё каким-то в этом роде. К тому же, время указано сильно приблизительно и зависит от многого: от канала пользователя, производительности его машины и активности самого пользователя и в может сокращаться до нескольких секунд. А главное, что параллельно свои задачи может выполнять любое число пользователей, что позволяет масштабировать систему в очень широких пределах.
> А уж вирусораспространителям такой сайт просто радость — делай сайты с вирусованным Javascript тоннами, и натравливай Ваших посетителей на них.
Система не открывает произвольные сайты, «натравить» кого-либо на них не получится. Есть, конечно, техническая возможность взломать сайт какого-нибудь агентства недвижимости, внедрить туда вредоносный код и ждать, пока его кто-нибудь откроет. Но для этого и предназначен Google Safe Browsing API. К тому же, точно так же вы можете получить «подарочек» на любом сайте, который был взломан, в том числе и на сайте агентства недвижимости.
Эээ… А зачем их контролировать?
> 2) Вы не можете защититься от того, что пользователь Вам вернет ядовитые данные, вместо реальной обработоки целевого URLа (Снять квартиру в районе «buy viagra www_spam-site.spam» за «buy viagra» рублей в месяц).
> 2а) Вам вообще могут не те резльутаты возвращать
Конечно, пользователь может попытаться подменить результат. Правда произвальный текст передать не получится, но можно, например, попытаться передать в 10 раз большую цену. Но как было написано в статье, в систему встроена защита от такой ситуации. Каждая задача (разбор одной и той же страницы) отдается на выполнение разным пользователям (с разными IP-адресами), и сервер проверяет чтобы их вычисления совпадали. Робот сам выбрать задачу не может, их раздает сервер (в случайном порядке).
>3) Вас могут (справедливо) занести в тот же Safe Browsing API за то, что во фрейме какой-нибудь вирус откроется
Как опять же написано в статье, всё, что загружается во фрейм, проходит через нашу web-прокси и следовательно это можно контролировать.
> не видел я сайтов (особенно крупных и которые имеет смысл парсить) которые бы не были в достаточной степени видны, БЕЗ Javascript
vashdom-spb.ru/arenda.php — это то, что просто навскидку в голову пришло, из ресурсов, которые мы обрабатывали. Выдача данных полностью формируется с помощью AJAX. Разумеется, это не единственный пример.
> Далее, Вы не можете спокойно запустить 100 компьютеров вместо того чтобы ждать 10 посетителей
Тут даже говорить не о чем: сколько стоит поставить и обслуживать 100 компьютеров? А если 100 станет мало? Посетители не стоят ничего.
> а когда поток посетителей кончится
Если нет посетителей, то и данные обрабатывать не для кого. Ресурс же существует не для того, чтобы просто существовать.