Прикольно! Так это по сути, наверное, глюк GR, видимо, не тестировали этот момент. Потому что на интенсивных папках и потоках прокрутить это невозможно =)
Таки да, вы правы, хранит более 30 дней… спасибо!
Осталось значит сделать какой-нибудь хак для GR, который показывает эти данные в удобном виде =)
Дело в том, что дело не только в привязке к пользователю, но и в самих записях (контенте) — заголовок, текст, url и др. служебная информация.
Устройство GR примерно такое:
1. Робот (много мощных серверов) качают не переставая RSS-записи с миллионов серверов (ведь rss можно добавить любой, это универсально)
2. Они складывают эти записи в БД.
3. Юзеры подписываются на существующие каналы или добавляют новый поток (который не знает GR)
3.1. Если поток уже находится в GR, то он его просто быстро выдаёт юзеру (кеш)
3.2 Если поток новый для GR, то он качает его, добавляет в свою БД и далее пункт 3.1
Так вот в чём дело — хранить все эти потоки за целый ОДИН МЕСЯЦ и то наверняка стоят гуглу громадных ресурсов, поэтому они и сделали это ограничение.
Обычно rss — это лишь обновления, типа коротких новостей, ну, если сравнивать, то по типу flash-sms, которые всплывают и потом не хранятся в памяти. Если уж очень нужен свой бесконечный кеш для rss-записей, ничего сложного нет, просто написать свой в виде расширения для GR. Я даже уверен, что такой уже написан.
Возникает вопрос с подделкой и правкой данных. Предусмотено ли у вас так называемый read-only режим данных? Можно ли увидеть, кто и когда правил текст и что было до изменений?
А то ведь, приходит пациент в больницу, ему написали, что он болеет гриппом, но диагноз поставили неверно. Стали лечить, ему стало хуже. Бумажек нету, удобно, да. Но взяли и исправил в «электронной карте» грипп на спид. Претензий от судов не будет.
То есть, электронно то электронно, но ведь легко всё подделать и как мне каежтся, закона в этом направлении пока не предусмотрено и даже способов read-only-шифрования нету, наверное? То есть, чтобы нельзя было исправить без следов.
Угу, могли бы сделать так — сначала заполняется сверху по-горизонтали, а потом уже вертикальные табы. А то сверху опять остаётся пустая строка. Туда хотя бы можно было бы сделать те же закладки…
К сожалению, пока вы будете копаться в машинных кодах и экономить биты, прогресс уйдёт так далеко, что вам эти биты покажутся смешными.
Даже уже сейчас память компьютера стоит 1 тыр за 4 Гбайта.
А ведь когда то Билли сказал, что 640 кбайт хватит всем.
Вам никто не запрещает писать маленькие программы, но рынок есть рынок. Рынок драйверов и маленьких программ для каких-нибудь микроконтроллеров в холодильнике и т.п. — отличное приложение таланта высококвалифицированных специалистов, коих я считаю всех тех, кто понимает и разбирается в ассемблере.
Хотя сейчас компиляторы С++ так развиты, что позволяют писать эффективные программы не хуже чем на ассемблере (как в скорости работы программы, так и в скорости разработки и дальнейшей поддержки).
С этим я тоже согласен, раньше вообще был очень серьёзным сторонником ассемблера и не признавал ЯВУ (языки высшего уровня).
Но сейчас удобнее разрабатывать программы на ЯВУ, например, на том же js. Компиляторы стали быстрые, в том числе и интерпретаторы.
А ассемблер и машинные коды — удел драйверов и других узких мест. Писать интерфейс работы с кнопкой, который будет работать раз в час по клику пользователя на машинных кодах — маразм и лишняя потеря времени.
Помню, раньше переходники IDE-USB продавали за 2 тыр руб, сейчас они по 200 руб
А вот подтягивать старые записи в реальном времени — вполне возможно, но вряд ли…
Таки да, вы правы, хранит более 30 дней… спасибо!
Осталось значит сделать какой-нибудь хак для GR, который показывает эти данные в удобном виде =)
30 дней pix.am/qO3U.png
Устройство GR примерно такое:
1. Робот (много мощных серверов) качают не переставая RSS-записи с миллионов серверов (ведь rss можно добавить любой, это универсально)
2. Они складывают эти записи в БД.
3. Юзеры подписываются на существующие каналы или добавляют новый поток (который не знает GR)
3.1. Если поток уже находится в GR, то он его просто быстро выдаёт юзеру (кеш)
3.2 Если поток новый для GR, то он качает его, добавляет в свою БД и далее пункт 3.1
Так вот в чём дело — хранить все эти потоки за целый ОДИН МЕСЯЦ и то наверняка стоят гуглу громадных ресурсов, поэтому они и сделали это ограничение.
chrome.google.com/webstore/search?hl=en-US&q=google+reader
А то ведь, приходит пациент в больницу, ему написали, что он болеет гриппом, но диагноз поставили неверно. Стали лечить, ему стало хуже. Бумажек нету, удобно, да. Но взяли и исправил в «электронной карте» грипп на спид. Претензий от судов не будет.
То есть, электронно то электронно, но ведь легко всё подделать и как мне каежтся, закона в этом направлении пока не предусмотрено и даже способов read-only-шифрования нету, наверное? То есть, чтобы нельзя было исправить без следов.
По сути, можно ввести настройку в приложение — экономия памяти, но тогда возможны притормаживания. И каждый будет выбирать, что ему удобно.
Даже уже сейчас память компьютера стоит 1 тыр за 4 Гбайта.
А ведь когда то Билли сказал, что 640 кбайт хватит всем.
Вам никто не запрещает писать маленькие программы, но рынок есть рынок. Рынок драйверов и маленьких программ для каких-нибудь микроконтроллеров в холодильнике и т.п. — отличное приложение таланта высококвалифицированных специалистов, коих я считаю всех тех, кто понимает и разбирается в ассемблере.
Хотя сейчас компиляторы С++ так развиты, что позволяют писать эффективные программы не хуже чем на ассемблере (как в скорости работы программы, так и в скорости разработки и дальнейшей поддержки).
Но сейчас удобнее разрабатывать программы на ЯВУ, например, на том же js. Компиляторы стали быстрые, в том числе и интерпретаторы.
А ассемблер и машинные коды — удел драйверов и других узких мест. Писать интерфейс работы с кнопкой, который будет работать раз в час по клику пользователя на машинных кодах — маразм и лишняя потеря времени.