linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* obexd FTP server signals
@ 2010-04-18 16:28 Daniel Abraham
  2010-04-18 18:27 ` Vinicius Gomes
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Abraham @ 2010-04-18 16:28 UTC (permalink / raw)
  To: linux-bluetooth

Hi, I have a question:

Is there any way to get more transaction-related signals from obexd,
when it's used as an FTP _server_?

As far as I can see from "obexd-api.txt" and from dbus-monitor, the
only things to catch are "session_started" and "session_removed".

But I'd like to have a level of granularity similar to the FTP client:
signals about starting/progress/canceling/completing transfers, which
specific kinds of trasfers are done (list folder, get file, put file,
etc.).

Any ideas?

Thanks

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: obexd FTP server signals
  2010-04-18 16:28 obexd FTP server signals Daniel Abraham
@ 2010-04-18 18:27 ` Vinicius Gomes
  2010-04-19  5:26   ` Daniel Abraham
  0 siblings, 1 reply; 3+ messages in thread
From: Vinicius Gomes @ 2010-04-18 18:27 UTC (permalink / raw)
  To: Daniel Abraham; +Cc: linux-bluetooth

Hi Daniel,

On Sun, Apr 18, 2010 at 1:28 PM, Daniel Abraham
<daniel.shrugged@gmail.com> wrote:
> Hi, I have a question:
>
> Is there any way to get more transaction-related signals from obexd,
> when it's used as an FTP _server_?
>

No. At least, not yet.

> As far as I can see from "obexd-api.txt" and from dbus-monitor, the
> only things to catch are "session_started" and "session_removed".
>
> But I'd like to have a level of granularity similar to the FTP client:
> signals about starting/progress/canceling/completing transfers, which
> specific kinds of trasfers are done (list folder, get file, put file,
> etc.).
>
> Any ideas?

At first we considered some form of status reporting, but after
thinking and looking at other "file sharing" servers we noticed that
it was not really useful for the server to report that information,
for example, sshd and any ftp server, don't have any form of status
reporting.

In those cases only the client reports the status, because the client
is where the user has control. I don't think obexd is much different
from those servers.

But, do you have a concrete case for this?

>
> Thanks
> --
> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: obexd FTP server signals
  2010-04-18 18:27 ` Vinicius Gomes
@ 2010-04-19  5:26   ` Daniel Abraham
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel Abraham @ 2010-04-19  5:26 UTC (permalink / raw)
  To: Vinicius Gomes; +Cc: linux-bluetooth

On Sun, Apr 18, 2010 at 9:27 PM, Vinicius Gomes
<vinicius.gomes@openbossa.org> wrote:
> On Sun, Apr 18, 2010 at 1:28 PM, Daniel Abraham
> <daniel.shrugged@gmail.com> wrote:
>> But I'd like to have a level of granularity similar to the FTP client:
>> signals about starting/progress/canceling/completing transfers, which
>> specific kinds of trasfers are done (list folder, get file, put file,
>> etc.).
>
> At first we considered some form of status reporting, but after
> thinking and looking at other "file sharing" servers we noticed that
> it was not really useful for the server to report that information,
> for example, sshd and any ftp server, don't have any form of status
> reporting.
>
> In those cases only the client reports the status, because the client
> is where the user has control. I don't think obexd is much different
> from those servers.
>
> But, do you have a concrete case for this?

1. Using it as a benchmark platform

In that case, the server is the focus point for gathering data
(consistently), and the clients are just remote black boxes. If I
can't expect and respond to specific events, I'd have to write
equivalent apps for each OS, which is sometimes impossible, and then
hope that methodology & measurements are consistent.

2. Basis for server activity logging

3. Less specific, but the sky is the limit: enabling server-side
timeouts/triggers/dynamic content/etc. - based on the user actions,
flows, history...

Anyway, my personal interest is in automating, logging and timing file
transfers from/to unknown remote clients.

Thanks

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-04-19  5:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-18 16:28 obexd FTP server signals Daniel Abraham
2010-04-18 18:27 ` Vinicius Gomes
2010-04-19  5:26   ` Daniel Abraham

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).