all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daiki Ueno <ueno@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 20193@debbugs.gnu.org
Subject: bug#20193: 25.0.50; declarative type specification for D-Bus args
Date: Fri, 27 Mar 2015 16:29:22 +0900	[thread overview]
Message-ID: <m38ueiaofh.fsf-ueno@gnu.org> (raw)
In-Reply-To: <87bnjgat6z.fsf@gmx.de> (Michael Albinus's message of "Thu, 26 Mar 2015 12:34:12 +0100")

Michael Albinus <michael.albinus@gmx.de> writes:

> In the early design phase of dbus.el I have played with explicit
> signatures for the arguments, like
>
>   (dbus-call-method :session
>                     "org.example.Foo"
>                     "/org/example/Foo"
>                     "org.example.Foo"
>                     "Test"
>                     :signature "a{si}"
>                     '(("a" 1) ("b" 2)))
>
> which is similar to your proposal, with other means. I haven't
> implemented it, because I found it to strict for Lisp developers to
> think in D-Bus signatures. It has only survived for marking the type of
> an empty array.
>
> Your proposal is closer to the developers, so it has charm. There is
> also a minor difference how dict entries are expressed, but that could
> be agreed. So I'm open to this, as an *alternative* option to the
> existing spec. We don't want to break existing code.

Certainly.  Do you have any preference on the alternative form?  My
example used the `:type' keyword, but it was a tentative plan and might
be too verbose for programmers.  Reusing `:signature' might be a better
idea as you mentioned (though it might be confusing with the current
meaning of `:signature' as a D-Bus type "g").

>> Would this kind of change be considered?  As a proof-of-concept, I'm
>> attaching a small Elisp snippet that augments the argument value with
>> the given type information (though I guess it should be implemented in
>> the C level, to avoid duplication of signature computation code).
>
> IIRC, this was another reason that I haven't followed the :signature
> approach - it was harder to implement in dbusbind.c. But this is years
> ago, maybe my memories are wrong.
>
> Yes, it shall be implemented in dbusbind.c - would you like to try it?

Sure.

> Btw, one of your examples is wrong (or at least misleading). An empty
> array must contain exactly one element of type signature. The case you
> have shown here indicates, that '(:array :signature "sig") is an array
> with exact one elemt, a signature. Although possible in D-Bus, this is
> not possible in dbus.el (maybe a design flaw?). Your example could be
> therefore changed to
>
> ;; (dbus--annotate-arg '(:struct :object-path (:array (:dict-entry
> string :int32)) :string)
> ;;                     '("path" nil "password"))
> ;; ;=> ((:struct :object-path "path" (:array :signature "{si}")
> :string "password"))
>
> This would require additional mapping of the type symbols to signature
> strings - something what exist in dbusbind.c already.

Oh, I see.  Thanks for the info.

Regards,
--
Daiki Ueno





  reply	other threads:[~2015-03-27  7:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25  3:31 bug#20193: 25.0.50; declarative type specification for D-Bus args Daiki Ueno
2015-03-26 11:34 ` Michael Albinus
2015-03-27  7:29   ` Daiki Ueno [this message]
2015-03-27  7:40     ` Michael Albinus
2015-08-27  9:23       ` Daiki Ueno
2015-08-28  7:31         ` Daiki Ueno
2015-08-28  8:22           ` Michael Albinus
2015-08-30 13:54           ` Michael Albinus
2015-09-02  7:24             ` Daiki Ueno
2015-09-02 14:06               ` Michael Albinus
2015-09-03  9:29                 ` Daiki Ueno
2015-09-03 10:07                   ` Michael Albinus
2015-09-04  2:33                     ` Daiki Ueno
2015-09-04  7:29                       ` Michael Albinus
2020-09-18 13:23                         ` Lars Ingebrigtsen
2020-09-24 13:17                           ` Michael Albinus
2015-09-03 16:08               ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m38ueiaofh.fsf-ueno@gnu.org \
    --to=ueno@gnu.org \
    --cc=20193@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.