Hi Luiz,
On 03/04/2013 10:05 PM, Luiz Augusto von Dentz wrote:
Hi Christian,
On Mon, Mar 4, 2013 at 6:52 PM, Christian Fetzer
<christian.fetzer@xxxxxxxxxxxxxxxx> wrote:
Hi Luiz,
On 03/01/2013 02:13 PM, Luiz Augusto von Dentz wrote:
So from the discussion the IRC yesterday I think we can have this
transparently handled by the transfer, we can perhaps add Suspend/Resume and
suspended state API to Transfer interface which probably in this case should
auto suspend if FractionDelivery is set so the application has to resume to
get the parts but they all belong to the same transfer and are saved in the
same file. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send
the line "unsubscribe linux-bluetooth" in the body of a message to
majordomo@xxxxxxxxxxxxxxx More majordomo info at
http://vger.kernel.org/majordomo-info.html
The first fraction is already a valid bMessage object, further fractions
contain enclosed bBody objects.
Since the application has to deal with the bMessage format already, there is
no need to hide the fractions in the transfer objects.
If they are all bmsg then you are right, they should be in their own transfer.
The proposed way of simply adding a FractionDeliver parameter to the message
meta data, allows the application to easily
deal with the fractions without adding too much complexity to itself or
BlueZ.
Im still not sure why the spec haven't done this in some other way,
but Im fine wit the parameter provide we can actually tell when it is
supported.
I've sent an update tying to make sure that the documentation explains
the "FractionDeliver"
parameter well enough, telling also when it is present.
I also changed the interface version as requested.
Let me know if you're fine with it then.
Thanks and Br,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
