OBEX-овое

[vitus_wagner]

Продолжаю потихоньку хакать obexsync, бывший t68tool. Пора бы уже выкладывать, так как по сравнению с t68tool 0.4 есть заметный прогресс - поддерживаются русские (и прочие не Latin-1) имена файлов. Из всех прочих командно-строчных инструментов, виденных мной, на такое заморачивается только BSD-шный obexapp. Остальные ничтоже сумняшеся зовут OBEX_CharToUnicode из libopenobex, которая, ну вы понимаете, попросту вставляет перед каждым байтом 0.

Но хочется ещё в довершение блока работы с перекодировками сделать нормализацию скачиваемых телефонных книжек и календарей. Дело в том, что как было выяснено экспериментальным путем, каждый телефон кодирует VCARD-ы кто во что горазд. Ericsson (ещё с до-Sony-евских времен, с R520) любит UTF-7, попадались также Quoted-printable-encoded Windows-1251 и даже iso8859-5.

В то же время, столь же экспериментально выяснено, что все эти телефоны прекрасно понимают если им передать ENCODING=8BIT;CHARSET=UTF-8. А если хранить записную книжку на компьютере именно в таком виде, то её удобно просматривать текстовым редактором. Опять же, у меня уже есть, и должна войти в комплект утилита поиска по записной книжке (в том числе и умеющая работать query_command в mutt). Она как раз рассчитана на 8bit и utf-8. Поэтому книжку надо нормализовать. Раньше этим занималась внешняя скриптовая обвязка. Но с появлением в 0.4 Bluetooth name resolution она как-то лишняя стала.

Зато всплыла засада с OBEX File Transfer Profile. Почему-то при работе obexftp телефон (один раз за сессию) спрашивает "а правда, что вы хотите дать этому устройству (компьютеру) доступ к вашим данным", а при коннекте t68tool - сразу посылает как unauthorized. Долго смотрел в исходники, так и не понял. Запрос GET формируется совершенно одинаково, значит разница только в CONNECT. Исходный автор t68tool зачем-то пихает туда OBEX_HDR_WHO со значением Linux, но его удаление почти ничего не меняет. А в obexftp туда пихают OBEX_HDR_TARGET с каким-то UUID в качестве значения. В блютусовских спецификациях описания этого UUID не нашел, надо в IrMC-шных искать. Но добавление UUID тоже не помогает, похоже там где-то есть еще какой-то промежуточный обмен сообщениями. Надо бы найти описание, может можно сделать так, чтобы телефон глупых вопросов не задавал. А то впихнуть всю транзакцию в один вызов командно-строчной утилиты вряд ли получится.

Еще выяснилось что почему-то для IrMC надо делать GET с полным путем (telecom/pb.vcf), а для FTP - сначала SETPATH в нужное место, а потом GET без пути - иначе не работает. Ну эту логику я как раз уже впихнул. Правда, опять же спецификации читать надо - это заморочка конкретного телефона или общий принцип. Если первое, то надо эту фичу делать отключаемой, и позволять каким-то образом делать GET по полному пути без SETPATH.

Comments

[alexkuklin.livejournal.com]

готов поучаствовать в тестировании.
надо только bt dongle откопать

[vitus_wagner]

У тебя ж вроде на ноуте bluetooth встроенный. Впрочем, оно и через IrDA умеет. И даже через serial, хотя на телефоне жены пока не пробовал. Там USB-шный кабель глюковатый. Хотя с gprs удалось добиться устойчивой работы.

[alexkuklin.livejournal.com]

у меня MaxSelect надо в гарантию везти :(

[vitus_wagner]

Я фигею с этих современных ноутбуков. Ты - только что купил, в гарантию везешь. besm6 тут недавно месяц его чинил (правда, он на него упал). То ли дело IBM Thinkpad прошлого века выпуска - и кошка со стола роняла и ещё много что случалось, а хоть бы хны.

[the--listener.livejournal.com]

Что делать... Все портится, а к тому, подо что оно портится, у нас нет драйверов...

Новые thinkpad-ы тоже не фонтан. В контрое две недели назад сдох T42, который несколько раз роняли. До какого-то момента все было хорошо, потом начал перегружаться, и в какой-то момент просто умер - микротрещина в плате. Конструкция внутри очень хлипкая, кроме двух направляющих - все пластиковое. (Я-то привык, к Dell-ам, у которых нормальная металлическая рама).

Есть, правда, надежда, что прикупленный на смену Z61m будет лучше.

А со мной, год назад, был случай - шел, поскользнулся по гололеду, упал на спину. На спине был рюкзак, в рюкзаке - мой старый Inspiron 8600. У меня легкое сотрясение, у ноута миллиметра на два в середине прогнулась крышка. (Я представил, что было бы, если бы она была пластиковая и решил сам больше никогда не брать ноутов в пластиковых корпусах и другим не советовать.)

[http://users.livejournal.com/_slw/]

а под фрей работать будет?

[vitus_wagner]

Не обещаю, но патчи приму с благодарностью.
В принципе, всё Bluez-специфичное там в отдельный маленький файлик вынесено.

[phd_ru]

Некоторые телефоны требуют SETPATH, некоторые требуют полного пути, а некоторые работают и так, и эдак. Я уже сталкивался с этим в программе http://phd.pp.ru/Software/cellphones/ .

[vitus_wagner]

За информацию спасибо, но что-то я не увидел у тебя в скрипте описаний на эту тему. Описал бы свой experience немножко более человеческими словами.
Вот в исходниках свежего (0.22pre4) obexftp интересную информацию нашел.

[phd_ru]

А у меня в скрипте и нет ничего, к сожалению. Я знаю из экспериментов и баг-репортов, что Сони-Эриксоны требуют SETPATH, Сименсы требуют полный путь. А про остальные телефоны просто не знаю.

[vitus_wagner]

Кстати, в твоем скрипте, на мой взгляд, есть один недостаток. Для его вызова требуется явное указание cd transport#obex.
Нет бы приделать к нему какое-нибудь специальное расширение (например .ot от obex transport), и прописать в .mc/ext его обработку по enter.

А вообще в спецификации OBEX явно написано, что доступ к telecom/* должен осуществляться с полным путем, а ко всему остальному - с SETPATH.

[phd_ru]

К моему скрипту это не имеет отношения - я же не могу это сделать изнутри самого скрипта. Настроить mc нужным образом - задача пользователя. Она вполне разрешима, тем более что про специальную команду %cd в документации в скрипте сказано.

[kouzdra.livejournal.com]

Мне проще - у меня телефон никак не передает и никак не принимает

А если бы и принимал - телефонная книжка латиницей набрана :)