 fox
II/IDEC networks :: ii.dev.2014 :: / Re: проблема со стилем
|
Login |
[#]
Re: проблема со стилем
51t(lenina,1) — 51t
2014-04-01 09:44:54
в итоге собрал свой парсер
на 2кб, обрабатывающий частные случаи
большой и страшный, но работает. пока будем обходиться тем, что есть
51t(lenina,1) — 51t
2014-04-01 09:44:54
в итоге собрал свой парсер
на 2кб, обрабатывающий частные случаи
большой и страшный, но работает. пока будем обходиться тем, что есть
[#]
Re: проблема со стилем
nwalker(lenina,24) — 51t
2014-04-01 14:46:45
у меня сердце кровью обливается. ну nih-синдром же во все поля.
вот что стоило взять нормальный markdown, в который можно запилить своих обработчиков к тому же, и который нормально читается даже в тексте?..
и, например, стандартный multipart/form-data как вариант для сообщений с аттачами, который и в консоли распаковывается без особых проблем
ну или вот абсолютно фиксированный формат сообщения - почему было не взять привычные http-like заголовки?.. просто и расширяемо же.
моя не понимать.
nwalker(lenina,24) — 51t
2014-04-01 14:46:45
у меня сердце кровью обливается. ну nih-синдром же во все поля.
вот что стоило взять нормальный markdown, в который можно запилить своих обработчиков к тому же, и который нормально читается даже в тексте?..
и, например, стандартный multipart/form-data как вариант для сообщений с аттачами, который и в консоли распаковывается без особых проблем
ну или вот абсолютно фиксированный формат сообщения - почему было не взять привычные http-like заголовки?.. просто и расширяемо же.
моя не понимать.
[#]
Re: проблема со стилем
51t(lenina,1) — nwalker
2014-04-01 15:12:55
простая реализация может быть кривой. она может быть хорошей и может быть плохой. она не может быть только одной - сложной. иначе это не простая реализация.
нет, markdown-обработчики точно не нужны. во-первых, они не есть простые, я даже с трудом представляю, что это такое (свои обработчики) и как это выглядит.
во-вторых, текстом не предусматривается никакое обестекчивание (можно делать маркдауны, текстили и прочее, свои клиенты, и общаться в своих эхах - лишь бы для других было читаемо).
потому что проще делать текстовые клиенты, хоть на tk, qt, хоть когда-нибудь голдед начать поддерживать, и если тащить форматирование в стандарт - это всё будет ужасно.
есть только три крайних случая:
это ответ, который надо выделять на любом клиенте, кроме txt
это плоский текст, который на html теряет форматирование и табы
и это гиперссылка, которую в вебе подчёркивать - это самая естественная вещь
никаких исключений из этого стандарт не предусматривает. прикручивать непонятную штуку, усложняющую процесс, вместо того, чтобы за 10 минут сделать свою рабочую реализацию - вот это мне точно непонятно. впрочем, в моей версии раньше был textile, сейчас нет.
атачи вообще не предусмотрены. а, поскольку base64 уже активно используется - то и нормально в него паковать. что может быть проще base64, паковки-распаковки хоть в python, хоть в busybox - это одна строка
про формат сообщений не понял. если про само устройство, то совершенно однозначно - простой текст по определённому номеру строки проще, чем, конечно, очевидный key: value. и разбирать его проще, даже с помощью head/tail
и из таких маленьких мелочей и складывается общий формат. и смысл предпочесть одно другому именно в том, насколько это можно просто реализовать в сторонних условиях, будь то скрипт для conky или удовлетворени простого любопытства. в каждом случае это компромисс, и я принимаю решение, которое больше отвечает поставленной задаче. если я начну что-то переусложнять или добавлять - это убъёт сам смысл (простое и запускается везде).
кроме того, мне нужна рабочая реализация, а не потенциальная. она у меня есть. я не могу сравнивать рабочие реализации с потенциальными :)
51t(lenina,1) — nwalker
2014-04-01 15:12:55
простая реализация может быть кривой. она может быть хорошей и может быть плохой. она не может быть только одной - сложной. иначе это не простая реализация.
нет, markdown-обработчики точно не нужны. во-первых, они не есть простые, я даже с трудом представляю, что это такое (свои обработчики) и как это выглядит.
во-вторых, текстом не предусматривается никакое обестекчивание (можно делать маркдауны, текстили и прочее, свои клиенты, и общаться в своих эхах - лишь бы для других было читаемо).
потому что проще делать текстовые клиенты, хоть на tk, qt, хоть когда-нибудь голдед начать поддерживать, и если тащить форматирование в стандарт - это всё будет ужасно.
есть только три крайних случая:
это ответ, который надо выделять на любом клиенте, кроме txt
это плоский текст, который на html теряет форматирование и табы
и это гиперссылка, которую в вебе подчёркивать - это самая естественная вещь
никаких исключений из этого стандарт не предусматривает. прикручивать непонятную штуку, усложняющую процесс, вместо того, чтобы за 10 минут сделать свою рабочую реализацию - вот это мне точно непонятно. впрочем, в моей версии раньше был textile, сейчас нет.
атачи вообще не предусмотрены. а, поскольку base64 уже активно используется - то и нормально в него паковать. что может быть проще base64, паковки-распаковки хоть в python, хоть в busybox - это одна строка
про формат сообщений не понял. если про само устройство, то совершенно однозначно - простой текст по определённому номеру строки проще, чем, конечно, очевидный key: value. и разбирать его проще, даже с помощью head/tail
и из таких маленьких мелочей и складывается общий формат. и смысл предпочесть одно другому именно в том, насколько это можно просто реализовать в сторонних условиях, будь то скрипт для conky или удовлетворени простого любопытства. в каждом случае это компромисс, и я принимаю решение, которое больше отвечает поставленной задаче. если я начну что-то переусложнять или добавлять - это убъёт сам смысл (простое и запускается везде).
кроме того, мне нужна рабочая реализация, а не потенциальная. она у меня есть. я не могу сравнивать рабочие реализации с потенциальными :)