Mantis - obex-data-server
Расширенный вид
95 General нововведение неприменима 2008-05-23 22:29 2009-10-21 21:14
закрыт 0.3.1  
решению не подлежит  
0000095: Use ODS as a standalone server
In some enviroments it could be useful that ODS act as a standalone server, that is, without another client process that uses its DBus interface to initialize a server.
There are two main alterations that have to be made so this can work:
  1. Remove some dependencies from DBusGMethodInvocation, so some methods can be called from inside ods itself.
  2. Add some support for configuration files, so there is no need to use DBus to create a new server or disable some interfaces (e.g.: use ODS as only an OPP server)
? file icon ods-new-storage.patch [^] (24,228 bytes) 2008-05-28 01:18
? file icon storage2.patch [^] (18,831 bytes) 2008-05-31 00:38
2008-05-23 22:29 vcgomes Новый вопрос
2008-05-25 19:50 heston_james Комментарий добавлен: 0000276
2008-05-26 17:45 vcgomes Комментарий добавлен: 0000277
2008-05-26 19:16 skirsdeda Комментарий добавлен: 0000278
2008-05-27 10:53 heston_james Комментарий добавлен: 0000280
2008-05-28 01:18 vcgomes Файл добавлен: ods-new-storage.patch
2008-05-28 01:19 vcgomes Комментарий добавлен: 0000287
2008-05-28 17:48 vcgomes Отслеживать: vcgomes
2008-05-30 17:57 skirsdeda Комментарий добавлен: 0000300
2008-05-31 00:38 vcgomes Комментарий добавлен: 0000304
2008-05-31 00:38 vcgomes Файл добавлен: storage2.patch
2009-10-21 21:14 skirsdeda Состояние новый => закрыт
2009-10-21 21:14 skirsdeda Решение открыт => решению не подлежит

2008-05-25 19:50   
Do you not think it would just be better to include a server script in with the package rather than modifying the ODS itself?

By making the server a seperate script we won't complicate the ods code, retain a focus on what ods 'should' be, a high level API. Also the server app would act as a well formed example of how to implement the API into an application.

At the moment ODS comes with a server test script in the /test directory, what benefits do you see to building this code into ods itself? I think it would probably just over complicate the ODS code, limit flexibility for the end developers and blur the definition of what ods is.

2008-05-26 17:45   
The rationale behind my suggestion is that in some cases we want to hide some functionalities from the user (e.g. disabling ftp, the server is started at a fixed directory, etc.).

I was thinking about adding a configuration file, so the packager would be able to disable the start of some servers (FTP, OPP, etc) at run-time and if specified start some servers by default.

Do you have any idea on how to implement this in a cleaner way?

2008-05-26 19:16   
Sounds good to me. We can implement a special GObject which would auto-start OPP/FTP servers and would be optional (when building ods). It might use a configuration file or whatever fits the purpose best.
2008-05-27 10:53   
Yeah, if we go down this route then a config file probably makes good sense to allow people to enable and disable the servers which are started and thier respective system paths, this way non-programming folk will still be able to take advantage of it.
2008-05-28 01:19   

I implemented a version of what we were discussing, feel free to test and comment ;-) as far as I tested it's working. Patch is attached.

2008-05-30 17:57   
Several points:
1) ods-standalone.{c/h} should be ods-config.{c/h} and ManagerSettings/ServerSettings should reside there. ManagerSettings should probably be renamed. This is so that we can use config file for other purposes.
2) instead of g_error_free(err);err = NULL; use g_clear_error(&err);

BTW, I updated mode lines in svn..
2008-05-31 00:38   

1) Ok
2) Nice hint, I am not very familiar with GLib/GObject.

new patch in storage2.patch