![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Хочу в деревню
Feb. 20th, 2007 11:42 am
Или не в деревню. Но чтоб километров 300-500 по трассе. 200 км, проеханных в воскресенье - мало. Только аппетит разыгрался.
Feb. 20th, 2007
Или не в деревню. Но чтоб километров 300-500 по трассе. 200 км, проеханных в воскресенье - мало. Только аппетит разыгрался.
И ещё о голубых зубах
Feb. 20th, 2007 03:02 pmПосле того как меня просветили в комментах, я таки собрался, выкачал спецификацию Bluetooth и немного её почитал.
Вынужден признать, что в той хаутушке, по которой я писал предыдущий пост, много не то что неточностей, а просто неверной информации. Надо собираться и писать более другой пост. Перерисовывать на русский язык диаграммы соотношения протоколов из спецификации и т.д.
Довольно ериличное общее описание технологии bluetooth для совсем юзеров я нашел на сайте bluejack.ru. На первый взгляд прямых противоречий спецификации не выявлено
Но вообще, забавно насколько авторы всяких opensource прибамбасов для работы с голубыми зубами не думают о usability. Рассмотрел ещё две утилиты - obexpushd и ussp-push, из Debian testing. В первой в документации нет ни слова о том, как организовать работу obex-сервера, хотя на моем уровне понимания очевидно, что программа поддерживает аж два способа такой огранизации - внутрисессионный (аналог kobexsrv, только без GUI), и per system, когда obexpushd висит в виде демона. Впрочем, интерфейс ни под то, ни под другое не заточен. Надо свой obex push daemon писать. Благо кода там килобайт на 20. Кроме того, отсутствует бэк-резолвинг адресов устройств в имена. Очевидно, что пользователю много понятнее сообщение "Устройство Ericsson T610 прислало вам файл", чем "устройство XX:XX:XX:XX:XX:XX прислало вам файл".
Вторая утилита - это Obex клиент. К сожалению, работа с bluetooth device names не предусмотрена. Слова device name в мануале присутствуют, но почему-то под ними имеется в виду /dev/rfcommX. Блин, какое мне дело до этого самого /dev/rfcomm (тем более что по хорошему счету он нафиг не нужен для работы с OBEX, libopenobex можно сразу на rfcomm-сокет натравливать. У меня вон на домашней машине вообще RFCOMM_TTY в ядре нет, а OBEX прекрасно работает).
Надо что-ли t68tool пошире порекламировать, благо там после прочтения предыдущей хаутушки я уже написал работу с именами и SDP. Пожалуй, надо только дописать возможность задавать отдельно имя файла на устройстве и файла на локальной машине при операциях send, get и push (в t68tool push - это посылка через OBEX Push Profile, а send - через OBEX File Transfer).
Вынужден признать, что в той хаутушке, по которой я писал предыдущий пост, много не то что неточностей, а просто неверной информации. Надо собираться и писать более другой пост. Перерисовывать на русский язык диаграммы соотношения протоколов из спецификации и т.д.
Довольно ериличное общее описание технологии bluetooth для совсем юзеров я нашел на сайте bluejack.ru. На первый взгляд прямых противоречий спецификации не выявлено
Но вообще, забавно насколько авторы всяких opensource прибамбасов для работы с голубыми зубами не думают о usability. Рассмотрел ещё две утилиты - obexpushd и ussp-push, из Debian testing. В первой в документации нет ни слова о том, как организовать работу obex-сервера, хотя на моем уровне понимания очевидно, что программа поддерживает аж два способа такой огранизации - внутрисессионный (аналог kobexsrv, только без GUI), и per system, когда obexpushd висит в виде демона. Впрочем, интерфейс ни под то, ни под другое не заточен. Надо свой obex push daemon писать. Благо кода там килобайт на 20. Кроме того, отсутствует бэк-резолвинг адресов устройств в имена. Очевидно, что пользователю много понятнее сообщение "Устройство Ericsson T610 прислало вам файл", чем "устройство XX:XX:XX:XX:XX:XX прислало вам файл".
Вторая утилита - это Obex клиент. К сожалению, работа с bluetooth device names не предусмотрена. Слова device name в мануале присутствуют, но почему-то под ними имеется в виду /dev/rfcommX. Блин, какое мне дело до этого самого /dev/rfcomm (тем более что по хорошему счету он нафиг не нужен для работы с OBEX, libopenobex можно сразу на rfcomm-сокет натравливать. У меня вон на домашней машине вообще RFCOMM_TTY в ядре нет, а OBEX прекрасно работает).
Надо что-ли t68tool пошире порекламировать, благо там после прочтения предыдущей хаутушки я уже написал работу с именами и SDP. Пожалуй, надо только дописать возможность задавать отдельно имя файла на устройстве и файла на локальной машине при операциях send, get и push (в t68tool push - это посылка через OBEX Push Profile, а send - через OBEX File Transfer).