Это тоже незаконно - но это не воровство, а нарушение авторских прав.
Закон об авторском праве тут тоже скорее всего не поможет. А все потому что ничего незаконного в копировании информации НЕТ. Кроме нескольких исключений, описанных в Законе об авторском праве (смотрим внимательно что является объектом авторского права).
Можно попробовать применить понятие недобросовестной конкуренции, но это еще сложнее.
А потому, уважаемый автор, расслабьтесь.
Выложили свои тексты в открытый источник (коим является веб-сайт), значит будьте готовы что их будут копировать. Не согласны с таким положением вещей - не публикуйте свои тексты, или продавайте их с лицензионным договором.
Сделайте в центральном хранилище примитивное АПИ, которое будет отдавать сайтам-клиентам уже готовые сериализованные массивы.
Да, примерно так и будет сделано. Только данные будут забираться из промежуточного каталога на клиенте, куда "центр" будет пихать обновленные данные. Ну или как-то так, еще не проектировал в деталях. В любом случае спасибо за идею и частичную реализацию ))
admak: Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.
Уже посчитал - максимум 100 мегабайт с учетом расходов на сериализацию.
Расходы на закачку в память массива можно легко решить memcache'м.
admak:
Про модификацию данных молчу - придется делать какую-то админку и проверку на целостность файла при сохранении, а то место закончится - и оп-с сайта уже нет.
Только чтение, модификации нет.
admak:
Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.
Определить в какой файл лезть: берете один или два симола от функции md5($key).
Стремный подход... но для гавников на фрихостах может и покатит. :)
DenisVS: подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.
целостность файлов не критична, это просто viewer, эталон данных хранится в другом месте.
коллизий быть не может доступ только на чтение.
накладные расходы вижу в необходимости серверу поднимать в память весь массив с диска при каждом обращении - можно порешать кэшированием в памяти, если будет критично.
DenisVS: ppchМожет, лучше готовый интерфейс?
Денех жалко. Сайтик этот будет жить во множественных экземпялрах на разных доменах.
Да и не вижу особого смысла преобразовывать данные в формат таблиц баз данных а потом при поиске опять формировать тот же самый пхпшный массив. Это кстати тоже накладные расходы.
---------- Добавлено 10.10.2014 в 08:43 ----------
foxi: Но лучще sqlite тогда уже.
sqlite надо чтобы на хостинге был, и там тоже как-бы файл базы данных формируется, который надо хранить и заботится о его целостности.
учитывая что данных мало и запросы простые... не вижу особого смысла заморачиваться.
Это тоже незаконно - но это не воровство, а нарушение авторских прав.
Закон об авторском праве тут тоже скорее всего не поможет. А все потому что ничего незаконного в копировании информации НЕТ. Кроме нескольких исключений, описанных в Законе об авторском праве (смотрим внимательно что является объектом авторского права).
Можно попробовать применить понятие недобросовестной конкуренции, но это еще сложнее.
А потому, уважаемый автор, расслабьтесь.
Выложили свои тексты в открытый источник (коим является веб-сайт), значит будьте готовы что их будут копировать. Не согласны с таким положением вещей - не публикуйте свои тексты, или продавайте их с лицензионным договором.
Сделайте в центральном хранилище примитивное АПИ, которое будет отдавать сайтам-клиентам уже готовые сериализованные массивы.
Да, примерно так и будет сделано. Только данные будут забираться из промежуточного каталога на клиенте, куда "центр" будет пихать обновленные данные. Ну или как-то так, еще не проектировал в деталях. В любом случае спасибо за идею и частичную реализацию ))
Вам нужно key -> value.
Так возьмите простенькие типа Redis, Memcached и их подобных - быстрые удобные и подходит под Ваши запросы.
Спасибо, посмотрю на эти тулы. Подскажите а как быть с хостингом? Поддерживаются эти средства на минимальных тарифных планах?
Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.
Уже посчитал - максимум 100 мегабайт с учетом расходов на сериализацию.
Расходы на закачку в память массива можно легко решить memcache'м.
Про модификацию данных молчу - придется делать какую-то админку и проверку на целостность файла при сохранении, а то место закончится - и оп-с сайта уже нет.
Только чтение, модификации нет.
Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.
Определить в какой файл лезть: берете один или два симола от функции md5($key).
Стремный подход... но для гавников на фрихостах может и покатит. :)
Подход хороший, думал об этом, спасибо.
подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.
целостность файлов не критична, это просто viewer, эталон данных хранится в другом месте.
коллизий быть не может доступ только на чтение.
накладные расходы вижу в необходимости серверу поднимать в память весь массив с диска при каждом обращении - можно порешать кэшированием в памяти, если будет критично.
ppchМожет, лучше готовый интерфейс?
Денех жалко. Сайтик этот будет жить во множественных экземпялрах на разных доменах.
Да и не вижу особого смысла преобразовывать данные в формат таблиц баз данных а потом при поиске опять формировать тот же самый пхпшный массив. Это кстати тоже накладные расходы.
---------- Добавлено 10.10.2014 в 08:43 ----------
Но лучще sqlite тогда уже.
sqlite надо чтобы на хостинге был, и там тоже как-бы файл базы данных формируется, который надо хранить и заботится о его целостности.
учитывая что данных мало и запросы простые... не вижу особого смысла заморачиваться.
если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.
Да, это я понимаю. В том то и дело что ничего кроме выборки по ключу не надо. То есть структура данных такая: [key] -> [value].
Пхпшный массив отлично подходит для быстрой выборки по ключу, быстрее не надо.
Поэтому и думаю хранить все как сериализованный массив в файле. Но не уверен что прокатит)
Многого хотите, раз PR только 5 начислили, значит и тиЦ сейчас тоже 5
Ну и зачем этот бред писать? Тут же тема для новичков, кто-то ведь может и не понять ваш тонкий юмор.
А вы хотите, чтобы стало?
тиц = 5, pr = 5
хотя бы тиц=10
На мой сайт таких ссылок достаточно много, давно уже обращаю на них внимание.
Вероятно по этой причине тиц=0 и трафик с яндекса падает уже несколько месяцев. При этом траф с гугла растет и пр=5.
тиц = 0, pr = 5
Это нормально?
Я как бы не заморачиваюсь, но такое поведение Яндекса слегка смущает.
За год существования СДЛ траффик с Яндекса упал с 60% до 40%, позиции по запросам тоже падают. Для гугла все наоборот.
Ничего кроме редких покупок ссылок на ГГЛ не делаю.
Надо что-то специальное для Яндекса делать, чтоб поднять тиц и выдачу? Или не стоит дергаться?