[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Как спастись от mysql-server в KDE 4.2



On 13 March 2009 21:26:58 Alexander GQ Gerasiov wrote:
> На Fri, 13 Mar 2009 20:09:00 +0200
>
> Покотиленко Костик <casper@meteor.dp.ua> записано:
> > В Птн, 13/03/2009 в 13:10 +0300, Artem Chuprina пишет:
> > > Владимир Ступин -> debian-russian@lists.debian.org  @ Fri, 13 Mar
> > >
> > > 2009 14:56:15 +0500:
> > >  >>  ПК> Плохая практика: прога с CLI + фронтенд
> > >  >>  ПК> Хорошая практика: прога с CLI <-- либа --> прога с GUI
> > >  >>
> > >  >> Ну и да, по ходу дела ты, по сути, записал в "плохую практику"
> > >  >> практически все клиент-серверные решения.  Начиная с SMTP и
> > >  >> HTTP :-)
> > >
> > >  ВС> Здесь наверное имелся в виду пример curl и libcurl. Впрочем,
> > >  ВС> наличие библиотеки не обязывает пользоваться именно ею, можно
> > >  ВС> пользоваться возможностями библиотеки и через CLI-программу.
> > > Но мне ВС> кажется, что выделить функционал программы в библиотеку
> > > - это более ВС> гибкий подход, который удовлетворит приверженцев
> > > любого лагеря: ВС> пользователей CLI, GUI и Web-интерфейсов.
> > >
> > > Моя практика показывает, что в норме приделать к CLI-программе гуй
> > > на скриптовом языке гораздо проще, чем сделать для этого же
> > > скриптового языка обвязку вокруг библиотеки.  Хотя, конечно, если
> > > ее уже кто-то за тебя сделал...
> > >
> > > Нет, я не утверждаю, что выделять библиотеку плохо.  Это хорошо, ибо
> > > повышает гибкость.  Я утверждаю, что заносить unix way в плохую
> > > практику не следует...
> >
> > Не путайте unix-way c <, > и |
> >
> > Первое включает второе, но не ограничивается им.
> >
> > > Но если уж на то пошло, то для _взаимодействия_ с функциональностью
> > > программы я предпочитаю клиент-серверную модель, причем с
> > > _текстовым_ протоколом.  Чтобы можно было сходить туда вручную и
> > > почитать ее ответы глазами.  Вот SMTP, FTP и HTTP в этом смысле
> > > хорошие примеры.
> >
> > Если лень писать инструменты для работы с бинарными данными, остаётся
> > единственное направление движения - в сторону SMTP, FTP, HTTP, XML,
> > BASE64 и другого говна(сори).
>
> Вот не надо. Там где интеркоммуникация гораздо правильнее использовать
> формат, который потенциально читаем человеком (вот почему XML так
> популярен, хотя не все умеют его правильно применять).

И как же его правильно готовить?

Reply to: