Hi,
below proposed API for MAP client in obex-client, for now just some
generic functions and browsing support.
Messages Access hierarchy
=========================
Service org.openobex.client
Interface org.openobex.MessagesAccess
Object path [variable prefix]/{session0,session1,...}
Methods dict(uint8 tag, variant value) GetAppParams()
Retrieve application parameters connected to the last MSE
response. Application parameters corresponding
to given call
are accessible until next request is sent.
Parameters are converted to unsigned integers
of corresponding sizes
(MAP specification section 6.3.1) or
NULL-terminated strings.
In case of parameters not mentioned in MAP
specification value
becomes struct of (uint8 length, array{uint8}).
See MAP specification (section corresponding to
given function)
for more details on returned parameters.
void SetFolder(boolean cdup, string name)
Set working directory for current session.
| cdup | folder name | operation |
|=====================================|
| FALSE | empty | cd / |
|--------+-------------+--------------|
| FALSE | name | cd name |
|--------+-------------+--------------|
| TRUE | [name] | cd ..[/name] |
+-------------------------------------+
array{dict(string property, string value)}
GetFolderListing(dict(uint8 tag, uint16 value))
Retrieve list of names (and all other
properties returned by MSE)
for directories in CWD.
Parameters as in MAP specification section 5.4.
array{dict(string property, string value)}
GetMessageListing(string folder, array{uint8 tag, variant value})
Return message listing for given subfolder of
CWD or directly
CWD if folder field is empty, format of each dict entry
corresponds to the message listing format (MAP
specification
section 3.1.6).
Parameters as in MAP specification section 5.5.
unix_fd msgfd
GetMessage(string handle, dict(uint8 tag, variant value))
Retrieve message from remote device and return
file descriptor,
from which message data (in BMSG format) may be read.
Parameters as in MAP specification section 5.6.
void SetMessageStatus(string handle, uint8 indicator,
uint8 value)
Modify status of a message on remote device.
Parameters as in MAP specification section 5.7.
void UpdateInbox()
Initiate update of inbox status on remote device.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Mon, Nov 7, 2011 at 5:10 PM, Bartosz Szatkowski <[email protected]> wrote:
> On Mon, Nov 7, 2011 at 2:20 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Bartosz,
>>
>> On Mon, Nov 7, 2011 at 2:42 PM, Bartosz Szatkowski <[email protected]> wrote:
>>> On Mon, Nov 7, 2011 at 11:37 AM, Luiz Augusto von Dentz
>>> <[email protected]> wrote:
>>>> Hi Bartosz,
>>>>
>>>> On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <[email protected]> wrote:
>>>>> On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
>>>>> <[email protected]> wrote:
>>>>>> Hi Bartosz,
>>>>>>
>>>>>> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>>>>>
>>>>>>> Generally you may be right, but i'm not sure whether actually tangling
>>>>>>> agent (client of the client?) is a good idea -- I'll check it
>>>>>>> tomorrow, but AFAIR it's ?an additional reversed connection? And
>>>>>>> situation with this big message probably is not so often to cause such
>>>>>>> a confusion. I would really like to use such API in simplest possible
>>>>>>> way, by calling some method and receiving answer and its exactly what
>>>>>>> is accomplished with fd.
>>>>>>
>>>>>> I haven't seen the implementation but I have a feeling it won't be
>>>>>> that simple, if you use the pipe/unix socket to stream the data them
>>>>>> you end up copying data and the stream still need to be handled ?in
>>>>>> client side which will very likely copy/convert the data again. We
>>>>>> have tried such a thing before with A2DP and it was consider
>>>>>> inefficient, so what we do nowadays is passing the bluetooth socket
>>>>>> itself to PulseAudio but note that here it would not be a good idea
>>>>>> since the client would have to deal with OBEX protocol directly.
>>>>>>
>>>>>> You could return the transfer object on GetMessage, actually is is
>>>>>> probably a good idea to do this also for GetFile/PutFile, so that the
>>>>>> caller application have direct control on the transfers it has started
>>>>>> and we can probable have a property e.g. Status (Transferring, Error,
>>>>>> Complete) to indicate the transfer status, that would remove the need
>>>>>> to have an agent in the application although the system may still have
>>>>>> one to track the progress and keep history of the transfers.
>>>>>>
>>>>>> --
>>>>>> Luiz Augusto von Dentz
>>>>>>
>>>>>
>>>>> As far as i can tell adding transfer would be good idea and it's not
>>>>> necessary to actually track it. But there is still question how to
>>>>> transfer data? I'm still convinced that passing fd is good idea, maybe
>>>>> even more flexible would be to pass it from user to obex-client in
>>>>> DBus call, so user may decide whether it would be more convenience to
>>>>> use file, pipe or whatever.
>>>>>
>>>>> So method may look something like this:
>>>>>
>>>>> string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
>>>>>
>>>>> Returning path to the newly created transfer.
>>>>
>>>> As I told you passing a fd to pass data is not very efficient because
>>>> you are just adding an intermediate buffer since obexd will have to
>>>> copy from the socket to the fd where the client read (btw buffering
>>>> the whole message in the client is probably a bad idea), in the other
>>>> hand the fd could be of a file that would probably work better but it
>>>> is no much different than passing a path which was my initial
>>>> suggestion and is probably simpler to implement because we have been
>>>> doing this already. This way when the transfer is completed it just a
>>>> matter of reading the file.
>>>>
>>>> --
>>>> Luiz Augusto von Dentz
>>>>
>>>
>>> Generally GetMessage (x-bt/message) is set to be buffered in
>>> obc_transfer_get - so there is (AFAICT) no real difference what we
>>> would do with this buffer. And if we would like to modify it to use
>>> file buffering, we can use usr provided fd rather then file name and
>>> let client decide where to store it. In sake of user app simplicity,
>>> as you say earlier.
>>
>> That is nothing that couldn't be changed, also whether it is a path or
>> not the user is still deciding where it should be stored but I guess a
>> path is actually less troublesome to the client to deal with since not
>> every binding supports fd passing which can be a problem to end user
>> application which I suppose this API should be targeting, also using
>> paths is consistent with other parts of the code GetFile/PutFile.
>>
>> --
>> Luiz Augusto von Dentz
>>
>
> OK, so maybe this fd passing would be confusing and may be problematic
> if somebody would use java or something.
>
> string GetMessage(string file_name, string handle, dict(uint8 tag,
> variant value))
>
> i think that this is as good as we can settle in this discussion, if
> there is no serious issues in this model maybe i would start coding
> it? (I'll resend full api sometime soon)
Sounds good to me.
--
Luiz Augusto von Dentz
On Mon, Nov 7, 2011 at 2:20 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Mon, Nov 7, 2011 at 2:42 PM, Bartosz Szatkowski <[email protected]> wrote:
>> On Mon, Nov 7, 2011 at 11:37 AM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Bartosz,
>>>
>>> On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <[email protected]> wrote:
>>>> On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
>>>> <[email protected]> wrote:
>>>>> Hi Bartosz,
>>>>>
>>>>> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>>>>
>>>>>> Generally you may be right, but i'm not sure whether actually tangling
>>>>>> agent (client of the client?) is a good idea -- I'll check it
>>>>>> tomorrow, but AFAIR it's an additional reversed connection? And
>>>>>> situation with this big message probably is not so often to cause such
>>>>>> a confusion. I would really like to use such API in simplest possible
>>>>>> way, by calling some method and receiving answer and its exactly what
>>>>>> is accomplished with fd.
>>>>>
>>>>> I haven't seen the implementation but I have a feeling it won't be
>>>>> that simple, if you use the pipe/unix socket to stream the data them
>>>>> you end up copying data and the stream still need to be handled in
>>>>> client side which will very likely copy/convert the data again. We
>>>>> have tried such a thing before with A2DP and it was consider
>>>>> inefficient, so what we do nowadays is passing the bluetooth socket
>>>>> itself to PulseAudio but note that here it would not be a good idea
>>>>> since the client would have to deal with OBEX protocol directly.
>>>>>
>>>>> You could return the transfer object on GetMessage, actually is is
>>>>> probably a good idea to do this also for GetFile/PutFile, so that the
>>>>> caller application have direct control on the transfers it has started
>>>>> and we can probable have a property e.g. Status (Transferring, Error,
>>>>> Complete) to indicate the transfer status, that would remove the need
>>>>> to have an agent in the application although the system may still have
>>>>> one to track the progress and keep history of the transfers.
>>>>>
>>>>> --
>>>>> Luiz Augusto von Dentz
>>>>>
>>>>
>>>> As far as i can tell adding transfer would be good idea and it's not
>>>> necessary to actually track it. But there is still question how to
>>>> transfer data? I'm still convinced that passing fd is good idea, maybe
>>>> even more flexible would be to pass it from user to obex-client in
>>>> DBus call, so user may decide whether it would be more convenience to
>>>> use file, pipe or whatever.
>>>>
>>>> So method may look something like this:
>>>>
>>>> string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
>>>>
>>>> Returning path to the newly created transfer.
>>>
>>> As I told you passing a fd to pass data is not very efficient because
>>> you are just adding an intermediate buffer since obexd will have to
>>> copy from the socket to the fd where the client read (btw buffering
>>> the whole message in the client is probably a bad idea), in the other
>>> hand the fd could be of a file that would probably work better but it
>>> is no much different than passing a path which was my initial
>>> suggestion and is probably simpler to implement because we have been
>>> doing this already. This way when the transfer is completed it just a
>>> matter of reading the file.
>>>
>>> --
>>> Luiz Augusto von Dentz
>>>
>>
>> Generally GetMessage (x-bt/message) is set to be buffered in
>> obc_transfer_get - so there is (AFAICT) no real difference what we
>> would do with this buffer. And if we would like to modify it to use
>> file buffering, we can use usr provided fd rather then file name and
>> let client decide where to store it. In sake of user app simplicity,
>> as you say earlier.
>
> That is nothing that couldn't be changed, also whether it is a path or
> not the user is still deciding where it should be stored but I guess a
> path is actually less troublesome to the client to deal with since not
> every binding supports fd passing which can be a problem to end user
> application which I suppose this API should be targeting, also using
> paths is consistent with other parts of the code GetFile/PutFile.
>
> --
> Luiz Augusto von Dentz
>
OK, so maybe this fd passing would be confusing and may be problematic
if somebody would use java or something.
string GetMessage(string file_name, string handle, dict(uint8 tag,
variant value))
i think that this is as good as we can settle in this discussion, if
there is no serious issues in this model maybe i would start coding
it? (I'll resend full api sometime soon)
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Mon, Nov 7, 2011 at 2:42 PM, Bartosz Szatkowski <[email protected]> wrote:
> On Mon, Nov 7, 2011 at 11:37 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Bartosz,
>>
>> On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <[email protected]> wrote:
>>> On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
>>> <[email protected]> wrote:
>>>> Hi Bartosz,
>>>>
>>>> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>>>
>>>>> Generally you may be right, but i'm not sure whether actually tangling
>>>>> agent (client of the client?) is a good idea -- I'll check it
>>>>> tomorrow, but AFAIR it's ?an additional reversed connection? And
>>>>> situation with this big message probably is not so often to cause such
>>>>> a confusion. I would really like to use such API in simplest possible
>>>>> way, by calling some method and receiving answer and its exactly what
>>>>> is accomplished with fd.
>>>>
>>>> I haven't seen the implementation but I have a feeling it won't be
>>>> that simple, if you use the pipe/unix socket to stream the data them
>>>> you end up copying data and the stream still need to be handled ?in
>>>> client side which will very likely copy/convert the data again. We
>>>> have tried such a thing before with A2DP and it was consider
>>>> inefficient, so what we do nowadays is passing the bluetooth socket
>>>> itself to PulseAudio but note that here it would not be a good idea
>>>> since the client would have to deal with OBEX protocol directly.
>>>>
>>>> You could return the transfer object on GetMessage, actually is is
>>>> probably a good idea to do this also for GetFile/PutFile, so that the
>>>> caller application have direct control on the transfers it has started
>>>> and we can probable have a property e.g. Status (Transferring, Error,
>>>> Complete) to indicate the transfer status, that would remove the need
>>>> to have an agent in the application although the system may still have
>>>> one to track the progress and keep history of the transfers.
>>>>
>>>> --
>>>> Luiz Augusto von Dentz
>>>>
>>>
>>> As far as i can tell adding transfer would be good idea and it's not
>>> necessary to actually track it. But there is still question how to
>>> transfer data? I'm still convinced that passing fd is good idea, maybe
>>> even more flexible would be to pass it from user to obex-client in
>>> DBus call, so user may decide whether it would be more convenience to
>>> use file, pipe or whatever.
>>>
>>> So method may look something like this:
>>>
>>> string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
>>>
>>> Returning path to the newly created transfer.
>>
>> As I told you passing a fd to pass data is not very efficient because
>> you are just adding an intermediate buffer since obexd will have to
>> copy from the socket to the fd where the client read (btw buffering
>> the whole message in the client is probably a bad idea), in the other
>> hand the fd could be of a file that would probably work better but it
>> is no much different than passing a path which was my initial
>> suggestion and is probably simpler to implement because we have been
>> doing this already. This way when the transfer is completed it just a
>> matter of reading the file.
>>
>> --
>> Luiz Augusto von Dentz
>>
>
> Generally GetMessage (x-bt/message) is set to be buffered in
> obc_transfer_get - so there is (AFAICT) no real difference what we
> would do with this buffer. And if we would like to modify it to use
> file buffering, we can use usr provided fd rather then file name and
> let client decide where to store it. In sake of user app simplicity,
> as you say earlier.
That is nothing that couldn't be changed, also whether it is a path or
not the user is still deciding where it should be stored but I guess a
path is actually less troublesome to the client to deal with since not
every binding supports fd passing which can be a problem to end user
application which I suppose this API should be targeting, also using
paths is consistent with other parts of the code GetFile/PutFile.
--
Luiz Augusto von Dentz
On Mon, Nov 7, 2011 at 11:37 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <[email protected]> wrote:
>> On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Bartosz,
>>>
>>> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>>
>>>> Generally you may be right, but i'm not sure whether actually tangling
>>>> agent (client of the client?) is a good idea -- I'll check it
>>>> tomorrow, but AFAIR it's an additional reversed connection? And
>>>> situation with this big message probably is not so often to cause such
>>>> a confusion. I would really like to use such API in simplest possible
>>>> way, by calling some method and receiving answer and its exactly what
>>>> is accomplished with fd.
>>>
>>> I haven't seen the implementation but I have a feeling it won't be
>>> that simple, if you use the pipe/unix socket to stream the data them
>>> you end up copying data and the stream still need to be handled in
>>> client side which will very likely copy/convert the data again. We
>>> have tried such a thing before with A2DP and it was consider
>>> inefficient, so what we do nowadays is passing the bluetooth socket
>>> itself to PulseAudio but note that here it would not be a good idea
>>> since the client would have to deal with OBEX protocol directly.
>>>
>>> You could return the transfer object on GetMessage, actually is is
>>> probably a good idea to do this also for GetFile/PutFile, so that the
>>> caller application have direct control on the transfers it has started
>>> and we can probable have a property e.g. Status (Transferring, Error,
>>> Complete) to indicate the transfer status, that would remove the need
>>> to have an agent in the application although the system may still have
>>> one to track the progress and keep history of the transfers.
>>>
>>> --
>>> Luiz Augusto von Dentz
>>>
>>
>> As far as i can tell adding transfer would be good idea and it's not
>> necessary to actually track it. But there is still question how to
>> transfer data? I'm still convinced that passing fd is good idea, maybe
>> even more flexible would be to pass it from user to obex-client in
>> DBus call, so user may decide whether it would be more convenience to
>> use file, pipe or whatever.
>>
>> So method may look something like this:
>>
>> string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
>>
>> Returning path to the newly created transfer.
>
> As I told you passing a fd to pass data is not very efficient because
> you are just adding an intermediate buffer since obexd will have to
> copy from the socket to the fd where the client read (btw buffering
> the whole message in the client is probably a bad idea), in the other
> hand the fd could be of a file that would probably work better but it
> is no much different than passing a path which was my initial
> suggestion and is probably simpler to implement because we have been
> doing this already. This way when the transfer is completed it just a
> matter of reading the file.
>
> --
> Luiz Augusto von Dentz
>
Generally GetMessage (x-bt/message) is set to be buffered in
obc_transfer_get - so there is (AFAICT) no real difference what we
would do with this buffer. And if we would like to modify it to use
file buffering, we can use usr provided fd rather then file name and
let client decide where to store it. In sake of user app simplicity,
as you say earlier.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <[email protected]> wrote:
> On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Bartosz,
>>
>> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>
>>> Generally you may be right, but i'm not sure whether actually tangling
>>> agent (client of the client?) is a good idea -- I'll check it
>>> tomorrow, but AFAIR it's ?an additional reversed connection? And
>>> situation with this big message probably is not so often to cause such
>>> a confusion. I would really like to use such API in simplest possible
>>> way, by calling some method and receiving answer and its exactly what
>>> is accomplished with fd.
>>
>> I haven't seen the implementation but I have a feeling it won't be
>> that simple, if you use the pipe/unix socket to stream the data them
>> you end up copying data and the stream still need to be handled ?in
>> client side which will very likely copy/convert the data again. We
>> have tried such a thing before with A2DP and it was consider
>> inefficient, so what we do nowadays is passing the bluetooth socket
>> itself to PulseAudio but note that here it would not be a good idea
>> since the client would have to deal with OBEX protocol directly.
>>
>> You could return the transfer object on GetMessage, actually is is
>> probably a good idea to do this also for GetFile/PutFile, so that the
>> caller application have direct control on the transfers it has started
>> and we can probable have a property e.g. Status (Transferring, Error,
>> Complete) to indicate the transfer status, that would remove the need
>> to have an agent in the application although the system may still have
>> one to track the progress and keep history of the transfers.
>>
>> --
>> Luiz Augusto von Dentz
>>
>
> As far as i can tell adding transfer would be good idea and it's not
> necessary to actually track it. But there is still question how to
> transfer data? I'm still convinced that passing fd is good idea, maybe
> even more flexible would be to pass it from user to obex-client in
> DBus call, so user may decide whether it would be more convenience to
> use file, pipe or whatever.
>
> So method may look something like this:
>
> string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
>
> Returning path to the newly created transfer.
As I told you passing a fd to pass data is not very efficient because
you are just adding an intermediate buffer since obexd will have to
copy from the socket to the fd where the client read (btw buffering
the whole message in the client is probably a bad idea), in the other
hand the fd could be of a file that would probably work better but it
is no much different than passing a path which was my initial
suggestion and is probably simpler to implement because we have been
doing this already. This way when the transfer is completed it just a
matter of reading the file.
--
Luiz Augusto von Dentz
On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>>
>> Generally you may be right, but i'm not sure whether actually tangling
>> agent (client of the client?) is a good idea -- I'll check it
>> tomorrow, but AFAIR it's an additional reversed connection? And
>> situation with this big message probably is not so often to cause such
>> a confusion. I would really like to use such API in simplest possible
>> way, by calling some method and receiving answer and its exactly what
>> is accomplished with fd.
>
> I haven't seen the implementation but I have a feeling it won't be
> that simple, if you use the pipe/unix socket to stream the data them
> you end up copying data and the stream still need to be handled in
> client side which will very likely copy/convert the data again. We
> have tried such a thing before with A2DP and it was consider
> inefficient, so what we do nowadays is passing the bluetooth socket
> itself to PulseAudio but note that here it would not be a good idea
> since the client would have to deal with OBEX protocol directly.
>
> You could return the transfer object on GetMessage, actually is is
> probably a good idea to do this also for GetFile/PutFile, so that the
> caller application have direct control on the transfers it has started
> and we can probable have a property e.g. Status (Transferring, Error,
> Complete) to indicate the transfer status, that would remove the need
> to have an agent in the application although the system may still have
> one to track the progress and keep history of the transfers.
>
> --
> Luiz Augusto von Dentz
>
As far as i can tell adding transfer would be good idea and it's not
necessary to actually track it. But there is still question how to
transfer data? I'm still convinced that passing fd is good idea, maybe
even more flexible would be to pass it from user to obex-client in
DBus call, so user may decide whether it would be more convenience to
use file, pipe or whatever.
So method may look something like this:
string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))
Returning path to the newly created transfer.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <[email protected]> wrote:
>
> Generally you may be right, but i'm not sure whether actually tangling
> agent (client of the client?) is a good idea -- I'll check it
> tomorrow, but AFAIR it's ?an additional reversed connection? And
> situation with this big message probably is not so often to cause such
> a confusion. I would really like to use such API in simplest possible
> way, by calling some method and receiving answer and its exactly what
> is accomplished with fd.
I haven't seen the implementation but I have a feeling it won't be
that simple, if you use the pipe/unix socket to stream the data them
you end up copying data and the stream still need to be handled in
client side which will very likely copy/convert the data again. We
have tried such a thing before with A2DP and it was consider
inefficient, so what we do nowadays is passing the bluetooth socket
itself to PulseAudio but note that here it would not be a good idea
since the client would have to deal with OBEX protocol directly.
You could return the transfer object on GetMessage, actually is is
probably a good idea to do this also for GetFile/PutFile, so that the
caller application have direct control on the transfers it has started
and we can probable have a property e.g. Status (Transferring, Error,
Complete) to indicate the transfer status, that would remove the need
to have an agent in the application although the system may still have
one to track the progress and keep history of the transfers.
--
Luiz Augusto von Dentz
On Thu, Nov 3, 2011 at 6:59 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 7:38 PM, Bartosz Szatkowski <[email protected]> wrote:
>> On Thu, Nov 3, 2011 at 4:13 PM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Bartosz,
>>>
>>> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <[email protected]> wrote:
>>>>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>>>>
>>>>>> void SetFolder(boolean cdup, string name)
>>>>>>
>>>>>> Set working directory for current session.
>>>>>>
>>>>>> | cdup | folder name | operation |
>>>>>> |=====================================|
>>>>>> | FALSE | empty | cd / |
>>>>>> |--------+-------------+--------------|
>>>>>> | FALSE | name | cd name |
>>>>>> |--------+-------------+--------------|
>>>>>> | TRUE | [name] | cd ..[/name] |
>>>>>> +-------------------------------------+
>>>>>
>>>>> Why not simply
>>>>> void SetFolder(String cdString)
>>>>>
>>>>> and derive the obex command from that? It makes that API much easier to use.
>>>>>
>>>>> HS
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>>>>> in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>> Because it provoke more questions eg. what about failure in the middle
>>>> of the path? Also i've planned to keep it at rather low level.
>>>
>>> Well we can make it only accept only one step at time, which it seems
>>> is what g_obex_setpath does. Btw what is thing with GetMessage return,
>>> fd? Do we really need that? Can't we just convert to string so that
>>> user applications don't have to convert it themselves? Otherwise just
>>> use an array of bytes ('ay') or pass a path where the message should
>>> be stored like GetFile. If the concern is that the transfer may take
>>> too long the client the client should not wait the reply and instead
>>> track the transfer using an agent.
>>>
>>> --
>>> Luiz Augusto von Dentz
>>>
>>
>> And what if you'll start downloading email with 10MB attachment?? So
>> it's better to send file descriptor through DBus than lots (and lots)
>> of data. And there is nothing to convert, client will get fd and then
>> just read message from a file - it's simple enough.
>
> Then create a transfer object and notify the agent like we do for
> GetFile, also with this you progress indication like we have with
> normal files and you are also able to catch errors or cancel the
> transfer.
>
> --
> Luiz Augusto von Dentz
>
Generally you may be right, but i'm not sure whether actually tangling
agent (client of the client?) is a good idea -- I'll check it
tomorrow, but AFAIR it's an additional reversed connection? And
situation with this big message probably is not so often to cause such
a confusion. I would really like to use such API in simplest possible
way, by calling some method and receiving answer and its exactly what
is accomplished with fd.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Thu, Nov 3, 2011 at 7:38 PM, Bartosz Szatkowski <[email protected]> wrote:
> On Thu, Nov 3, 2011 at 4:13 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Bartosz,
>>
>> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <[email protected]> wrote:
>>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <[email protected]> wrote:
>>>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>>>
>>>>> ? ? ? ? ? ? ? void SetFolder(boolean cdup, string name)
>>>>>
>>>>> ? ? ? ? ? ? ? ? ? ? ? Set working directory for current session.
>>>>>
>>>>> ? ? ? ? ? ? ? ? ? ? ? | ?cdup ?| folder name | operation ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? |=====================================|
>>>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| empty ? ? ? | cd / ? ? ? ? |
>>>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| name ? ? ? ?| cd name ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>>>> ? ? ? ? ? ? ? ? ? ? ? | TRUE ? | [name] ? ? ?| cd ..[/name] |
>>>>> ? ? ? ? ? ? ? ? ? ? ? +-------------------------------------+
>>>>
>>>> Why not simply
>>>> ?void SetFolder(String cdString)
>>>>
>>>> and derive the obex command from that? It makes that API much easier to use.
>>>>
>>>> HS
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>>>> in
>>>> the body of a message to [email protected]
>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> Because it provoke more questions eg. what about failure in the middle
>>> of the path? Also i've planned to keep it at rather low level.
>>
>> Well we can make it only accept only one step at time, which it seems
>> is what g_obex_setpath does. Btw what is thing with GetMessage return,
>> fd? Do we really need that? Can't we just convert to string so that
>> user applications don't have to convert it themselves? Otherwise just
>> use an array of bytes ('ay') or pass a path where the message should
>> be stored like GetFile. If the concern is that the transfer may take
>> too long the client the client should not wait the reply and instead
>> track the transfer using an agent.
>>
>> --
>> Luiz Augusto von Dentz
>>
>
> And what if you'll start downloading email with 10MB attachment?? So
> it's better to send file descriptor through DBus than lots (and lots)
> of data. And there is nothing to convert, client will get fd and then
> just read message from a file - it's simple enough.
Then create a transfer object and notify the agent like we do for
GetFile, also with this you progress indication like we have with
normal files and you are also able to catch errors or cancel the
transfer.
--
Luiz Augusto von Dentz
On Thu, Nov 3, 2011 at 4:13 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <[email protected]> wrote:
>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <[email protected]> wrote:
>>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>>
>>>> void SetFolder(boolean cdup, string name)
>>>>
>>>> Set working directory for current session.
>>>>
>>>> | cdup | folder name | operation |
>>>> |=====================================|
>>>> | FALSE | empty | cd / |
>>>> |--------+-------------+--------------|
>>>> | FALSE | name | cd name |
>>>> |--------+-------------+--------------|
>>>> | TRUE | [name] | cd ..[/name] |
>>>> +-------------------------------------+
>>>
>>> Why not simply
>>> void SetFolder(String cdString)
>>>
>>> and derive the obex command from that? It makes that API much easier to use.
>>>
>>> HS
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Because it provoke more questions eg. what about failure in the middle
>> of the path? Also i've planned to keep it at rather low level.
>
> Well we can make it only accept only one step at time, which it seems
> is what g_obex_setpath does. Btw what is thing with GetMessage return,
> fd? Do we really need that? Can't we just convert to string so that
> user applications don't have to convert it themselves? Otherwise just
> use an array of bytes ('ay') or pass a path where the message should
> be stored like GetFile. If the concern is that the transfer may take
> too long the client the client should not wait the reply and instead
> track the transfer using an agent.
>
> --
> Luiz Augusto von Dentz
>
And what if you'll start downloading email with 10MB attachment?? So
it's better to send file descriptor through DBus than lots (and lots)
of data. And there is nothing to convert, client will get fd and then
just read message from a file - it's simple enough.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi!
This API is directly linked to the MAP Specification for setFolder see
P.49. Therefor it's already documented and easier to understand.
2011/11/3 Luiz Augusto von Dentz <[email protected]>:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <[email protected]> wrote:
>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <[email protected]> wrote:
>>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>>
>>>> ? ? ? ? ? ? ? void SetFolder(boolean cdup, string name)
>>>>
>>>> ? ? ? ? ? ? ? ? ? ? ? Set working directory for current session.
>>>>
>>>> ? ? ? ? ? ? ? ? ? ? ? | ?cdup ?| folder name | operation ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? |=====================================|
>>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| empty ? ? ? | cd / ? ? ? ? |
>>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| name ? ? ? ?| cd name ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>>> ? ? ? ? ? ? ? ? ? ? ? | TRUE ? | [name] ? ? ?| cd ..[/name] |
>>>> ? ? ? ? ? ? ? ? ? ? ? +-------------------------------------+
>>>
>>> Why not simply
>>> ?void SetFolder(String cdString)
>>>
>>> and derive the obex command from that? It makes that API much easier to use.
>>>
>>> HS
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Because it provoke more questions eg. what about failure in the middle
>> of the path? Also i've planned to keep it at rather low level.
>
> Well we can make it only accept only one step at time, which it seems
> is what g_obex_setpath does. Btw what is thing with GetMessage return,
> fd? Do we really need that? Can't we just convert to string so that
> user applications don't have to convert it themselves? Otherwise just
> use an array of bytes ('ay') or pass a path where the message should
> be stored like GetFile. If the concern is that the transfer may take
> too long the client the client should not wait the reply and instead
> track the transfer using an agent.
>
> --
> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hi Bartosz,
On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <[email protected]> wrote:
> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <[email protected]> wrote:
>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>
>>> ? ? ? ? ? ? ? void SetFolder(boolean cdup, string name)
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? Set working directory for current session.
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? | ?cdup ?| folder name | operation ? ?|
>>> ? ? ? ? ? ? ? ? ? ? ? |=====================================|
>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| empty ? ? ? | cd / ? ? ? ? |
>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>> ? ? ? ? ? ? ? ? ? ? ? | FALSE ?| name ? ? ? ?| cd name ? ? ?|
>>> ? ? ? ? ? ? ? ? ? ? ? |--------+-------------+--------------|
>>> ? ? ? ? ? ? ? ? ? ? ? | TRUE ? | [name] ? ? ?| cd ..[/name] |
>>> ? ? ? ? ? ? ? ? ? ? ? +-------------------------------------+
>>
>> Why not simply
>> ?void SetFolder(String cdString)
>>
>> and derive the obex command from that? It makes that API much easier to use.
>>
>> HS
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
> Because it provoke more questions eg. what about failure in the middle
> of the path? Also i've planned to keep it at rather low level.
Well we can make it only accept only one step at time, which it seems
is what g_obex_setpath does. Btw what is thing with GetMessage return,
fd? Do we really need that? Can't we just convert to string so that
user applications don't have to convert it themselves? Otherwise just
use an array of bytes ('ay') or pass a path where the message should
be stored like GetFile. If the concern is that the transfer may take
too long the client the client should not wait the reply and instead
track the transfer using an agent.
--
Luiz Augusto von Dentz
T24gVGh1LCBOb3YgMywgMjAxMSBhdCAzOjA4IFBNLCBIZW5kcmlrIFNhdHRsZXIgPHBvc3RAaGVu
ZHJpay1zYXR0bGVyLmRlPiB3cm90ZToKPiBBbSAwMy4xMS4yMDExIDE0OjQ0LCBzY2hyaWViIEJh
cnRvc3ogU3phdGtvd3NraToKPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgdm9pZCBTZXRGb2xk
ZXIoYm9vbGVhbiBjZHVwLCBzdHJpbmcgbmFtZSkKPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgU2V0IHdvcmtpbmcgZGlyZWN0b3J5IGZvciBjdXJyZW50IHNlc3Npb24uCj4+
Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqBjZHVwIMKgfCBmb2xkZXIg
bmFtZSB8IG9wZXJhdGlvbiDCoCDCoHwKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgfD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT18Cj4+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgRkFMU0UgwqB8IGVtcHR5IMKgIMKgIMKgIHwgY2QgLyDC
oCDCoCDCoCDCoCB8Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwtLS0tLS0t
LSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tfAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCB8IEZBTFNFIMKgfCBuYW1lIMKgIMKgIMKgIMKgfCBjZCBuYW1lIMKgIMKgIMKg
fAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8LS0tLS0tLS0rLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLXwKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
fCBUUlVFIMKgIHwgW25hbWVdIMKgIMKgIMKgfCBjZCAuLlsvbmFtZV0gfAo+PiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSsKPgo+IFdoeSBub3Qgc2ltcGx5Cj4gwqB2b2lkIFNldEZvbGRlcihTdHJpbmcgY2RTdHJp
bmcpCj4KPiBhbmQgZGVyaXZlIHRoZSBvYmV4IGNvbW1hbmQgZnJvbSB0aGF0PyBJdCBtYWtlcyB0
aGF0IEFQSSBtdWNoIGVhc2llciB0byB1c2UuCj4KPiBIUwo+Cj4gLS0KPiBUbyB1bnN1YnNjcmli
ZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtYmx1ZXRv
b3RoIgo+IGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5l
bC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9t
YWpvcmRvbW8taW5mby5odG1sCj4KCkJlY2F1c2UgaXQgcHJvdm9rZSBtb3JlIHF1ZXN0aW9ucyBl
Zy4gd2hhdCBhYm91dCBmYWlsdXJlIGluIHRoZSBtaWRkbGUKb2YgdGhlIHBhdGg/IEFsc28gaSd2
ZSBwbGFubmVkIHRvIGtlZXAgaXQgYXQgcmF0aGVyIGxvdyBsZXZlbC4KCi0tIApQb3pkcm93aWVu
aWEgLSBDaGVlcnMsCkJhcnRvc3ogU3phdGtvd3NraQo=
Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
> void SetFolder(boolean cdup, string name)
>
> Set working directory for current session.
>
> | cdup | folder name | operation |
> |=====================================|
> | FALSE | empty | cd / |
> |--------+-------------+--------------|
> | FALSE | name | cd name |
> |--------+-------------+--------------|
> | TRUE | [name] | cd ..[/name] |
> +-------------------------------------+
Why not simply
void SetFolder(String cdString)
and derive the obex command from that? It makes that API much easier to
use.
HS
Hi,
below proposed API for MAP client in obex-client, for now just some
generic functions and browsing support.
Messages Access hierarchy
=========================
Service org.openobex.client
Interface org.openobex.MessagesAccess
Object path [variable prefix]/{session0,session1,...}
Methods dict(uint8 tag, variant value) GetAppParams()
Retrieve application parameters connected to the last MSE
response. Application parameters corresponding to given call
are accessible until next request is sent.
Parameters are converted to unsigned integers of corresponding sizes
(MAP specification section 6.3.1) or NULL-terminated strings.
In case of parameters not mentioned in MAP specification value
becomes struct of (uint8 length, array{uint8}).
See MAP specification (section corresponding to given function)
for more details on returned parameters.
void SetFolder(boolean cdup, string name)
Set working directory for current session.
| cdup | folder name | operation |
|=====================================|
| FALSE | empty | cd / |
|--------+-------------+--------------|
| FALSE | name | cd name |
|--------+-------------+--------------|
| TRUE | [name] | cd ..[/name] |
+-------------------------------------+
array{dict(string property, string value)}
GetFolderListing(dict(uint8 tag, uint16 value))
Retrieve list of names (and all other properties returned by MSE)
for directories in CWD.
Parameters as in MAP specification section 5.4.
array{dict(string property, string value)}
GetMessageListing(string folder, array{uint8 tag, variant value})
Return message listing for given subfolder of CWD or directly
CWD if folder field is empty, format of each dict entry
corresponds to the message listing format (MAP specification
section 3.1.6).
Parameters as in MAP specification section 5.5.
unix_fd msgfd
GetMessage(string handle, dict(uint8 tag, variant value))
Retrieve message from remote device and return file descriptor,
from which message data (in BMSG format) may be read.
Parameters as in MAP specification section 5.6.
void SetMessageStatus(string handle, uint8 indicator, uint8 value)
Modify status of a message on remote device.
Parameters as in MAP specification section 5.7.
void UpdateInbox()
Initiate update of inbox status on remote device.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
> Hi,
> below proposed API for MAP client in obex-client, for now just some
> generic functions and browsing support.
>
> Messages Access hierarchy
> =========================
>
> Service org.openobex.client
> Interface org.openobex.MessagesAccess
Are there any plan on switching to a different namespace?
Using openobex was always in conflict with previously existing software
(o-d-s) and with the switch to gobex for the client, it's even less
correct.
HS