---
client/map.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
doc/client-api.txt | 5 +++-
2 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/client/map.c b/client/map.c
index bee49c5..51a7711 100644
--- a/client/map.c
+++ b/client/map.c
@@ -49,7 +49,63 @@ struct map_data {
static DBusConnection *conn = NULL;
+static void simple_cb(GObex *obex, GError *err, GObexPacket *rsp,
+ gpointer user_data)
+{
+ DBusMessage *reply;
+ struct map_data *map = user_data;
+ guint8 err_code = g_obex_packet_get_operation(rsp, NULL);
+
+ if (err != NULL)
+ reply = g_dbus_create_error(map->msg,
+ "org.openobex.Error.Failed",
+ "%s", err->message);
+ else if (err_code != G_OBEX_RSP_SUCCESS)
+ reply = g_dbus_create_error(map->msg,
+ "org.openobex.Error.Failed",
+ "%s (0x%02x)",
+ g_obex_strerror(err_code),
+ err_code);
+ else
+ reply = dbus_message_new_method_return(map->msg);
+
+ g_dbus_send_message(conn, reply);
+ dbus_message_unref(map->msg);
+}
+
+static DBusMessage *map_setpath(DBusConnection *connection,
+ DBusMessage *message, void *user_data)
+{
+ struct map_data *map = user_data;
+ const char *folder;
+ GObex *obex;
+ GError *err = NULL;
+
+ if (dbus_message_get_args(message, NULL, DBUS_TYPE_STRING, &folder,
+ DBUS_TYPE_INVALID) == FALSE)
+ return g_dbus_create_error(message,
+ "org.openobex.Error.InvalidArguments",
+ NULL);
+
+ obex = obc_session_get_obex(map->session);
+
+ g_obex_setpath(obex, folder, simple_cb, map, &err);
+ if (err != NULL) {
+ DBusMessage *reply;
+ reply = g_dbus_create_error(message,
+ "org.openobex.Error.Failed",
+ "%s", err->message);
+ g_error_free(err);
+ return reply;
+ }
+
+ map->msg = dbus_message_ref(message);
+
+ return NULL;
+}
+
static GDBusMethodTable map_methods[] = {
+ { "SetFolder", "s", "", map_setpath, G_DBUS_METHOD_FLAG_ASYNC },
{ }
};
diff --git a/doc/client-api.txt b/doc/client-api.txt
index ee8951f..fb5a8b2 100644
--- a/doc/client-api.txt
+++ b/doc/client-api.txt
@@ -258,7 +258,10 @@ Service org.openobex.client
Interface org.openobex.MessageAccess
Object path [variable prefix]/{session0,session1,...}
-Methods
+Methods void SetFolder(string name)
+
+ Set working directory for current session, *name* may
+ be the directory name or '..[/dir]'.
Transfer hierarchy
==================
--
1.7.4.1
On Thu, Dec 15, 2011 at 1:17 PM, Johan Hedberg <[email protected]> wrote:
> Hi Bartosz,
>
> On Thu, Dec 15, 2011, Bartosz Szatkowski wrote:
>> > The name should be GetMessageListing and not GetMessagesListing (the
>> > latter isn't really proper english). I went ahead and changed it through
>> > a separate patch since I didn't notice before having already applied
>> > your patch. Also, all this seems to be missing from the API
>> > documentation (doc/*). Please send a patch for that.
>>
>> The function name is "GetMessagesListing" in spec.
>> There is no doc as at the moment there is no apparams handling and no
>> xml parsing, so I'll send patch with doc when we reach full
>> functionality.
>
> So the plan is to return something else than the raw XML that MAP
> provides? In that case I don't think it's necessary to hold on to the
> exact spec naming of these functions. E.g. GetMessages or GetMessageList
> might make more sense in the case that you return a pre-parsed
> list/structure of some kind.
>
> Johan
We planned to return dict {field: value}. Generally I don't care much
about this name - we can go with GetMessageListing, as I seem to use
both forms without noticing it anyway.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Thu, Dec 15, 2011, Bartosz Szatkowski wrote:
> > The name should be GetMessageListing and not GetMessagesListing (the
> > latter isn't really proper english). I went ahead and changed it through
> > a separate patch since I didn't notice before having already applied
> > your patch. Also, all this seems to be missing from the API
> > documentation (doc/*). Please send a patch for that.
>
> The function name is "GetMessagesListing" in spec.
> There is no doc as at the moment there is no apparams handling and no
> xml parsing, so I'll send patch with doc when we reach full
> functionality.
So the plan is to return something else than the raw XML that MAP
provides? In that case I don't think it's necessary to hold on to the
exact spec naming of these functions. E.g. GetMessages or GetMessageList
might make more sense in the case that you return a pre-parsed
list/structure of some kind.
Johan
Hi,
On Thu, Dec 15, 2011, Johan Hedberg wrote:
> On Thu, Dec 15, 2011, Bartosz Szatkowski wrote:
> > I've sent API before I've started to work on patches - only Luiz
> > responded, and there was discussion on other matters ...
>
> It seems I've forgotten to apply the API patch then. Can you point me to
> the email subject so we can get this into the tree?
Nevermind. I noticed from your other email that there's no such patch
(yet).
Johan
Hi Bartosz,
On Thu, Dec 15, 2011, Bartosz Szatkowski wrote:
> I've sent API before I've started to work on patches - only Luiz
> responded, and there was discussion on other matters ...
It seems I've forgotten to apply the API patch then. Can you point me to
the email subject so we can get this into the tree?
Johan
On Thu, Dec 15, 2011 at 12:54 PM, Johan Hedberg <[email protected]> wrote:
> Hi,
>
> On Thu, Dec 15, 2011, Johan Hedberg wrote:
>> On Mon, Dec 12, 2011, Bartosz Szatkowski wrote:
>> > + { "GetMessagesListing", "sa{ss}", "s", map_get_messages_listing,
>> > + G_DBUS_METHOD_FLAG_ASYNC },
>>
>> The name should be GetMessageListing and not GetMessagesListing (the
>> latter isn't really proper english).
>
> And now I notice that the spec. actually uses the plural form (which
> still sounds to me like strange English). All this fuss could have been
> avoided if we had had a proper discussion of the API beforehand and had
> the documentation in place before these patches.
>
> Johan
I've sent API before I've started to work on patches - only Luiz
responded, and there was discussion on other matters ...
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
On Thu, Dec 15, 2011 at 12:50 PM, Johan Hedberg <[email protected]> wrote:
> Hi Bartosz,
>
> On Mon, Dec 12, 2011, Bartosz Szatkowski wrote:
>> + { "GetMessagesListing", "sa{ss}", "s", map_get_messages_listing,
>> + G_DBUS_METHOD_FLAG_ASYNC },
>
> The name should be GetMessageListing and not GetMessagesListing (the
> latter isn't really proper english). I went ahead and changed it through
> a separate patch since I didn't notice before having already applied
> your patch. Also, all this seems to be missing from the API
> documentation (doc/*). Please send a patch for that.
The function name is "GetMessagesListing" in spec.
There is no doc as at the moment there is no apparams handling and no
xml parsing, so I'll send patch with doc when we reach full
functionality.
--
Pozdrowienia - Cheers,
Bartosz Szatkowski
Hi,
On Thu, Dec 15, 2011, Johan Hedberg wrote:
> On Mon, Dec 12, 2011, Bartosz Szatkowski wrote:
> > + { "GetMessagesListing", "sa{ss}", "s", map_get_messages_listing,
> > + G_DBUS_METHOD_FLAG_ASYNC },
>
> The name should be GetMessageListing and not GetMessagesListing (the
> latter isn't really proper english).
And now I notice that the spec. actually uses the plural form (which
still sounds to me like strange English). All this fuss could have been
avoided if we had had a proper discussion of the API beforehand and had
the documentation in place before these patches.
Johan
Hi Bartosz,
On Mon, Dec 12, 2011, Bartosz Szatkowski wrote:
> + { "GetMessagesListing", "sa{ss}", "s", map_get_messages_listing,
> + G_DBUS_METHOD_FLAG_ASYNC },
The name should be GetMessageListing and not GetMessagesListing (the
latter isn't really proper english). I went ahead and changed it through
a separate patch since I didn't notice before having already applied
your patch. Also, all this seems to be missing from the API
documentation (doc/*). Please send a patch for that.
Johan
Hi Bartosz,
On Mon, Dec 12, 2011, Bartosz Szatkowski wrote:
> ---
> client/map.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> doc/client-api.txt | 5 +++-
> 2 files changed, 60 insertions(+), 1 deletions(-)
All four patches have been applied. Thanks.
Johan
Just basic functionality for now, returning whole listing as a string
(no parsing) and no apparams handling.
---
client/map.c | 30 ++++++++++++++++++++++++++++++
test/map-client | 5 +++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/client/map.c b/client/map.c
index 0511e4c..f37a8b6 100644
--- a/client/map.c
+++ b/client/map.c
@@ -153,11 +153,41 @@ static DBusMessage *map_get_folder_listing(DBusConnection *connection,
return NULL;
}
+static DBusMessage *map_get_messages_listing(DBusConnection *connection,
+ DBusMessage *message, void *user_data)
+{
+ struct map_data *map = user_data;
+ int err;
+ const char *folder;
+ DBusMessageIter msg_iter;
+
+ dbus_message_iter_init(message, &msg_iter);
+
+ if (dbus_message_iter_get_arg_type(&msg_iter) != DBUS_TYPE_STRING)
+ return g_dbus_create_error(message,
+ "org.openobex.Error.InvalidArguments", NULL);
+
+ dbus_message_iter_get_basic(&msg_iter, &folder);
+
+ err = obc_session_get(map->session, "x-bt/MAP-msg-listing", folder,
+ NULL, NULL, 0,
+ buffer_cb, map);
+ if (err < 0)
+ return g_dbus_create_error(message, "org.openobex.Error.Failed",
+ NULL);
+
+ map->msg = dbus_message_ref(message);
+
+ return NULL;
+}
+
static GDBusMethodTable map_methods[] = {
{ "SetFolder", "s", "", map_setpath,
G_DBUS_METHOD_FLAG_ASYNC },
{ "GetFolderListing", "a{ss}", "s", map_get_folder_listing,
G_DBUS_METHOD_FLAG_ASYNC },
+ { "GetMessagesListing", "sa{ss}", "s", map_get_messages_listing,
+ G_DBUS_METHOD_FLAG_ASYNC },
{ }
};
diff --git a/test/map-client b/test/map-client
index bcd2e66..1a4afdb 100755
--- a/test/map-client
+++ b/test/map-client
@@ -14,6 +14,8 @@ def parse_options():
parser.add_option("-l", "--lsdir", action="store_true", dest="ls_dir",
help="List folders in current directory")
parser.add_option("-v", "--verbose", action="store_true", dest="verbose")
+ parser.add_option("-L", "--lsmsg", action="store", dest="ls_msg",
+ help="List messages in supplied CWD subdir")
return parser.parse_args()
@@ -54,4 +56,7 @@ if __name__ == '__main__':
if options.ls_dir:
print map.GetFolderListing(dict())
+ if options.ls_msg is not None:
+ print map.GetMessagesListing(options.ls_msg, dict())
+
mainloop.run()
--
1.7.4.1
---
Makefile.am | 3 ++-
test/map-client | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletions(-)
create mode 100755 test/map-client
diff --git a/Makefile.am b/Makefile.am
index c371f8a..f65a3dc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -9,7 +9,8 @@ doc_files = doc/obexd-api.txt doc/agent-api.txt doc/client-api.txt
test_files = test/simple-agent test/send-files \
test/pull-business-card test/exchange-business-cards \
- test/list-folders test/pbap-client test/ftp-client
+ test/list-folders test/pbap-client test/ftp-client \
+ test/map-client
gdbus_sources = gdbus/gdbus.h gdbus/mainloop.c gdbus/watch.c \
gdbus/object.c gdbus/polkit.c
diff --git a/test/map-client b/test/map-client
new file mode 100755
index 0000000..5ee4331
--- /dev/null
+++ b/test/map-client
@@ -0,0 +1,52 @@
+#!/usr/bin/python
+
+import gobject
+
+import dbus
+import dbus.mainloop.glib
+from optparse import OptionParser
+
+def parse_options():
+ parser.add_option("-d", "--device", dest="device",
+ help="Device to connect", metavar="DEVICE")
+ parser.add_option("-c", "--chdir", dest="new_dir",
+ help="Change current directory to DIR", metavar="DIR")
+ parser.add_option("-v", "--verbose", action="store_true", dest="verbose")
+
+ return parser.parse_args()
+
+def set_folder(session, new_dir):
+ for node in new_dir.split("/"):
+ session.SetFolder(node)
+
+if __name__ == '__main__':
+
+ dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
+
+ parser = OptionParser()
+
+ (options, args) = parse_options()
+
+ if not options.device:
+ parser.print_help()
+ exit(0)
+
+ bus = dbus.SessionBus()
+ mainloop = gobject.MainLoop()
+
+ client = dbus.Interface(bus.get_object("org.openobex.client", "/"),
+ "org.openobex.Client")
+
+ session_path = client.CreateSession({ "Destination": options.device,
+ "Target": "map"})
+
+ session = dbus.Interface(bus.get_object("org.openobex.client", session_path),
+ "org.openobex.Session")
+
+ map = dbus.Interface(bus.get_object("org.openobex.client", session_path),
+ "org.openobex.MessageAccess")
+
+ if options.new_dir:
+ set_folder(map, options.new_dir)
+
+ mainloop.run()
--
1.7.4.1
For now just basic functionality - returning whole listing as a string
(no parsing for now) and no apparams handling.
---
client/map.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
test/map-client | 5 +++++
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/client/map.c b/client/map.c
index 51a7711..0511e4c 100644
--- a/client/map.c
+++ b/client/map.c
@@ -104,8 +104,60 @@ static DBusMessage *map_setpath(DBusConnection *connection,
return NULL;
}
+static void buffer_cb(struct obc_session *session, GError *err,
+ void *user_data)
+{
+ struct obc_transfer *transfer = obc_session_get_transfer(session);
+ struct map_data *map = user_data;
+ DBusMessage *reply;
+ const char *buf;
+ int size;
+
+ if (err != NULL) {
+ reply = g_dbus_create_error(map->msg,
+ "org.openobex.Error.Failed",
+ "%s", err->message);
+ goto done;
+ }
+
+ buf = obc_transfer_get_buffer(transfer, &size);
+ if (size == 0)
+ buf = "";
+
+ reply = g_dbus_create_reply(map->msg, DBUS_TYPE_STRING, &buf,
+ DBUS_TYPE_INVALID);
+
+ obc_transfer_clear_buffer(transfer);
+
+done:
+ g_dbus_send_message(conn, reply);
+ dbus_message_unref(map->msg);
+ obc_transfer_unregister(transfer);
+}
+
+static DBusMessage *map_get_folder_listing(DBusConnection *connection,
+ DBusMessage *message, void *user_data)
+{
+ struct map_data *map = user_data;
+ int err;
+
+ err = obc_session_get(map->session, "x-obex/folder-listing",
+ NULL, NULL, NULL, 0,
+ buffer_cb, map);
+ if (err < 0)
+ return g_dbus_create_error(message, "org.openobex.Error.Failed",
+ NULL);
+
+ map->msg = dbus_message_ref(message);
+
+ return NULL;
+}
+
static GDBusMethodTable map_methods[] = {
- { "SetFolder", "s", "", map_setpath, G_DBUS_METHOD_FLAG_ASYNC },
+ { "SetFolder", "s", "", map_setpath,
+ G_DBUS_METHOD_FLAG_ASYNC },
+ { "GetFolderListing", "a{ss}", "s", map_get_folder_listing,
+ G_DBUS_METHOD_FLAG_ASYNC },
{ }
};
diff --git a/test/map-client b/test/map-client
index 5ee4331..bcd2e66 100755
--- a/test/map-client
+++ b/test/map-client
@@ -11,6 +11,8 @@ def parse_options():
help="Device to connect", metavar="DEVICE")
parser.add_option("-c", "--chdir", dest="new_dir",
help="Change current directory to DIR", metavar="DIR")
+ parser.add_option("-l", "--lsdir", action="store_true", dest="ls_dir",
+ help="List folders in current directory")
parser.add_option("-v", "--verbose", action="store_true", dest="verbose")
return parser.parse_args()
@@ -49,4 +51,7 @@ if __name__ == '__main__':
if options.new_dir:
set_folder(map, options.new_dir)
+ if options.ls_dir:
+ print map.GetFolderListing(dict())
+
mainloop.run()
--
1.7.4.1
On Wed, Jun 6, 2012 at 9:14 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Bartosz,
>
> On Thu, Dec 15, 2011 at 2:45 PM, Bartosz Szatkowski <[email protected]> wrote:
>>>
>>> So the plan is to return something else than the raw XML that MAP
>>> provides? In that case I don't think it's necessary to hold on to the
>>> exact spec naming of these functions. E.g. GetMessages or GetMessageList
>>> might make more sense in the case that you return a pre-parsed
>>> list/structure of some kind.
>>>
>>> Johan
>>
>> We planned to return dict {field: value}. Generally I don't care much
>> about this name - we can go with GetMessageListing, as I seem to use
>> both forms without noticing it anyway.
>
> Are there still plans to continue this work? I would like to change
> this method to return a dictionary like we do for pbap and perhaps
> unify this in a single listing so we do folder + messages.
>
>
> --
> Luiz Augusto von Dentz
Hi Luiz,
since January I'm not longer Comarch employee - so you probably should
ask Sławek/Radek/Łukasz whether they're planing to continue work on
it.
--
Cheers,
Bartosz Szatkowski
Hi Bartosz,
On Thu, Dec 15, 2011 at 2:45 PM, Bartosz Szatkowski <[email protected]> wrote:
>>
>> So the plan is to return something else than the raw XML that MAP
>> provides? In that case I don't think it's necessary to hold on to the
>> exact spec naming of these functions. E.g. GetMessages or GetMessageList
>> might make more sense in the case that you return a pre-parsed
>> list/structure of some kind.
>>
>> Johan
>
> We planned to return dict {field: value}. Generally I don't care much
> about this name - we can go with GetMessageListing, as I seem to use
> both forms without noticing it anyway.
Are there still plans to continue this work? I would like to change
this method to return a dictionary like we do for pbap and perhaps
unify this in a single listing so we do folder + messages.
--
Luiz Augusto von Dentz