Эм, а смысл? confirm, как и alert, стандартный диалог. Реализации есть во всех браузерах. Мне думается что надо стремиться к единообразному поведению приложения (я ведь и в firefox могу сделать так чтоб он у меня не спрашивал подтверждения загрузки).
«Определяй поддержку функциональности а не браузер» — хорошее правило. Но поскольку join есть везде, то можно просто подменять нативную реализацию на свою в определённых браузерах и везде использовать Array.join(). Это будет и удобно и производительность просядет минимально (черновик. в нём наверняка есть что исправить).
> Фактически можно полностью продублировать любой запрос не из плагина.
Ну. Защититься нельзя. А так каждый плагин будет иметь уникальную «метку», основанную на вашем же api (этим данным можно верить). Если поведение плагина будет отличаться от среднестатистического (=> кто-то использует api не из плагина) его можно забанить.
Что тут можно ещё посоветовать? Использовать https? Обфусцировать код плагина? Использовать NaCl? Писать говнокод чтобы затруднить жизнь желающему покопаться во внутренностях плагина?
> Теперь они разворачиваются на всё окно оперы, но не больше. При таком развороте как я понимаю аппаратное ускорение не работает напрочь, ибо жуткие тормоза.
Больше похоже на то что используется HTML 5 версия плеера.
В appstats нет. Только API. Можно только примерно прикинуть сколько вызовов нужно странице.
А в боевом окружении подробная статистика будет в Quota Details. Общее количество операций: квоты read/write + подробная детализация по операциям.
А нет. Вру. Вот тут свежие и точные данные. get по 1 read операции на сущность. Итого 5 операций.
RPC == API == высокоуровневые операции. А квоты (50k операций) низкоуровневые.
Если get, то одна. Если put, то тоже одна, но ещё процессорное время потратится. Так при bulkload легко за несколько секунд реального времени потратить несколько часов CPU (~60k записей).
