Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH 1/2] Add messages backend initialization and finalization
@ 2011-05-23 14:01 Slawomir Bochenski
  2011-05-23 14:01 ` [PATCH 2/2] Add MAP session management and SetFolder function Slawomir Bochenski
  2011-05-25 20:40 ` [PATCH 1/2] Add messages backend initialization and finalization Johan Hedberg
  0 siblings, 2 replies; 4+ messages in thread
From: Slawomir Bochenski @ 2011-05-23 14:01 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Slawomir Bochenski

This adds functions for initializing and freeing resources used by
message storage access backend and example implementation in the dummy
(or rather - filesystem) backend.

Dummy backend uses $MAP_ROOT (if set) and falls back to
$HOME/map-messages for its message storage. This directory should at
least contain basic folders required by the MAP specification. It
represents the root as seen from the perspective of MAP client. You can
prepare it as follows:

$ mkdir -p "$MAP_ROOT/telecom/msg/inbox"
$ mkdir "$MAP_ROOT/telecom/msg/sent"
$ mkdir "$MAP_ROOT/telecom/msg/deleted"
$ mkdir "$MAP_ROOT/telecom/msg/outbox"
---
 plugins/mas.c            |    8 ++++++++
 plugins/messages-dummy.c |   22 ++++++++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/plugins/mas.c b/plugins/mas.c
index a84b8fd..243d2f6 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -261,6 +261,10 @@ static int mas_init(void)
 {
 	int err;
 
+	err = messages_init();
+	if (err < 0)
+		goto failed_messages_init;
+
 	err = obex_mime_type_driver_register(&mime_map);
 	if (err < 0)
 		goto failed_mime;
@@ -275,6 +279,9 @@ failed_mas_reg:
 	obex_mime_type_driver_unregister(&mime_map);
 
 failed_mime:
+	messages_exit();
+
+failed_messages_init:
 	return err;
 }
 
@@ -282,6 +289,7 @@ static void mas_exit(void)
 {
 	obex_service_driver_unregister(&mas);
 	obex_mime_type_driver_unregister(&mime_map);
+	messages_exit();
 }
 
 OBEX_PLUGIN_DEFINE(mas, mas_init, mas_exit)
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index a536d81..7b2e1a1 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -26,16 +26,38 @@
 #endif
 
 #include <errno.h>
+#include <stdlib.h>
 
 #include "messages.h"
 
+static char *root_folder = NULL;
+
 int messages_init(void)
 {
+	char *tmp;
+
+	if (root_folder)
+		return 0;
+
+	tmp = getenv("MAP_ROOT");
+	if (tmp) {
+		root_folder = g_strdup(tmp);
+		return 0;
+	}
+
+	tmp = getenv("HOME");
+	if (!tmp)
+		return -1;
+
+	root_folder = g_build_filename(tmp, "map-messages", NULL);
+
 	return 0;
 }
 
 void messages_exit(void)
 {
+	g_free(root_folder);
+	root_folder = NULL;
 }
 
 int messages_connect(void **session)
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread
* [PATCH 0/2] Message Access Profile, cont.
@ 2011-03-23 13:56 Slawomir Bochenski
  2011-03-23 13:56 ` [PATCH 1/2] Add messages backend initialization and finalization Slawomir Bochenski
  0 siblings, 1 reply; 4+ messages in thread
From: Slawomir Bochenski @ 2011-03-23 13:56 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Slawomir Bochenski

As Johan insisted, here is another approach.

Functions used for accessing message storage are going to be a bit more
independent from MAP architecture and so more reusable in other places.

There may be some initialization needed before storage is usable. This is
introduced in first patch. I was thinking about other ways to do it:

1) Add OBEX_PLUGIN_DEFINE to messages-*.c and so make it a plugin (this
is related to what Luiz suggested before).

This would however prevent MAP plugin from being able to refuse to load
if message storage is not functional. Also it breaks the idea of message
storage API being independent from obexd architecture.

2) Add reference counter of plugin users, so only last messages_exit
would free common resources (like it is the case with root_folder in
messages_dummy.c).

This would get harder is someone would wish to use threads at some point.

3) Get rid of static data and return pointer from messages_init() that
would be passed to all message storage functions calls.

This option still may need some reference counting and data shared
between API clients at some point (I'm thinking about implementation of
undelete behaviour, required by MAP, when actual storage does not have
that possibility).


What do you think?

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-05-25 20:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-23 14:01 [PATCH 1/2] Add messages backend initialization and finalization Slawomir Bochenski
2011-05-23 14:01 ` [PATCH 2/2] Add MAP session management and SetFolder function Slawomir Bochenski
2011-05-25 20:40 ` [PATCH 1/2] Add messages backend initialization and finalization Johan Hedberg
  -- strict thread matches above, loose matches on Subject: below --
2011-03-23 13:56 [PATCH 0/2] Message Access Profile, cont Slawomir Bochenski
2011-03-23 13:56 ` [PATCH 1/2] Add messages backend initialization and finalization Slawomir Bochenski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox