From: christian.babeux@efficios.com (Christian Babeux)
Subject: [lttng-dev] Machine Interface
Date: Thu, 6 Feb 2014 13:21:07 -0500 [thread overview]
Message-ID: <CAGDH53=c+H26t6Nk71cGHnqfgj-At_nv4kWO1ODr69YGp3icTQ@mail.gmail.com> (raw)
In-Reply-To: <20140206170038.GA30540@gmail.com>
> How about --machine-interface <output-type>?
> By default <output-type> would be the chosen format.
>
> This open opportunities for other MI type and have an unified syntax.
>
> --xml option is clear and efficient.We could
> add an option for each type (--json,--yaml) if needed.
IMO, supporting multiple output formats would be a tad bit overkill.
Moreover, the issue of bringing in additional library dependencies to
support multiple output format remains.
Thanks,
Christian
On Thu, Feb 6, 2014 at 12:00 PM, Jonathan Rajotte
<jonathan.r.julien at gmail.com> wrote:
> On Thu, Feb 06, 2014 at 11:11:39AM -0500, Christian Babeux wrote:
>> Hi Jonathan,
>>
>> > Multiples solutions come to mind:
>> > -XML
>> > -JSON
>> > -YAML
>> > -Custom syntax (like GDB Machine interface* as proposed by Alexandre
>> > Montplaisir)
>>
>> I would advocate for the use of XML for the machine interface. Two
>> reasons come to mind:
>>
>> 1 - The expression of hierarchy (session, events, etc.) is much easier with XML.
>>
>> 2 - In a recent post [1], it was decided that the configuration load
>> and restore (for sessions) would also use XML. This will introduce a
>> new dependency on libxml. If we were to choose yet another format for
>> the machine interface, we would probably need to introduce another
>> dependency to some library.
>
> Good point
> +1 for XML
>
>>
>> > Machine interface output would be generated only with --mi option and
>> > could contain additional information than regular output.
>>
>> Perhaps adding --xml option to the relevant command? This would be
>> similar to svn machine interface [2].
>
> How about --machine-interface <output-type>?
> By default <output-type> would be the chosen format.
>
> This open opportunities for other MI type and have an unified syntax.
>
> --xml option is clear and efficient.We could
> add an option for each type (--json,--yaml) if needed.
>
>>
>> Thanks,
>>
>> Christian
>>
>> [1] - http://lists.lttng.org/pipermail/lttng-dev/2013-December/022068.html
>> [2] - http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.sw
>>
>> On Wed, Feb 5, 2014 at 9:42 PM, Jonathan Rajotte
>> <jonathan.r.julien at gmail.com> wrote:
>> > Hello all,
>> >
>> > After speaking with Michel Dagenais, Genevi?ve Bastien, folks over at EfficiOs
>> > and Ericsson, a machine interface for lttng-tool would be a nice feature
>> > to have. Olivier Cotte and me will be working on MI for the
>> > next few weeks.
>> >
>> > The main objective would be to reduce parsing complexity
>> > in control tools.
>> > ex:Regex used in TMF control service.
>> > (org.eclipse.linuxtools.internal.lttng2.ui.views.control.service.LTTngControlService.java)
>> >
>> > Multiples solutions come to mind:
>> > -XML
>> > -JSON
>> > -YAML
>> > -Custom syntax (like GDB Machine interface* as proposed by Alexandre
>> > Montplaisir)
>> >
>> > XML/JSON/YAML promote extensibility and ease of development for new tools
>> > dependant on lttng-tools by being established standards.
>> > On the other hand, they add dependencies to lttng-tools where a custom syntax
>> > would not.
>> >
>> > Machine interface output would be generated only with --mi option and
>> > could contain additional information than regular output.
>> >
>> > We are focusing on output right now but we may eventually add a 'mi'
>> > command for input if necessary.
>> >
>> > What do you think ?
>> >
>> > Thanks
>> >
>> >
>> > *https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html
>> >
>> > --
>> > Jonathan Rajotte Julien
>> > Charg? de laboratoire INF1995
>> > Membre MD6
>> > Polytechnique Montr?al
>> >
>> > _______________________________________________
>> > lttng-dev mailing list
>> > lttng-dev at lists.lttng.org
>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> --
> Jonathan Rajotte Juliana
> Charg? de laboratoire INF1995
> Membre MD6
> Polytechnique Montr?al
next prev parent reply other threads:[~2014-02-06 18:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-06 2:42 Jonathan Rajotte
2014-02-06 7:41 ` Woegerer, Paul
2014-02-06 13:32 ` Simon Marchi
2014-02-06 17:07 ` Woegerer, Paul
2014-02-06 18:40 ` Simon Marchi
2014-02-06 16:11 ` Christian Babeux
2014-02-06 17:00 ` Jonathan Rajotte
2014-02-06 18:21 ` Christian Babeux [this message]
2014-02-06 13:51 Thibault, Daniel
2014-02-13 18:00 Olivier Cotte
2014-02-13 18:26 ` Simon Marchi
2014-02-13 19:16 ` Jonathan Rajotte
2014-02-13 20:05 Thibault, Daniel
2014-02-13 20:36 ` Jonathan Rajotte
2014-02-13 20:41 ` Thibault, Daniel
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='CAGDH53=c+H26t6Nk71cGHnqfgj-At_nv4kWO1ODr69YGp3icTQ@mail.gmail.com' \
--to=christian.babeux@efficios.com \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox