[PATCH 0/4] Message Access Profile plugin

[PATCH 0/4] Message Access Profile plugin

[lkslawek]

These are the first ones of upcoming series of patches implementing Message
Access Profile (server role) in obexd. 

The work is more than less complete (~4k lines now), but as advised by Johan,
I'm cutting the whole thing into smaller pieces before sending this here.

Regards,
Slawomir Bochenski

 .gitignore               |    1 +
 Makefile.am              |   10 ++-
 configure.ac             |   12 ++
 plugins/mas.c            |  338 ++++++++++++++++++++++++++++++++++++++++++++++
 plugins/messages-dummy.c |   28 ++++
 plugins/messages.h       |   37 +++++
 src/main.c               |   11 ++-
 src/obex.h               |    1 +
 8 files changed, 435 insertions(+), 3 deletions(-)

[PATCH 1/4] Add skeleton for Message Access Profile plugin

[lkslawek]

From: Slawomir Bochenski <lkslawek@gmail.com>

This patch introduces skeleton of a plugin supporting server role side
of Bluetooth SIG profile defining procedures for exchanging message
objects.

The plugin can be compiled with different backends used for accessing
message repository. This can be selected during configure:

	./configure --with-messages=backend_name

When no backend is specified, the default dummy is chosen.

There is also a new command line option to obexd needed to start Message
Access service:

	obexd [...] --mas
---
 .gitignore               |    1 +
 Makefile.am              |   10 +++++++++-
 configure.ac             |   12 ++++++++++++
 plugins/mas.c            |   42 ++++++++++++++++++++++++++++++++++++++++++
 plugins/messages-dummy.c |   28 ++++++++++++++++++++++++++++
 plugins/messages.h       |   22 ++++++++++++++++++++++
 src/main.c               |   11 +++++++++--
 src/obex.h               |    1 +
 8 files changed, 124 insertions(+), 3 deletions(-)
 create mode 100644 plugins/mas.c
 create mode 100644 plugins/messages-dummy.c
 create mode 100644 plugins/messages.h

diff --git a/.gitignore b/.gitignore
index 663240a..e3f5c3f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,6 +29,7 @@ src/obexd
 src/obexd.service
 plugins/phonebook.c
 plugins/telephony.c
+plugins/messages.c
 client/obex-client
 client/obex-client.service
 test/obex-test
diff --git a/Makefile.am b/Makefile.am
index d32d613..8d8fdc6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,6 +58,9 @@ builtin_modules += pbap
 builtin_sources += plugins/pbap.c plugins/phonebook.h \
 			plugins/vcard.h plugins/vcard.c
 
+builtin_modules += mas
+builtin_sources += plugins/mas.c plugins/messages.h
+
 builtin_modules += irmc
 builtin_sources += plugins/irmc.c
 
@@ -65,6 +68,7 @@ builtin_modules += syncevolution
 builtin_sources += plugins/syncevolution.c
 
 builtin_nodist += plugins/phonebook.c
+builtin_nodist += plugins/messages.c
 
 libexec_PROGRAMS += src/obexd
 
@@ -137,7 +141,8 @@ CLEANFILES = $(service_DATA) $(builtin_files)
 EXTRA_DIST = src/genbuiltin $(doc_files) $(test_files) src/obex.conf \
 			src/obexd.service.in client/obex-client.service.in \
 			plugins/phonebook-dummy.c plugins/phonebook-ebook.c \
-			plugins/phonebook-tracker.c
+			plugins/phonebook-tracker.c \
+			plugins/messages-dummy.c
 
 DISTCHECK_CONFIGURE_FLAGS = --enable-client --enable-server
 
@@ -150,3 +155,6 @@ MAINTAINERCLEANFILES = Makefile.in \
 
 plugins/phonebook.c: plugins/@PHONEBOOK_DRIVER@
 	$(AM_V_GEN)$(LN_S) @abs_top_srcdir@/$< $@
+
+plugins/messages.c: plugins/@MESSAGES_DRIVER@
+	$(AM_V_GEN)$(LN_S) @abs_top_srcdir@/$< $@
diff --git a/configure.ac b/configure.ac
index 9194843..fb349ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,6 +106,18 @@ AC_ARG_ENABLE(debug, AC_HELP_STRING([--enable-debug],
 		CFLAGS="$CFLAGS -g"
 	fi
 ])
+
+messages_driver=dummy
+AC_ARG_WITH(messages, AC_HELP_STRING([--with-messages=DRIVER], [select messages driver]), [
+	if (test "${withval}" = "no"); then
+		messages_driver=dummy;
+	else
+		messages_driver=${withval};
+	fi
+])
+
+AC_SUBST([MESSAGES_DRIVER], [messages-${messages_driver}.c])
+
 phonebook_driver=dummy
 AC_ARG_WITH(phonebook, AC_HELP_STRING([--with-phonebook=DRIVER], [select phonebook driver]), [
 	if (test "${withval}" = "no"); then
diff --git a/plugins/mas.c b/plugins/mas.c
new file mode 100644
index 0000000..cb6dda0
--- /dev/null
+++ b/plugins/mas.c
@@ -0,0 +1,42 @@
+/*
+ *
+ *  OBEX Server
+ *
+ *  Copyright (C) 2010-2011  Slawomir Bochenski <lkslawek@gmail.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include "plugin.h"
+#include "log.h"
+
+#include "messages.h"
+
+static int mas_init(void)
+{
+	return 0;
+}
+
+static void mas_exit(void)
+{
+}
+
+OBEX_PLUGIN_DEFINE(mas, mas_init, mas_exit)
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
new file mode 100644
index 0000000..1722306
--- /dev/null
+++ b/plugins/messages-dummy.c
@@ -0,0 +1,28 @@
+/*
+ *
+ *  OBEX Server
+ *
+ *  Copyright (C) 2010-2011  Slawomir Bochenski <lkslawek@gmail.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include "messages.h"
diff --git a/plugins/messages.h b/plugins/messages.h
new file mode 100644
index 0000000..2a41ea7
--- /dev/null
+++ b/plugins/messages.h
@@ -0,0 +1,22 @@
+/*
+ *
+ *  OBEX Server
+ *
+ *  Copyright (C) 2010-2011  Slawomir Bochenski <lkslawek@gmail.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
diff --git a/src/main.c b/src/main.c
index 1e78615..8154e3b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -84,6 +84,7 @@ static gboolean option_irmc = FALSE;
 static gboolean option_pcsuite = FALSE;
 static gboolean option_symlinks = FALSE;
 static gboolean option_syncevolution = FALSE;
+static gboolean option_mas = FALSE;
 
 static gboolean parse_debug(const char *key, const char *value,
 				gpointer user_data, GError **error)
@@ -125,6 +126,8 @@ static GOptionEntry options[] = {
 				"Enable PC Suite Services server" },
 	{ "syncevolution", 'e', 0, G_OPTION_ARG_NONE, &option_syncevolution,
 				"Enable OBEX server for SyncEvolution" },
+        { "mas", 'm', 0, G_OPTION_ARG_NONE, &option_mas,
+				"Enable Message Access server" },
 	{ NULL },
 };
 
@@ -212,9 +215,10 @@ int main(int argc, char *argv[])
 	if (option_opp == FALSE && option_ftp == FALSE &&
 				option_pbap == FALSE &&
 				option_irmc == FALSE &&
-				option_syncevolution == FALSE) {
+				option_syncevolution == FALSE &&
+				option_mas == FALSE) {
 		fprintf(stderr, "No server selected (use either "
-				"--opp, --ftp, --pbap, --irmc or --syncevolution)\n");
+				"--opp, --ftp, --pbap, --irmc, --mas, or --syncevolution)\n");
 		exit(EXIT_FAILURE);
 	}
 
@@ -278,6 +282,9 @@ int main(int argc, char *argv[])
 		obex_server_init(OBEX_SYNCEVOLUTION, NULL, TRUE, FALSE,
 							FALSE, NULL);
 
+	if (option_mas == TRUE)
+		obex_server_init(OBEX_MAS, NULL, TRUE, FALSE, FALSE, NULL);
+
 	if (!root_folder_setup(option_root, option_root_setup)) {
 		error("Unable to setup root folder %s", option_root);
 		exit(EXIT_FAILURE);
diff --git a/src/obex.h b/src/obex.h
index c3f6e3d..94274c2 100644
--- a/src/obex.h
+++ b/src/obex.h
@@ -36,6 +36,7 @@
 #define OBEX_IRMC	(1 << 5)
 #define OBEX_PCSUITE	(1 << 6)
 #define OBEX_SYNCEVOLUTION	(1 << 7)
+#define OBEX_MAS	(1 << 8)
 
 #define TARGET_SIZE 16
 
-- 
1.7.1

[PATCH 2/4] Add actual service for Message Access Profile

[lkslawek]

From: Slawomir Bochenski <lkslawek@gmail.com>

This adds basic service functionality in MAP code, accompanied by proper
record for SDP.

RFCOMM channel of choice is 16 which is in accordance with
doc/assigned-numbers.txt.
---
 plugins/mas.c |  186 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 186 insertions(+), 0 deletions(-)

diff --git a/plugins/mas.c b/plugins/mas.c
index cb6dda0..2d061a1 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -25,18 +25,204 @@
 #include <config.h>
 #endif
 
+#include <errno.h>
+#include <glib.h>
+#include <openobex/obex.h>
+
 #include "plugin.h"
 #include "log.h"
+#include "obex.h"
+#include "service.h"
+#include "dbus.h"
 
 #include "messages.h"
 
+/* Channel number according to bluez doc/assigned-numbers.txt */
+#define MAS_CHANNEL	16
+
+#define MAS_RECORD "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>		\
+<record>								\
+  <attribute id=\"0x0001\">						\
+    <sequence>								\
+      <uuid value=\"0x1132\"/>						\
+    </sequence>								\
+  </attribute>								\
+									\
+  <attribute id=\"0x0004\">						\
+    <sequence>								\
+      <sequence>							\
+        <uuid value=\"0x0100\"/>					\
+      </sequence>							\
+      <sequence>							\
+        <uuid value=\"0x0003\"/>					\
+        <uint8 value=\"%u\" name=\"channel\"/>				\
+      </sequence>							\
+      <sequence>							\
+        <uuid value=\"0x0008\"/>					\
+      </sequence>							\
+    </sequence>								\
+  </attribute>								\
+									\
+  <attribute id=\"0x0009\">						\
+    <sequence>								\
+      <sequence>							\
+        <uuid value=\"0x1134\"/>					\
+        <uint16 value=\"0x0100\" name=\"version\"/>			\
+      </sequence>							\
+    </sequence>								\
+  </attribute>								\
+									\
+  <attribute id=\"0x0100\">						\
+    <text value=\"%s\" name=\"name\"/>					\
+  </attribute>								\
+									\
+  <attribute id=\"0x0315\">						\
+    <uint8 value=\"0x00\"/>						\
+  </attribute>								\
+									\
+  <attribute id=\"0x0316\">						\
+    <uint8 value=\"0x0F\"/>						\
+  </attribute>								\
+</record>"
+
+struct mas_session {
+	struct mas_request *request;
+};
+
+static const uint8_t MAS_TARGET[TARGET_SIZE] = {
+			0xbb, 0x58, 0x2b, 0x40, 0x42, 0x0c, 0x11, 0xdb,
+			0xb0, 0xde, 0x08, 0x00, 0x20, 0x0c, 0x9a, 0x66  };
+
+static void mas_clean(struct mas_session *mas)
+{
+	g_free(mas);
+}
+
+static void *mas_connect(struct obex_session *os, int *err)
+{
+	struct mas_session *mas;
+
+	DBG("");
+
+	*err = 0;
+
+	mas = g_new0(struct mas_session, 1);
+
+	manager_register_session(os);
+
+	return mas;
+}
+
+static void mas_disconnect(struct obex_session *os, void *user_data)
+{
+	struct mas_session *mas = user_data;
+
+	DBG("");
+
+	manager_unregister_session(os);
+
+	mas_clean(mas);
+}
+
+static int mas_get(struct obex_session *os, obex_object_t *obj,
+					gboolean *stream, void *user_data)
+{
+	struct mas_session *mas = user_data;
+	const char *type = obex_get_type(os);
+	const char *name = obex_get_name(os);
+	int ret;
+
+	DBG("GET: name %s type %s mas %p",
+			name, type, mas);
+
+	if (type == NULL)
+		return -EBADR;
+
+	*stream = FALSE;
+
+	ret = obex_get_stream_start(os, name);
+	if (ret < 0)
+		goto fail;
+
+	return 0;
+fail:
+	return ret;
+}
+
+static int mas_put(struct obex_session *os, obex_object_t *obj, void *user_data)
+{
+	struct mas_session *mas = user_data;
+	const char *type = obex_get_type(os);
+	const char *name = obex_get_name(os);
+	int ret;
+
+	DBG("PUT: name %s type %s mas %p", name, type, mas);
+
+	if (type == NULL)
+		return -EBADR;
+
+	ret = obex_put_stream_start(os, name);
+	if (ret < 0)
+		goto fail;
+
+	return 0;
+fail:
+	return ret;
+}
+
+static int mas_setpath(struct obex_session *os, obex_object_t *obj,
+		void *user_data)
+{
+	const char *name;
+	uint8_t *nonhdr;
+
+	if (OBEX_ObjectGetNonHdrData(obj, &nonhdr) != 2) {
+		error("Set path failed: flag and constants not found!");
+		return -EBADR;
+	}
+
+	name = obex_get_name(os);
+
+	DBG("SETPATH: name %s nonhdr 0x%x%x", name, nonhdr[0], nonhdr[1]);
+
+	if ((nonhdr[0] & 0x02) != 0x02) {
+		DBG("Error: requested directory creation");
+		return -EBADR;
+	}
+
+	return 0;
+}
+static struct obex_service_driver mas = {
+	.name = "Message Access server",
+	.service = OBEX_MAS,
+	.channel = MAS_CHANNEL,
+	.record = MAS_RECORD,
+	.target = MAS_TARGET,
+	.target_size = TARGET_SIZE,
+	.connect = mas_connect,
+	.get = mas_get,
+	.put = mas_put,
+	.setpath = mas_setpath,
+	.disconnect = mas_disconnect,
+};
+
 static int mas_init(void)
 {
+	int err;
+
+	err = obex_service_driver_register(&mas);
+	if (err < 0)
+		goto fail_mas_reg;
+
 	return 0;
+
+fail_mas_reg:
+	return err;
 }
 
 static void mas_exit(void)
 {
+	obex_service_driver_unregister(&mas);
 }
 
 OBEX_PLUGIN_DEFINE(mas, mas_init, mas_exit)
-- 
1.7.1

Re: [PATCH 2/4] Add actual service for Message Access Profile

[Johan Hedberg]

Hi Slawek,

On Wed, Mar 02, 2011, lkslawek@gmail.com wrote:
> +	ret = obex_get_stream_start(os, name);
> +	if (ret < 0)
> +		goto fail;
> +
> +	return 0;
> +fail:
> +	return ret;
> +}

How about just "return obex_get_stream_start(os, name);"?

> +	ret = obex_put_stream_start(os, name);
> +	if (ret < 0)
> +		goto fail;
> +
> +	return 0;
> +fail:
> +	return ret;
> +}

Same here.

> +	}
> +
> +	return 0;
> +}
> +static struct obex_service_driver mas = {

Missing empty line before "statis struct ...".

>  static int mas_init(void)
>  {
> +	int err;
> +
> +	err = obex_service_driver_register(&mas);
> +	if (err < 0)
> +		goto fail_mas_reg;
> +
>  	return 0;
> +
> +fail_mas_reg:
> +	return err;
>  }

Just "return obex_service_driver_register(&mas);" should be enough.

Johan

Re: [PATCH 2/4] Add actual service for Message Access Profile

[Slawomir Bochenski]

On Thu, Mar 10, 2011 at 12:14 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Slawek,
>
> On Wed, Mar 02, 2011, lkslawek@gmail.com wrote:
>> +     ret = obex_get_stream_start(os, name);
>> +     if (ret < 0)
>> +             goto fail;
>> +
>> +     return 0;
>> +fail:
>> +     return ret;
>> +}
>
> How about just "return obex_get_stream_start(os, name);"?
>
>> +     ret = obex_put_stream_start(os, name);
>> +     if (ret < 0)
>> +             goto fail;
>> +
>> +     return 0;
>> +fail:
>> +     return ret;
>> +}
>
> Same here.
>
This is ready for upcoming change, where there is also applications
parameter parsing that can fail and return it's own error code.
>> +     }
>> +
>> +     return 0;
>> +}
>> +static struct obex_service_driver mas = {
>
> Missing empty line before "statis struct ...".
>
I will fix it.
>>  static int mas_init(void)
>>  {
>> +     int err;
>> +
>> +     err = obex_service_driver_register(&mas);
>> +     if (err < 0)
>> +             goto fail_mas_reg;
>> +
>>       return 0;
>> +
>> +fail_mas_reg:
>> +     return err;
>>  }
>
> Just "return obex_service_driver_register(&mas);" should be enough.
This one makes more sense when you look at all patches in this set as a whole.

-- 
Slawomir Bochenski

[PATCH 3/4] Add MIME driver to MAP plugin

[lkslawek]

From: Slawomir Bochenski <lkslawek@gmail.com>

As procedures when communicating with message backend will be the same
regardless of the actual type in request, there is only one MIME driver,
thus .mimetype is left NULL.
---
 plugins/mas.c |   55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/plugins/mas.c b/plugins/mas.c
index 2d061a1..6636b75 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -33,6 +33,7 @@
 #include "log.h"
 #include "obex.h"
 #include "service.h"
+#include "mimetype.h"
 #include "dbus.h"
 
 #include "messages.h"
@@ -192,6 +193,43 @@ static int mas_setpath(struct obex_session *os, obex_object_t *obj,
 
 	return 0;
 }
+
+static void *any_open(const char *name, int oflag, mode_t mode,
+				void *driver_data, size_t *size, int *err)
+{
+	struct mas_session *mas = driver_data;
+
+	DBG("");
+
+	*err = 0;
+	return mas;
+}
+
+static ssize_t any_write(void *object, const void *buf, size_t count)
+{
+	DBG("");
+
+	return count;
+}
+
+static ssize_t any_read(void *obj, void *buf, size_t count,
+				uint8_t *hi, unsigned int *flags)
+{
+	DBG("");
+
+	*hi = OBEX_HDR_BODY;
+	*flags = 0;
+
+	return 0;
+}
+
+static int any_close(void *obj)
+{
+	DBG("");
+
+	return 0;
+}
+
 static struct obex_service_driver mas = {
 	.name = "Message Access server",
 	.service = OBEX_MAS,
@@ -206,10 +244,24 @@ static struct obex_service_driver mas = {
 	.disconnect = mas_disconnect,
 };
 
+static struct obex_mime_type_driver mime_map = {
+	.target = MAS_TARGET,
+	.target_size = TARGET_SIZE,
+	.mimetype = NULL,
+	.open = any_open,
+	.close = any_close,
+	.read = any_read,
+	.write = any_write,
+};
+
 static int mas_init(void)
 {
 	int err;
 
+	err = obex_mime_type_driver_register(&mime_map);
+	if (err < 0)
+		goto fail_mime;
+
 	err = obex_service_driver_register(&mas);
 	if (err < 0)
 		goto fail_mas_reg;
@@ -217,12 +269,15 @@ static int mas_init(void)
 	return 0;
 
 fail_mas_reg:
+	obex_mime_type_driver_unregister(&mime_map);
+fail_mime:
 	return err;
 }
 
 static void mas_exit(void)
 {
 	obex_service_driver_unregister(&mas);
+	obex_mime_type_driver_unregister(&mime_map);
 }
 
 OBEX_PLUGIN_DEFINE(mas, mas_init, mas_exit)
-- 
1.7.1

[PATCH 4/4] Add detecting of MAP function in OBEX request

[lkslawek]

From: Slawomir Bochenski <lkslawek@gmail.com>

There is also first part of mas.c <-> backend API. The mas_request
structure will be used when calling backend functions.
---
 plugins/mas.c      |   55 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 plugins/messages.h |   15 ++++++++++++++
 2 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/plugins/mas.c b/plugins/mas.c
index 6636b75..36b4b64 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -25,6 +25,7 @@
 #include <config.h>
 #endif
 
+#include <string.h>
 #include <errno.h>
 #include <glib.h>
 #include <openobex/obex.h>
@@ -38,6 +39,14 @@
 
 #include "messages.h"
 
+#define EVENT_TYPE		"x-bt/MAP-event-report"
+#define MESSAGE_TYPE		"x-bt/message"
+#define FOLDER_LISTING_TYPE	"x-obex/folder-listing"
+#define MESSAGES_LISTING_TYPE	"x-bt/MAP-msg-listing"
+#define NOTIFICATION_TYPE	"x-bt/MAP-NotificationRegistration"
+#define STATUS_TYPE		"x-bt/messageStatus"
+#define UPDATE_TYPE		"x-bt/MAP-messageUpdate"
+
 /* Channel number according to bluez doc/assigned-numbers.txt */
 #define MAS_CHANNEL	16
 
@@ -99,6 +108,14 @@ static void mas_clean(struct mas_session *mas)
 	g_free(mas);
 }
 
+static void reset_request(struct mas_session *mas)
+{
+	if (mas->request) {
+		g_free(mas->request);
+		mas->request = NULL;
+	}
+}
+
 static void *mas_connect(struct obex_session *os, int *err)
 {
 	struct mas_session *mas;
@@ -139,6 +156,21 @@ static int mas_get(struct obex_session *os, obex_object_t *obj,
 	if (type == NULL)
 		return -EBADR;
 
+	mas->request = g_new0(struct mas_request, 1);
+
+	/* NOTE: type is case-insensitive! */
+	if (g_ascii_strcasecmp(type, FOLDER_LISTING_TYPE) == 0)
+		mas->request->fid = MFID_GET_FOLDER_LISTING;
+	else if (g_ascii_strcasecmp(type, MESSAGES_LISTING_TYPE) == 0)
+		mas->request->fid = MFID_GET_MESSAGES_LISTING;
+	else if (g_ascii_strcasecmp(type, MESSAGE_TYPE) == 0)
+		mas->request->fid = MFID_GET_MESSAGE;
+	else {
+		DBG("Incorrect type: %s", type);
+		ret = -EBADR;
+		goto fail;
+	}
+
 	*stream = FALSE;
 
 	ret = obex_get_stream_start(os, name);
@@ -147,6 +179,7 @@ static int mas_get(struct obex_session *os, obex_object_t *obj,
 
 	return 0;
 fail:
+	reset_request(mas);
 	return ret;
 }
 
@@ -162,12 +195,30 @@ static int mas_put(struct obex_session *os, obex_object_t *obj, void *user_data)
 	if (type == NULL)
 		return -EBADR;
 
+	mas->request = g_new0(struct mas_request, 1);
+
+	/* NOTE: type is case-insensitive! */
+	if (g_ascii_strcasecmp(type, NOTIFICATION_TYPE) == 0)
+		mas->request->fid = MFID_SET_NOTIFICATION_REGISTRATION;
+	else if (g_ascii_strcasecmp(type, STATUS_TYPE) == 0)
+		mas->request->fid = MFID_SET_MESSAGE_STATUS;
+	else if (g_ascii_strcasecmp(type, MESSAGE_TYPE) == 0)
+		mas->request->fid = MFID_PUSH_MESSAGE;
+	else if (g_ascii_strcasecmp(type, UPDATE_TYPE) == 0)
+		mas->request->fid = MFID_UPDATE_INBOX;
+	else {
+		DBG("Incorrect type: %s", type);
+		ret = -EBADR;
+		goto fail;
+	}
+
 	ret = obex_put_stream_start(os, name);
 	if (ret < 0)
 		goto fail;
 
 	return 0;
 fail:
+	reset_request(mas);
 	return ret;
 }
 
@@ -225,8 +276,12 @@ static ssize_t any_read(void *obj, void *buf, size_t count,
 
 static int any_close(void *obj)
 {
+	struct mas_session *mas = obj;
+
 	DBG("");
 
+	reset_request(mas);
+
 	return 0;
 }
 
diff --git a/plugins/messages.h b/plugins/messages.h
index 2a41ea7..ccbb0af 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -20,3 +20,18 @@
  *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  *
  */
+
+enum messages_function_id {
+	MFID_INVALID = 0,
+	MFID_SET_NOTIFICATION_REGISTRATION,
+	MFID_GET_FOLDER_LISTING,
+	MFID_GET_MESSAGES_LISTING,
+	MFID_GET_MESSAGE,
+	MFID_SET_MESSAGE_STATUS,
+	MFID_PUSH_MESSAGE,
+	MFID_UPDATE_INBOX,
+};
+
+struct mas_request {
+	enum messages_function_id fid;
+};
-- 
1.7.1

Re: [PATCH 0/4] Message Access Profile plugin

[Luiz Augusto von Dentz]

Hi,

On Wed, Mar 2, 2011 at 6:36 AM,  <lkslawek@gmail.com> wrote:
> These are the first ones of upcoming series of patches implementing Message
> Access Profile (server role) in obexd.
>
> The work is more than less complete (~4k lines now), but as advised by Johan,
> I'm cutting the whole thing into smaller pieces before sending this here.
>
> Regards,
> Slawomir Bochenski
>
>  .gitignore               |    1 +
>  Makefile.am              |   10 ++-
>  configure.ac             |   12 ++
>  plugins/mas.c            |  338 ++++++++++++++++++++++++++++++++++++++++++++++
>  plugins/messages-dummy.c |   28 ++++
>  plugins/messages.h       |   37 +++++
>  src/main.c               |   11 ++-
>  src/obex.h               |    1 +
>  8 files changed, 435 insertions(+), 3 deletions(-)

I guess naming the file and plugin 'map' would make more sense here,
we don't want to confuse people what this file is about.

Also Ive been thinking on removing this internal APIs for backend,
each would implemented as plugin/mimetype driver directly and we can
create basic drivers for pbap and map and export its callbacks on
pbap.h and map.h respectively as we do for pcsuite which uses ftp
driver callbacks.

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: [PATCH 0/4] Message Access Profile plugin

[Slawomir Bochenski]

Hi,

On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> I guess naming the file and plugin 'map' would make more sense here,
> we don't want to confuse people what this file is about.

There are two things which makes MAP - MAS and MNS. It is not like any
other plugin we have here. The communication goes both ways, i.e. in
full implementation there are OBEX server and OBEX client present on
_both_ sides. As generally architecture of obexd and obex-client
currently allows OBEX servers to be implemented only in obexd and OBEX
clients in obex-client, it is easy to imagine that in order to add
full MAP client role, there would be need for another plugin in obexd
for MNS.

So there can be mns.c and mas.c, both in obexd, both completely
independent - each one of them having nothing in common, i.e. user can
run mns when he wants to be MAP client, mas when he wants to be MAP
server or mas and mns when he likes to be both.

Therefore naming it "map" would confuse more those who know what is
MAP and what they really want.

> Also Ive been thinking on removing this internal APIs for backend,
> each would implemented as plugin/mimetype driver directly and we can
> create basic drivers for pbap and map and export its callbacks on
> pbap.h and map.h respectively as we do for pcsuite which uses ftp
> driver callbacks.

I really hope that you will keep this in "thinking stage" for now. I
see problems coming. I'd rather prefer to use what we have now and
what works. There might be some parts that won't fit well in this new
philosophy. It would be better to postpone considering such changes in
MAP to the point when it will be in repository in a more complete
form.


-- 
Slawomir Bochenski

Re: [PATCH 0/4] Message Access Profile plugin

[Luiz Augusto von Dentz]

Hi,

On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
> Hi,
>
> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> I guess naming the file and plugin 'map' would make more sense here,
>> we don't want to confuse people what this file is about.
>
> There are two things which makes MAP - MAS and MNS. It is not like any
> other plugin we have here. The communication goes both ways, i.e. in
> full implementation there are OBEX server and OBEX client present on
> _both_ sides. As generally architecture of obexd and obex-client
> currently allows OBEX servers to be implemented only in obexd and OBEX
> clients in obex-client, it is easy to imagine that in order to add
> full MAP client role, there would be need for another plugin in obexd
> for MNS.

But that doesn't solve any problem since the profile as a whole need
both client and server side it make no sense to have one without the
other, we can still have different drivers for each sides but the
plugin should be the same, it is a single profile not two.

> So there can be mns.c and mas.c, both in obexd, both completely
> independent - each one of them having nothing in common, i.e. user can
> run mns when he wants to be MAP client, mas when he wants to be MAP
> server or mas and mns when he likes to be both.
>
> Therefore naming it "map" would confuse more those who know what is
> MAP and what they really want.

Again if they cannot be qualified separately then it make no sense to
separate them in two plugin, the logical separation can happen on
driver level.

>> Also Ive been thinking on removing this internal APIs for backend,
>> each would implemented as plugin/mimetype driver directly and we can
>> create basic drivers for pbap and map and export its callbacks on
>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>> driver callbacks.
>
> I really hope that you will keep this in "thinking stage" for now. I
> see problems coming. I'd rather prefer to use what we have now and
> what works. There might be some parts that won't fit well in this new
> philosophy. It would be better to postpone considering such changes in
> MAP to the point when it will be in repository in a more complete
> form.

It should not cause any problem, because core only knows about the
mimetype drivers, the backend interface is a plugin specific API. In
theory one could re implement pbap plugin which would have another
backend interface. If we have the backend implementing the mimetype
driver the only thing that changes is that no API is needed between
e.g. pbap plugin and the backend.

Note that one of the worst problems with current pbap implementation
is the backend API, because it has to handle things like asynchronous
requests and cancel requests which comes from mimetype driver it had
to change several times during the development, I don't want this to
happen with map.

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: [PATCH 0/4] Message Access Profile plugin

[Slawomir Bochenski]

On 3/3/11, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com>
> wrote:
>> Hi,
>>
>> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>> I guess naming the file and plugin 'map' would make more sense here,
>>> we don't want to confuse people what this file is about.
>>
>> There are two things which makes MAP - MAS and MNS. It is not like any
>> other plugin we have here. The communication goes both ways, i.e. in
>> full implementation there are OBEX server and OBEX client present on
>> _both_ sides. As generally architecture of obexd and obex-client
>> currently allows OBEX servers to be implemented only in obexd and OBEX
>> clients in obex-client, it is easy to imagine that in order to add
>> full MAP client role, there would be need for another plugin in obexd
>> for MNS.
>
> But that doesn't solve any problem since the profile as a whole need
> both client and server side it make no sense to have one without the
> other, we can still have different drivers for each sides but the
> plugin should be the same, it is a single profile not two.
>

Let me rephrase this:
+-------+-------------+---------------+
|MAP    | obex-client | client/mns.c  |
|Server |             |     / \       |
|role   |             |      |        |
|       +-------------|    D-Bus      |
|       | obexd       |      |        |
|       |             |     \ /       |
|       |             | plugins/mas.c |
+-------+-------------+---------------+

+-------+-------------+---------------+
|MAP    | obex-client | client/mas.c  |
|Client |             |     / \       |
|role   |             |      |        |
|       +-------------|    D-Bus      |
|       | obexd       |      |        |
|       |             |     \ /       |
|       |             | plugins/mns.c |
+-------+-------------+---------------+

>> So there can be mns.c and mas.c, both in obexd, both completely
>> independent - each one of them having nothing in common, i.e. user can
>> run mns when he wants to be MAP client, mas when he wants to be MAP
>> server or mas and mns when he likes to be both.
>>
>> Therefore naming it "map" would confuse more those who know what is
>> MAP and what they really want.
>
> Again if they cannot be qualified separately then it make no sense to
> separate them in two plugin, the logical separation can happen on
> driver level.

So yes, they most definitely can be qualified separately.

>>> Also Ive been thinking on removing this internal APIs for backend,
>>> each would implemented as plugin/mimetype driver directly and we can
>>> create basic drivers for pbap and map and export its callbacks on
>>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>>> driver callbacks.
>>
>> I really hope that you will keep this in "thinking stage" for now. I
>> see problems coming. I'd rather prefer to use what we have now and
>> what works. There might be some parts that won't fit well in this new
>> philosophy. It would be better to postpone considering such changes in
>> MAP to the point when it will be in repository in a more complete
>> form.
>
> It should not cause any problem, because core only knows about the
> mimetype drivers, the backend interface is a plugin specific API. In
> theory one could re implement pbap plugin which would have another
> backend interface. If we have the backend implementing the mimetype
> driver the only thing that changes is that no API is needed between
> e.g. pbap plugin and the backend.
>
> Note that one of the worst problems with current pbap implementation
> is the backend API, because it has to handle things like asynchronous
> requests and cancel requests which comes from mimetype driver it had
> to change several times during the development, I don't want this to
> happen with map.

This already happened with MAP and it works. It is done differently than
in PBAP, for example handling of application parameters and cases when
body is sent and when it is not is done more cleanly. And I've already
seen the problems closer to the end of the MAP implementation road. What
you're proposing will make this road more bumpy.

--
Slawomir Bochenski

Re: [PATCH 0/4] Message Access Profile plugin

[Luiz Augusto von Dentz]

Hi,

On Thu, Mar 3, 2011 at 11:09 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
> On 3/3/11, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> I guess naming the file and plugin 'map' would make more sense here,
>>>> we don't want to confuse people what this file is about.
>>>
>>> There are two things which makes MAP - MAS and MNS. It is not like any
>>> other plugin we have here. The communication goes both ways, i.e. in
>>> full implementation there are OBEX server and OBEX client present on
>>> _both_ sides. As generally architecture of obexd and obex-client
>>> currently allows OBEX servers to be implemented only in obexd and OBEX
>>> clients in obex-client, it is easy to imagine that in order to add
>>> full MAP client role, there would be need for another plugin in obexd
>>> for MNS.
>>
>> But that doesn't solve any problem since the profile as a whole need
>> both client and server side it make no sense to have one without the
>> other, we can still have different drivers for each sides but the
>> plugin should be the same, it is a single profile not two.
>>
>
> Let me rephrase this:
> +-------+-------------+---------------+
> |MAP    | obex-client | client/mns.c  |
> |Server |             |     / \       |
> |role   |             |      |        |
> |       +-------------|    D-Bus      |
> |       | obexd       |      |        |
> |       |             |     \ /       |
> |       |             | plugins/mas.c |
> +-------+-------------+---------------+
>
> +-------+-------------+---------------+
> |MAP    | obex-client | client/mas.c  |
> |Client |             |     / \       |
> |role   |             |      |        |
> |       +-------------|    D-Bus      |
> |       | obexd       |      |        |
> |       |             |     \ /       |
> |       |             | plugins/mns.c |
> +-------+-------------+---------------+
>
>>> So there can be mns.c and mas.c, both in obexd, both completely
>>> independent - each one of them having nothing in common, i.e. user can
>>> run mns when he wants to be MAP client, mas when he wants to be MAP
>>> server or mas and mns when he likes to be both.
>>>
>>> Therefore naming it "map" would confuse more those who know what is
>>> MAP and what they really want.
>>
>> Again if they cannot be qualified separately then it make no sense to
>> separate them in two plugin, the logical separation can happen on
>> driver level.
>
> So yes, they most definitely can be qualified separately.

Sorry but I doubt you can, MAS and MSN are not profiles they just
represent services, besides it is mandatory to support both MAS and
MNS in MSE see Table 4-1:MAP features, so at least for obexd it
doesn't make much sense to have them separated in two plugins, they
can be separated in different files which are used by the same plugin,
this make it easier to enable/disable MAP as o whole.

>>>> Also Ive been thinking on removing this internal APIs for backend,
>>>> each would implemented as plugin/mimetype driver directly and we can
>>>> create basic drivers for pbap and map and export its callbacks on
>>>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>>>> driver callbacks.
>>>
>>> I really hope that you will keep this in "thinking stage" for now. I
>>> see problems coming. I'd rather prefer to use what we have now and
>>> what works. There might be some parts that won't fit well in this new
>>> philosophy. It would be better to postpone considering such changes in
>>> MAP to the point when it will be in repository in a more complete
>>> form.
>>
>> It should not cause any problem, because core only knows about the
>> mimetype drivers, the backend interface is a plugin specific API. In
>> theory one could re implement pbap plugin which would have another
>> backend interface. If we have the backend implementing the mimetype
>> driver the only thing that changes is that no API is needed between
>> e.g. pbap plugin and the backend.
>>
>> Note that one of the worst problems with current pbap implementation
>> is the backend API, because it has to handle things like asynchronous
>> requests and cancel requests which comes from mimetype driver it had
>> to change several times during the development, I don't want this to
>> happen with map.
>
> This already happened with MAP and it works. It is done differently than
> in PBAP, for example handling of application parameters and cases when
> body is sent and when it is not is done more cleanly. And I've already
> seen the problems closer to the end of the MAP implementation road. What
> you're proposing will make this road more bumpy.

Sorry, but until this reach upstream you cannot assumed it has
happened. That why we suggest sending us patches earlier so we can
review and discuss architect and design aspects not only code, now
that we had more experience with the backend interface we could
actually experiment the direct approach without creating more APIs,
usually it is easier to add API but hard to remove them once a lot of
code depend on them. What you may suggest is to integrate MAP
implementation as it is and latter change it, but please communicate
before about design decisions, there is no need to develop this
completely before sending upstream.

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: [PATCH 0/4] Message Access Profile plugin

[Slawomir Bochenski]

On Thu, Mar 3, 2011 at 4:08 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 3, 2011 at 11:09 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
>> On 3/3/11, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>>> Hi,
>>>
>>> On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
>>>> <luiz.dentz@gmail.com> wrote:
>>>>> I guess naming the file and plugin 'map' would make more sense here,
>>>>> we don't want to confuse people what this file is about.
>>>>
>>>> There are two things which makes MAP - MAS and MNS. It is not like any
>>>> other plugin we have here. The communication goes both ways, i.e. in
>>>> full implementation there are OBEX server and OBEX client present on
>>>> _both_ sides. As generally architecture of obexd and obex-client
>>>> currently allows OBEX servers to be implemented only in obexd and OBEX
>>>> clients in obex-client, it is easy to imagine that in order to add
>>>> full MAP client role, there would be need for another plugin in obexd
>>>> for MNS.
>>>
>>> But that doesn't solve any problem since the profile as a whole need
>>> both client and server side it make no sense to have one without the
>>> other, we can still have different drivers for each sides but the
>>> plugin should be the same, it is a single profile not two.
>>>
>>
>> Let me rephrase this:
>> +-------+-------------+---------------+
>> |MAP    | obex-client | client/mns.c  |
>> |Server |             |     / \       |
>> |role   |             |      |        |
>> |       +-------------|    D-Bus      |
>> |       | obexd       |      |        |
>> |       |             |     \ /       |
>> |       |             | plugins/mas.c |
>> +-------+-------------+---------------+
>>
>> +-------+-------------+---------------+
>> |MAP    | obex-client | client/mas.c  |
>> |Client |             |     / \       |
>> |role   |             |      |        |
>> |       +-------------|    D-Bus      |
>> |       | obexd       |      |        |
>> |       |             |     \ /       |
>> |       |             | plugins/mns.c |
>> +-------+-------------+---------------+
>>
>>>> So there can be mns.c and mas.c, both in obexd, both completely
>>>> independent - each one of them having nothing in common, i.e. user can
>>>> run mns when he wants to be MAP client, mas when he wants to be MAP
>>>> server or mas and mns when he likes to be both.
>>>>
>>>> Therefore naming it "map" would confuse more those who know what is
>>>> MAP and what they really want.
>>>
>>> Again if they cannot be qualified separately then it make no sense to
>>> separate them in two plugin, the logical separation can happen on
>>> driver level.
>>
>> So yes, they most definitely can be qualified separately.
>
> Sorry but I doubt you can, MAS and MSN are not profiles they just
> represent services, besides it is mandatory to support both MAS and
> MNS in MSE see Table 4-1:MAP features, so at least for obexd it
> doesn't make much sense to have them separated in two plugins, they
> can be separated in different files which are used by the same plugin,
> this make it easier to enable/disable MAP as o whole.
Please read me again. Especially take a longer look at the graphics
with roles presented. The plugins/mns.c presented here _does not_ have
_anything_ to do with plugins/mas.c - they are used in completely
different roles. Once again: they are NOT part of the same thing. See
chapter 2.1 in MAP specification. What will be qualified _together_ is
plugin/mas.c and client/mns.c.

>>>>> Also Ive been thinking on removing this internal APIs for backend,
>>>>> each would implemented as plugin/mimetype driver directly and we can
>>>>> create basic drivers for pbap and map and export its callbacks on
>>>>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>>>>> driver callbacks.
>>>>
>>>> I really hope that you will keep this in "thinking stage" for now. I
>>>> see problems coming. I'd rather prefer to use what we have now and
>>>> what works. There might be some parts that won't fit well in this new
>>>> philosophy. It would be better to postpone considering such changes in
>>>> MAP to the point when it will be in repository in a more complete
>>>> form.
>>>
>>> It should not cause any problem, because core only knows about the
>>> mimetype drivers, the backend interface is a plugin specific API. In
>>> theory one could re implement pbap plugin which would have another
>>> backend interface. If we have the backend implementing the mimetype
>>> driver the only thing that changes is that no API is needed between
>>> e.g. pbap plugin and the backend.
>>>
>>> Note that one of the worst problems with current pbap implementation
>>> is the backend API, because it has to handle things like asynchronous
>>> requests and cancel requests which comes from mimetype driver it had
>>> to change several times during the development, I don't want this to
>>> happen with map.
>>
>> This already happened with MAP and it works. It is done differently than
>> in PBAP, for example handling of application parameters and cases when
>> body is sent and when it is not is done more cleanly. And I've already
>> seen the problems closer to the end of the MAP implementation road. What
>> you're proposing will make this road more bumpy.
>
> Sorry, but until this reach upstream you cannot assumed it has
> happened. That why we suggest sending us patches earlier so we can
> review and discuss architect and design aspects not only code, now
> that we had more experience with the backend interface we could
> actually experiment the direct approach without creating more APIs,
> usually it is easier to add API but hard to remove them once a lot of
> code depend on them. What you may suggest is to integrate MAP
> implementation as it is and latter change it, but please communicate
> before about design decisions, there is no need to develop this
> completely before sending upstream.
PBAP is much simpler than MAP. Thus it may be tempting to do
assumptions about MAP using previous experiences. This may not lead to
good conclusions.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>



-- 
Slawomir Bochenski

Re: [PATCH 0/4] Message Access Profile plugin

[Luiz Augusto von Dentz]

Hi,

On Thu, Mar 3, 2011 at 12:20 PM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 4:08 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Mar 3, 2011 at 11:09 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
>>> On 3/3/11, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>> I guess naming the file and plugin 'map' would make more sense here,
>>>>>> we don't want to confuse people what this file is about.
>>>>>
>>>>> There are two things which makes MAP - MAS and MNS. It is not like any
>>>>> other plugin we have here. The communication goes both ways, i.e. in
>>>>> full implementation there are OBEX server and OBEX client present on
>>>>> _both_ sides. As generally architecture of obexd and obex-client
>>>>> currently allows OBEX servers to be implemented only in obexd and OBEX
>>>>> clients in obex-client, it is easy to imagine that in order to add
>>>>> full MAP client role, there would be need for another plugin in obexd
>>>>> for MNS.
>>>>
>>>> But that doesn't solve any problem since the profile as a whole need
>>>> both client and server side it make no sense to have one without the
>>>> other, we can still have different drivers for each sides but the
>>>> plugin should be the same, it is a single profile not two.
>>>>
>>>
>>> Let me rephrase this:
>>> +-------+-------------+---------------+
>>> |MAP    | obex-client | client/mns.c  |
>>> |Server |             |     / \       |
>>> |role   |             |      |        |
>>> |       +-------------|    D-Bus      |
>>> |       | obexd       |      |        |
>>> |       |             |     \ /       |
>>> |       |             | plugins/mas.c |
>>> +-------+-------------+---------------+
>>>
>>> +-------+-------------+---------------+
>>> |MAP    | obex-client | client/mas.c  |
>>> |Client |             |     / \       |
>>> |role   |             |      |        |
>>> |       +-------------|    D-Bus      |
>>> |       | obexd       |      |        |
>>> |       |             |     \ /       |
>>> |       |             | plugins/mns.c |
>>> +-------+-------------+---------------+
>>>
>>>>> So there can be mns.c and mas.c, both in obexd, both completely
>>>>> independent - each one of them having nothing in common, i.e. user can
>>>>> run mns when he wants to be MAP client, mas when he wants to be MAP
>>>>> server or mas and mns when he likes to be both.
>>>>>
>>>>> Therefore naming it "map" would confuse more those who know what is
>>>>> MAP and what they really want.
>>>>
>>>> Again if they cannot be qualified separately then it make no sense to
>>>> separate them in two plugin, the logical separation can happen on
>>>> driver level.
>>>
>>> So yes, they most definitely can be qualified separately.
>>
>> Sorry but I doubt you can, MAS and MSN are not profiles they just
>> represent services, besides it is mandatory to support both MAS and
>> MNS in MSE see Table 4-1:MAP features, so at least for obexd it
>> doesn't make much sense to have them separated in two plugins, they
>> can be separated in different files which are used by the same plugin,
>> this make it easier to enable/disable MAP as o whole.
> Please read me again. Especially take a longer look at the graphics
> with roles presented. The plugins/mns.c presented here _does not_ have
> _anything_ to do with plugins/mas.c - they are used in completely
> different roles. Once again: they are NOT part of the same thing. See
> chapter 2.1 in MAP specification. What will be qualified _together_ is
> plugin/mas.c and client/mns.c.

Yep, another design decision you took without consulting us, I believe
MSE should be completely implemented on obexd and MCE on obex-client,
why do you thing involving two processes here would make sense? There
is nothing prevent us to implement client code on obexd nor server
code on obex-client, this was a design choice you took which doesn't
mean it can't work using MSE/MCE separation.

>>>>>> Also Ive been thinking on removing this internal APIs for backend,
>>>>>> each would implemented as plugin/mimetype driver directly and we can
>>>>>> create basic drivers for pbap and map and export its callbacks on
>>>>>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>>>>>> driver callbacks.
>>>>>
>>>>> I really hope that you will keep this in "thinking stage" for now. I
>>>>> see problems coming. I'd rather prefer to use what we have now and
>>>>> what works. There might be some parts that won't fit well in this new
>>>>> philosophy. It would be better to postpone considering such changes in
>>>>> MAP to the point when it will be in repository in a more complete
>>>>> form.
>>>>
>>>> It should not cause any problem, because core only knows about the
>>>> mimetype drivers, the backend interface is a plugin specific API. In
>>>> theory one could re implement pbap plugin which would have another
>>>> backend interface. If we have the backend implementing the mimetype
>>>> driver the only thing that changes is that no API is needed between
>>>> e.g. pbap plugin and the backend.
>>>>
>>>> Note that one of the worst problems with current pbap implementation
>>>> is the backend API, because it has to handle things like asynchronous
>>>> requests and cancel requests which comes from mimetype driver it had
>>>> to change several times during the development, I don't want this to
>>>> happen with map.
>>>
>>> This already happened with MAP and it works. It is done differently than
>>> in PBAP, for example handling of application parameters and cases when
>>> body is sent and when it is not is done more cleanly. And I've already
>>> seen the problems closer to the end of the MAP implementation road. What
>>> you're proposing will make this road more bumpy.
>>
>> Sorry, but until this reach upstream you cannot assumed it has
>> happened. That why we suggest sending us patches earlier so we can
>> review and discuss architect and design aspects not only code, now
>> that we had more experience with the backend interface we could
>> actually experiment the direct approach without creating more APIs,
>> usually it is easier to add API but hard to remove them once a lot of
>> code depend on them. What you may suggest is to integrate MAP
>> implementation as it is and latter change it, but please communicate
>> before about design decisions, there is no need to develop this
>> completely before sending upstream.
> PBAP is much simpler than MAP. Thus it may be tempting to do
> assumptions about MAP using previous experiences. This may not lead to
> good conclusions.

If mimetype driver API was not able to implement the drivers for MAP
you would have to change it, I don't see any modification to
mimetype.h, so it looks exactly like pbap, mimetype driver is used to
extract the request information to pass to backend via some API.

Please if you have a use case for MAP that with mimetype driver it
cannot be implement please provide it, otherwise I would consider that
you meant the backend is much more complex, but the requests are quite
similar.


-- 
Luiz Augusto von Dentz
Computer Engineer

Re: [PATCH 0/4] Message Access Profile plugin

[Slawomir Bochenski]

Hello Luiz,

On Thu, Mar 3, 2011 at 8:54 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 3, 2011 at 12:20 PM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
>> On Thu, Mar 3, 2011 at 4:08 PM, Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>> Hi,
>>>
>>> On Thu, Mar 3, 2011 at 11:09 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
>>>> On 3/3/11, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Mar 3, 2011 at 6:58 AM, Slawomir Bochenski <lkslawek@gmail.com>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Mar 2, 2011 at 10:12 PM, Luiz Augusto von Dentz
>>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>>> I guess naming the file and plugin 'map' would make more sense here,
>>>>>>> we don't want to confuse people what this file is about.
>>>>>>
>>>>>> There are two things which makes MAP - MAS and MNS. It is not like any
>>>>>> other plugin we have here. The communication goes both ways, i.e. in
>>>>>> full implementation there are OBEX server and OBEX client present on
>>>>>> _both_ sides. As generally architecture of obexd and obex-client
>>>>>> currently allows OBEX servers to be implemented only in obexd and OBEX
>>>>>> clients in obex-client, it is easy to imagine that in order to add
>>>>>> full MAP client role, there would be need for another plugin in obexd
>>>>>> for MNS.
>>>>>
>>>>> But that doesn't solve any problem since the profile as a whole need
>>>>> both client and server side it make no sense to have one without the
>>>>> other, we can still have different drivers for each sides but the
>>>>> plugin should be the same, it is a single profile not two.
>>>>>
>>>>
>>>> Let me rephrase this:
>>>> +-------+-------------+---------------+
>>>> |MAP    | obex-client | client/mns.c  |
>>>> |Server |             |     / \       |
>>>> |role   |             |      |        |
>>>> |       +-------------|    D-Bus      |
>>>> |       | obexd       |      |        |
>>>> |       |             |     \ /       |
>>>> |       |             | plugins/mas.c |
>>>> +-------+-------------+---------------+
>>>>
>>>> +-------+-------------+---------------+
>>>> |MAP    | obex-client | client/mas.c  |
>>>> |Client |             |     / \       |
>>>> |role   |             |      |        |
>>>> |       +-------------|    D-Bus      |
>>>> |       | obexd       |      |        |
>>>> |       |             |     \ /       |
>>>> |       |             | plugins/mns.c |
>>>> +-------+-------------+---------------+
>>>>
>>>>>> So there can be mns.c and mas.c, both in obexd, both completely
>>>>>> independent - each one of them having nothing in common, i.e. user can
>>>>>> run mns when he wants to be MAP client, mas when he wants to be MAP
>>>>>> server or mas and mns when he likes to be both.
>>>>>>
>>>>>> Therefore naming it "map" would confuse more those who know what is
>>>>>> MAP and what they really want.
>>>>>
>>>>> Again if they cannot be qualified separately then it make no sense to
>>>>> separate them in two plugin, the logical separation can happen on
>>>>> driver level.
>>>>
>>>> So yes, they most definitely can be qualified separately.
>>>
>>> Sorry but I doubt you can, MAS and MSN are not profiles they just
>>> represent services, besides it is mandatory to support both MAS and
>>> MNS in MSE see Table 4-1:MAP features, so at least for obexd it
>>> doesn't make much sense to have them separated in two plugins, they
>>> can be separated in different files which are used by the same plugin,
>>> this make it easier to enable/disable MAP as o whole.
>> Please read me again. Especially take a longer look at the graphics
>> with roles presented. The plugins/mns.c presented here _does not_ have
>> _anything_ to do with plugins/mas.c - they are used in completely
>> different roles. Once again: they are NOT part of the same thing. See
>> chapter 2.1 in MAP specification. What will be qualified _together_ is
>> plugin/mas.c and client/mns.c.
> Yep, another design decision you took without consulting us, I believe
> MSE should be completely implemented on obexd and MCE on obex-client,
> why do you thing involving two processes here would make sense?

Actually, with this whole plethora of small decisions I did not feel
urge to discuss, this was a notable exception. Before I even wrote a
single line of notifications-related code I considered carefully
multiple possibilities. And then I shared my findings on #obexd @
freenode asking specifically what would be the preferred way to
implement this. Johan took part in the discussion addressing this and
we came to conclusion, that even though this needs two processes
running (which in fact was what personally make me a little bit
reluctant) this is the cleanest and simplest way to do this.

> There is nothing prevent us to implement client code on obexd nor server
> code on obex-client, this was a design choice you took

Are we still talking about obexd or is it obex-data-server (which do
have client and server functionality integrated in one daemon)? This
is far more complicated. As far as I know currently there is nothing
allowing implementing OBEX clients in obexd nor allowing implementing
OBEX servers in obex-client. Even in server role, when required OBEX
client is simple this would require adding large parts from
obex-client to obexd (SDP browsing, actual client event handlers) and
it might be not as easy as linking it with parts of obex-client.
Unless we want to achieve the same architecture that obex-data-server
has and eventually melt obex-client and obexd into one daemon which
binds them all ;), I don't think it is possible

For MSE I was thinking about manually adding parts for searching SDP,
making my own bluetooth socket and using openobex directly. This would
make the code horrible, but still, this is a possibility. I would not
want to go there, though. In case of MCE there is no requirement that
MNS server has to be present, so they can be left separated between
obex-client and obexd and do not even talk to each other, only to the
MCE client applications that would want to utilize them.

> which doesn't mean it can't work using MSE/MCE separation.

Please restate this sentence ending. Well, I just plainly do not get
it at all. Even whether you meant something negative or positive. :)

>>>>>>> Also Ive been thinking on removing this internal APIs for backend,
>>>>>>> each would implemented as plugin/mimetype driver directly and we can
>>>>>>> create basic drivers for pbap and map and export its callbacks on
>>>>>>> pbap.h and map.h respectively as we do for pcsuite which uses ftp
>>>>>>> driver callbacks.
>>>>>>
>>>>>> I really hope that you will keep this in "thinking stage" for now. I
>>>>>> see problems coming. I'd rather prefer to use what we have now and
>>>>>> what works. There might be some parts that won't fit well in this new
>>>>>> philosophy. It would be better to postpone considering such changes in
>>>>>> MAP to the point when it will be in repository in a more complete
>>>>>> form.
>>>>>
>>>>> It should not cause any problem, because core only knows about the
>>>>> mimetype drivers, the backend interface is a plugin specific API. In
>>>>> theory one could re implement pbap plugin which would have another
>>>>> backend interface. If we have the backend implementing the mimetype
>>>>> driver the only thing that changes is that no API is needed between
>>>>> e.g. pbap plugin and the backend.
>>>>>
>>>>> Note that one of the worst problems with current pbap implementation
>>>>> is the backend API, because it has to handle things like asynchronous
>>>>> requests and cancel requests which comes from mimetype driver it had
>>>>> to change several times during the development, I don't want this to
>>>>> happen with map.
>>>>
>>>> This already happened with MAP and it works. It is done differently than
>>>> in PBAP, for example handling of application parameters and cases when
>>>> body is sent and when it is not is done more cleanly. And I've already
>>>> seen the problems closer to the end of the MAP implementation road. What
>>>> you're proposing will make this road more bumpy.
>>>
>>> Sorry, but until this reach upstream you cannot assumed it has
>>> happened. That why we suggest sending us patches earlier so we can
>>> review and discuss architect and design aspects not only code, now
>>> that we had more experience with the backend interface we could
>>> actually experiment the direct approach without creating more APIs,
>>> usually it is easier to add API but hard to remove them once a lot of
>>> code depend on them. What you may suggest is to integrate MAP
>>> implementation as it is and latter change it, but please communicate
>>> before about design decisions, there is no need to develop this
>>> completely before sending upstream.
>> PBAP is much simpler than MAP. Thus it may be tempting to do
>> assumptions about MAP using previous experiences. This may not lead to
>> good conclusions.
>
> If mimetype driver API was not able to implement the drivers for MAP
> you would have to change it, I don't see any modification to
> mimetype.h, so it looks exactly like pbap, mimetype driver is used to
> extract the request information to pass to backend via some API.
>
> Please if you have a use case for MAP that with mimetype driver it
> cannot be implement please provide it, otherwise I would consider that
> you meant the backend is much more complex, but the requests are quite
> similar.

Let me bullet point some examples:

* When the notifications are active the backend can call plugin at any
time, not in line with any request currently processed. Backend does
it when it becomes aware of a new message in repository. This is done
by calling glue function, implemented in the plugin.

* Additionally, as backend has a better way of making decisions about
pending notifications (some of these may become outdated before we are
ready to send them), it also does the queuing. It starts queuing
notifications when transport plugin informs it that client wishes to
receive notifications, and this happens right when
SetNotificationRegistration is received. Queuing is needed:
- because of delay between getting SetNotificationRegistration and
making the connection back to MNS OBEX server on client's side,
- because we have to wait for client response on MNS channel to
previous notification before we can send the next one.

So plugin uses another glue functions to say that it is ready to send
next notification in line.

* About this theory regarding another PBAP plugin. I assume you meant
that one wouldn't want to implement exactly another PBAP plugin and
more likely someone would want to develop another profile needing the
access to the same data PBAP does (or parts of it).

I suppose that this is the relation between pcsuite and filesystem.c.
However PBAP or MAP is not a filesystem.c - the data sent is not raw
(or rather depending only on the underlaying accessed object). It is
formatted in some profile-specific fashion. I can see that current
implementation of PBAP makes the backend doing all the work of
formatting data, so this data is useless in case of some new profile
that needs to get phone book entries and possibly send them in it's
own format.

This is not what I've chosen for MAP. For instance message listing
object in MAP profile takes form of XML document. The backend role is
to get all the meta data it can possibly get that is useful in this
listing and it returns this data to transport plugin in struct. This
way the data is really reusable in any other scenarios. Escaping
strings and formatting XML is done in plugin. This also prevents
repetitions in code of multiple backends.

So again - implementing storage backends as mime drivers removes the
flexibility of choosing data structure appropriate for situation.

> --
> Luiz Augusto von Dentz
> Computer Engineer
>



-- 
Slawomir Bochenski