This adjusts obexd.service.in to changes introduced in commit
e7792642accead1de0016bd7f78c74d9b6cad38a, retaining original behaviour.
---
src/obexd.service.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/obexd.service.in b/src/obexd.service.in
index 24571bd..5c6ba0f 100644
--- a/src/obexd.service.in
+++ b/src/obexd.service.in
@@ -1,3 +1,3 @@
[D-BUS Service]
Name=org.openobex
-Exec=@libexecdir@/obexd --nodaemon --opp --ftp
+Exec=@libexecdir@/obexd --nodaemon --plugin=bluetooth:usb:opp:ftp
--
1.7.4.1
Hi,
On Wed, Jun 1, 2011 at 5:41 PM, Slawomir Bochenski <[email protected]> wrote:
>> I don't think the content of the default .service file has been thought
>> out so deeply, so I wouldn't put too much effort into retaining the
>> *exact* same behavior as before. Distros will typically customize it
>> anyway for their needs. What does make sense though is to have some kind
>> of sensible defaults there. Aren't all plugins a sensible default? Do we
>> have something inherently unstable/experimental that could mess up
>> systems? If so then that should probably be disabled by default already
>> at configure time, and if you really want to have something in the
>> service file it's probably easier to use -P instead of -p since the
>> "bad" plugins are in the minority.
>
> Well, in fact when this file was committed originally, there was
> nothing more to choose vyt OPP and FTP. Those two however looked like
> sensible defaults for a desktop setup. I suppose that for example PBAP
> and MAP don't seem to be the most wanted plugins in this case. Don't
> know about IrMC or SyncML.
But it doesn' t mean that this file will be installed as it is, so
just remove the invalid options and load all plugins as Johan
suggested should be fine. As for unstable plugins we can have it done
similarly to pcsuite which needs to be enabled during build time.
--
Luiz Augusto von Dentz
Computer Engineer
> I don't think the content of the default .service file has been thought
> out so deeply, so I wouldn't put too much effort into retaining the
> *exact* same behavior as before. Distros will typically customize it
> anyway for their needs. What does make sense though is to have some kind
> of sensible defaults there. Aren't all plugins a sensible default? Do we
> have something inherently unstable/experimental that could mess up
> systems? If so then that should probably be disabled by default already
> at configure time, and if you really want to have something in the
> service file it's probably easier to use -P instead of -p since the
> "bad" plugins are in the minority.
Well, in fact when this file was committed originally, there was
nothing more to choose vyt OPP and FTP. Those two however looked like
sensible defaults for a desktop setup. I suppose that for example PBAP
and MAP don't seem to be the most wanted plugins in this case. Don't
know about IrMC or SyncML.
--
Slawomir Bochenski
Hi Slawek,
On Wed, Jun 01, 2011, Slawomir Bochenski wrote:
> > Aren't most/all plugins compiled as built-in and all built-in plugins
> > loaded by default? Then you shouldn't need to provide any -p option to
> > get everything loaded. If this is the case could you update your patch
> > to simply remove the --ftp and --opp options without adding the --plugin
> > option.
> >
> > Johan
> >
>
> This was specifically made for retaining original behaviour. Simply
> removing --ftp and --opp would make obexd load all available plugins,
> which isn't how this worked until now.
I don't think the content of the default .service file has been thought
out so deeply, so I wouldn't put too much effort into retaining the
*exact* same behavior as before. Distros will typically customize it
anyway for their needs. What does make sense though is to have some kind
of sensible defaults there. Aren't all plugins a sensible default? Do we
have something inherently unstable/experimental that could mess up
systems? If so then that should probably be disabled by default already
at configure time, and if you really want to have something in the
service file it's probably easier to use -P instead of -p since the
"bad" plugins are in the minority.
Johan
On Wed, Jun 1, 2011 at 3:42 PM, Slawomir Bochenski <[email protected]> wrote:
> This was specifically made for retaining original behaviour. Simply
> removing --ftp and --opp would make obexd load all available plugins,
> which isn't how this worked until now.
Or, to be specific - it worked that way. That is all plugins loaded,
but not every server initialized and started. Only those explicitly
given on command line.
--
Slawomir Bochenski
> Aren't most/all plugins compiled as built-in and all built-in plugins
> loaded by default? Then you shouldn't need to provide any -p option to
> get everything loaded. If this is the case could you update your patch
> to simply remove the --ftp and --opp options without adding the --plugin
> option.
>
> Johan
>
This was specifically made for retaining original behaviour. Simply
removing --ftp and --opp would make obexd load all available plugins,
which isn't how this worked until now.
--
Slawomir Bochenski
Hi Slawek,
On Wed, Jun 01, 2011, Slawomir Bochenski wrote:
> I'm not sure however if ignoring transport plugins when --plugin is
> used is a good idea at all. There is no hint in --help text what user
> would have to load to make obexd work. Also no list of available
> plugins, thus this all is a bit confusing now.
Aren't most/all plugins compiled as built-in and all built-in plugins
loaded by default? Then you shouldn't need to provide any -p option to
get everything loaded. If this is the case could you update your patch
to simply remove the --ftp and --opp options without adding the --plugin
option.
Johan
I'm not sure however if ignoring transport plugins when --plugin is
used is a good idea at all. There is no hint in --help text what user
would have to load to make obexd work. Also no list of available
plugins, thus this all is a bit confusing now.
BR,
Slawomir Bochenski