All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Slawomir Bochenski <lkslawek@gmail.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 3/4] Modify obex_write_stream logic
Date: Thu, 16 Jun 2011 13:51:42 -0300	[thread overview]
Message-ID: <20110616165140.GA5229@piper> (raw)
In-Reply-To: <BANLkTikOJC7QSWkJ2HbJTQg-e2n36mc-zw@mail.gmail.com>

Hi Luiz,

On 11:27 Thu 16 Jun, Luiz Augusto von Dentz wrote:
> Hi,
> 
> On Wed, Jun 15, 2011 at 5:59 PM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
> >
> > The loop is only used before we start streaming. That is because if
> > there was no streaming started, request will be finished after
> > returning from OpenOBEX callback. To still allow plugins to use the
> > original approach, the loop guarantees that there will be another
> > read() if the service plugin did not explicitly returned -EAGAIN, so
> > read() still decides explicitly when it wants the suspending to
> > happen, therefore it is perfectly aware of when to call
> > obex_object_set_io_flags().
> >
> > This is just how OpenOBEX works - unless we are streaming body
> > headers, we should add headers when getting event and suspend if we
> > want to postpone finishing the request. I would not call this loop
> > "dangerous".
> 
> I would say this is not a limitation of OpenOBEX, just the way we
> implement async io in obexd.
> 
> > Well, we have also another possible header types and generally in some
> > near future a profile may need to use more than just application
> > parameters header and/or body headers (e.g. user defined headers).
> > This might also allow sending Length header asynchronously (which by
> > quick looking at code is not possible now).
> >
> > With approach I presented the cost of changes is very low and
> > additionally makes it extremely easy to return all possible headers.
> > Also everything just works, together with support for asynchronous
> > I/O.
> >
> > Adding additional callback will unnecessarily complicate the code.
> 
> Sorry I have to disagree here, adding another callback probably
> simplify the code a bit since we can have something like this:
> 
> if (!streaming && driver->get_apparams)
>     driver->get_apparams...
> 
> So just drivers that support get_apparams will be called and that
> should be enough to guarantee the apparams are added in the beginning
> packet.
> 
> Custom headers are a different matter, right now we don't have any
> plugin/driver who need them.

But we will have soon, BIP needs them. So we better start considering
how should we export it to the plugins.

> 
> -- 
> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers,
-- 
Vinicius

  parent reply	other threads:[~2011-06-16 16:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 13:09 Various GET functionality fixes (obsoletes: Renewed new missed calls handling) Slawomir Bochenski
2011-06-07 13:09 ` [PATCH 1/4] Revert API changes to mime driver read function Slawomir Bochenski
2011-06-07 13:09 ` [PATCH 2/4] Remove redundant code Slawomir Bochenski
2011-06-07 13:10 ` [PATCH 3/4] Modify obex_write_stream logic Slawomir Bochenski
2011-06-07 13:10 ` [PATCH 4/4] Fix handling asynchronous plugin reads Slawomir Bochenski
2011-06-08  4:27   ` Luiz Augusto von Dentz
2011-06-13  9:34     ` Various GET functionality fixes (obsoletes: Renewed new missed calls handling) Slawomir Bochenski
2011-06-13  9:34       ` [PATCH 3/4] Modify obex_write_stream logic Slawomir Bochenski
2011-06-15 13:30         ` Luiz Augusto von Dentz
2011-06-15 13:39           ` Johan Hedberg
2011-06-15 14:59             ` Slawomir Bochenski
2011-06-16  8:27               ` Luiz Augusto von Dentz
2011-06-16  8:58                 ` Slawomir Bochenski
2011-06-16  9:19                   ` Slawomir Bochenski
2011-06-16 16:51                 ` Vinicius Costa Gomes [this message]
2011-06-17  7:35                   ` Luiz Augusto von Dentz
2011-06-17  7:59                     ` Slawomir Bochenski
2011-06-13  9:34       ` [PATCH 4/4] Fix handling asynchronous plugin reads Slawomir Bochenski
2011-06-13 11:24         ` [PATCH v3 " Slawomir Bochenski
2011-06-14  6:33           ` Luiz Augusto von Dentz
2011-06-14  6:58             ` Slawomir Bochenski
2011-06-15 13:06               ` Johan Hedberg
2011-06-15 15:08                 ` Slawomir Bochenski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110616165140.GA5229@piper \
    --to=vinicius.gomes@openbossa.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=lkslawek@gmail.com \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.