fStrange

Я говноруби не знаю, но в mysql коннекторах обычно проверить можно функцией Ping.

Пользуюсь nic.ru для ru
А так, я бы в россии уже не регал ничего на всякий.

Очевидно что вы плохо понимаете как работает openApi раз пытаетесь все время сравнивать то, что вам нужно, с этой технологией.

Там структура такая: есть браузер клиента, с яваскриптом.
Есть сервер сайта.
Есть сервер вконтакте.

Когда человек хочет авторизоваться на сайте он жмет кнопку «авторизоваться через в контакте». Открывается всплывающее окно со страницей с домена вконтакте, там пользоватлеь вводит email/пароль, данные его (логин и пароль) отправляются серверу контакта. Сервер контакта их проверяет и если все ОК отправляет данные серверу сайта, на котором человек авторизуется. Сервер сайта, приняв эти данные, проверяет их и если все ок авторизует человека.

Т.е. проверка подлинности данных происходит на стороне сервера, а не на стороне яваскрипт.

Хранить ключи в яваскрипте/флеше не вариант и так никто не делает. В любом случае нужен дополнительный скрипт на стороне сервера-клиента, который будет проверять подлинность пришедших от сервера-поставщика услуги данных и уже потом передавать их в браузер (аяксом или еще как то)

Ответ на вопрос выше: как определить что посетитель уже залогинен на сайте-поставщике услуги?
Очень просто, сайт-поставщик услуги ставит клиенту свою куку. сайт-клиент ставит на своей странице iframe в котором грузится спецстраница сайта-поставщика со спец параметром типа from=site-client. Сайт-поставщик услуги получив запрос этой страницы смотрит есть ли у человека его кука и если есть то шлет серверу сайта-клиента необходимые данные, а сайт-клиент уже аяксом шлет данные в браузер пользователя.

Весь обмен данными с точки зрения JS происходит в пределах одного домена: через iframe с сайтом-поставщиком и аяксом с сайтом-клиентом.

Весь кроссдоменный обмен данными (между сайтом-поставщиком и сайтом-клиентом) происходит уже на стороне серверов без участия браузеров клиентов и эти данные невозможно перехватить.

Все три рассматриваемых вами продукта — надстройки над общефункциональными цмс. Для небольшого магазина это конечно подойдет (лично я делал на modx, участвовал в допиливании этого самого shopkeeper в свое время). Но если магазин более-менее приличный, почему бы не использовать специализированные цмс? Самые известные — это Magento(shareware), osCommerce(free) и российский shareware продукт WebAsyst Shop-Script. Привожу платные варианты, т.к. они реально проверены временем и выбирать конкретную нужно по задачам

> web приложения исходники которых очень помогут в самообучении.

pear.php.net — мне в свое время очень помогло, в том числе и в обучении

среди андроидов самые достойные камеры у SE

Можно немного подождать до выхода xperia arc, там будет камера аж 8 мегапикселей, и скорей всего довольно приличная

Это точно можно назвать предварительной оптимизацией :)

Почему вы считаете что это ненормально? Сдвинуть нумерацию для всех последующих строк — один ненапряжный запрос.
Сколько нагрузки дадут все эти методы «оптимизации» по сравнению со сдвигом?
Как часто происходит перенумерация по сравнению с обычной выборкой? Может не стоит вообще заморачиваться с тем что происходит крайне редко?
Насколько усложнит и замедлит частые операции выборки дополнительные методы «оптимизации» редкой и ненагружаемой операции?

Мне кажется что вам проще воспользоваться полнофункциональной IDE а не пытать редактор превратить в IDE. Я использую Eclipse

Спасибо, это помогло.

Остро не хватает блога про ГЛОНАСС.

Целый ряд блогозаписей ([1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]) куда лучше выглядел бы в таком специализированном блоге, а не в других.

Посмотрите disqus.com. Опционарно там можно оповещать друзей о комментариях.

MS Jet

Если пишите на билдере, то и думать нечего — firebird.

Например парсится выдача того же гугла, и туда попадают ссылки на сайт. У меня таким образом несколько проектов тоже постоянно появляются на всяких говноблогах на блогспоте.

После миллиона записей MySQL начинает тупить со всем, что сложнее чем выборка по ключу. Действительно ли Вам тут нужен джойн? Я понимаю что он не сложный, но 3 селект запроса по ключу сработают быстрее чем джойн + гораздо больше шансов вытащить значения из кеша.

Еще у меня большое подозрения на блокировки, посмотрите в логах не ждут ли запросы большую часть времени права на лок таблицы.

Как вариант найти файлы, к которым не было обращения определённое время. В этом поможет find (я так понимаю, что хостинг на unix?). -exec удалит файлы.
find ./ -used кол-во_дней_тому_назад -exec rm '{}' \;