Я так думаю, что эти правила будут использоваться, если компания, создавшая «Техсредство электронной почты» пожелает на это техсредство получить лицензию на ПО (ну, документ подтверждающий права). Тогда будут сверять: а поддерживает ли техсредство необходимый минимум?
Либо это правила для государственных разработок.
В любом случае нам на этом зацикливаться не стоит :)
Собственно, большая часть документа — краткие описания требований к создаваемому программному обеспечению.
Например: При реализации ТС электронной почты выполняются следующие функции:
1. аутентификация по введенным идентификационным параметрам;
2. выдача сообщений на устройство отображения в соответствии с введенным регистрационным именем (адресом);
3. отправка сообщений в соответствии с введенным адресом (несколькими адресами);
4. добавление нового адреса электронной почты;
5. удаление адреса электронной почты;
6. блокировка адреса электронной почты;
7. организация очереди для отправки сообщений;
8. прием, хранение, передача в сообщениях электронной почты файлов, соответствующих формату MIME.
То есть по сути — очень краткое описание минимального функционала почтового клиента. И так — весь документ.
На работу WWW в целом и рунета в частности это никак не повлияет, так что можно даже не обращать на это внимания.
Хотя, конечно, порадовало следующее:
15. При реализации ТС доменных имен выполняются следующие функции:
15.2. создание новой зоны;
То есть, фактически, ребята решили самостоятельно новые ссTLD выводить :)
Однако меня лично больше радуют сообщения на их сайте, вроде такого: Can't load '/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBD/mysql/mysql.so' for module DBD::mysql: libmysqlclient.so.14: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.
А также неумение пользоваться тегами и
Повторю слова Skipper-а, написанные чуть ниже: микроформаты гораздо более материальны того же веб 2.0 (его берём для примеру, ничего личного), хотя бы потому что есть более-менее понятная спецификация и описание работы (тот же XFN уже встроен в WordPress, а это тоже о чём-то да говорит). Ну, на мой взгляд так.
Оффтоп: если написать XFN в русской раскладке получится ЧАТ. Интересное совпаденьице :)
Да, не оспоришь. Другое дело, что такой резкий прорыв от «ВАЗовских» тИЦ и PR к чему-то третьему «от Bentley», вообще говоря, маловероятен. На мой взгляд.
А если и случится, то уж Google-то точно подсуетятся, чтобы сделать либо что-то похожее, либо просто выкупить новую технологию.
> будет технология лучшая, чем PR (хоть от Google, хоть от другой компании)
> про PR забудут легко и быстро все, кроме историков.
Да нет, легко пожалуй не забудут. Скорее будут использовать как дополнительный показатель. Вот PR явно точнее нашего российско-яндексового тИЦ, а ведь никто про тИЦ не забывает, наоборот: чаще всего ставят одновременно и счётчик тИЦ и счётчик PR.
Поэтому появление новой технологии будет означать лишь увеличение работы для пиарщиков. И новой циферки в счётчиках тИЦ/PR/??.
В качестве самоличного лога ошибок (только для себя) очень неплохо использовать Debug_HackerConsole товарища Котерова. Очень удобно: получается вроде как бы и на сайт ошибки-то выводятся, и самому сайту не мешают.
Но вот в сеть это выставлять уже не стоит, нечего пользователям знать о таком.
А что Вы думаете по поводу, например веб 2.0? Ведь так же: на всех новостных сайтах, во всех колонках и на всех каналах. Вроде бы и надоело уже. Ну, что поделать, если такие названия въедливые и противные у нашего будущего?
А микроформаты — это, на самом деле и вправду хорошо. Особенно когда появятся достаточно хорошие сервисы для работы с ними.
Либо это правила для государственных разработок.
В любом случае нам на этом зацикливаться не стоит :)
Например: При реализации ТС электронной почты выполняются следующие функции:
1. аутентификация по введенным идентификационным параметрам;
2. выдача сообщений на устройство отображения в соответствии с введенным регистрационным именем (адресом);
3. отправка сообщений в соответствии с введенным адресом (несколькими адресами);
4. добавление нового адреса электронной почты;
5. удаление адреса электронной почты;
6. блокировка адреса электронной почты;
7. организация очереди для отправки сообщений;
8. прием, хранение, передача в сообщениях электронной почты файлов, соответствующих формату MIME.
То есть по сути — очень краткое описание минимального функционала почтового клиента. И так — весь документ.
На работу WWW в целом и рунета в частности это никак не повлияет, так что можно даже не обращать на это внимания.
Хотя, конечно, порадовало следующее:
15. При реализации ТС доменных имен выполняются следующие функции:
15.2. создание новой зоны;
То есть, фактически, ребята решили самостоятельно новые ссTLD выводить :)
Однако меня лично больше радуют сообщения на их сайте, вроде такого: Can't load '/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBD/mysql/mysql.so' for module DBD::mysql: libmysqlclient.so.14: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.
А также неумение пользоваться тегами
и- .
(А большой смеющийся смайлик тут)
Оффтоп: если написать XFN в русской раскладке получится ЧАТ. Интересное совпаденьице :)
А если и случится, то уж Google-то точно подсуетятся, чтобы сделать либо что-то похожее, либо просто выкупить новую технологию.
В любом случае, это моё маленькое имхо.
> про PR забудут легко и быстро все, кроме историков.
Да нет, легко пожалуй не забудут. Скорее будут использовать как дополнительный показатель. Вот PR явно точнее нашего российско-яндексового тИЦ, а ведь никто про тИЦ не забывает, наоборот: чаще всего ставят одновременно и счётчик тИЦ и счётчик PR.
Поэтому появление новой технологии будет означать лишь увеличение работы для пиарщиков. И новой циферки в счётчиках тИЦ/PR/??.
Но вот в сеть это выставлять уже не стоит, нечего пользователям знать о таком.
А микроформаты — это, на самом деле и вправду хорошо. Особенно когда появятся достаточно хорошие сервисы для работы с ними.