Am 07.02.2020 um 22:23 hat John Snow geschrieben:
> On 2/6/20 9:21 AM, Kevin Wolf wrote:
> > I think this subthread shows that we actually have many separate
> > projects that people wish to have someone work on. Each of them is
> > probably a bit too small for a whole GSoC, but all of them
Am 08.02.2020 um 08:25 hat Markus Armbruster geschrieben:
> John Snow writes:
>
> > On 2/6/20 9:21 AM, Kevin Wolf wrote:
> [...]
> >> 2. Rewriting qmp-shell to use a better syntax for nested data
> >>structures. This would have to be defined before the project starts.
> >>
> >
> > ... Can't
Eric Blake writes:
> On 2/6/20 12:18 PM, Dr. David Alan Gilbert wrote:
>
>>>
>>> Pain points of JSON include having to count parenthesises and having to
>>> quote so bloody much. Additional QMP pain points include long names and
>>> excessive nesting.
>>
>> Some other pet hates:
>>a) Number
John Snow writes:
> On 2/6/20 9:21 AM, Kevin Wolf wrote:
[...]
>> 2. Rewriting qmp-shell to use a better syntax for nested data
>>structures. This would have to be defined before the project starts.
>>
>
> ... Can't start until we define the proper interface, because then we
> have to
John Snow writes:
> A note:
>
> qmp-shell could offer some sugared versions of things like "query-block"
> that do some work understanding the reply from QEMU and printing it in a
> nice human format.
This is exactly how HMP commands should work.
By moving them to qmp-shell, we get to code
On 2/6/20 1:18 PM, Dr. David Alan Gilbert wrote:
> But, for machine representations, I'm not sure moving away from JSON is
> a requirement.
This is not really on the table.
--js
On 2/6/20 12:18 PM, Dr. David Alan Gilbert wrote:
Pain points of JSON include having to count parenthesises and having to
quote so bloody much. Additional QMP pain points include long names and
excessive nesting.
Some other pet hates:
a) Number formats are awful for our uses
b) Lack
On 2/6/20 9:21 AM, Kevin Wolf wrote:
> Am 06.02.2020 um 10:40 hat Markus Armbruster geschrieben:
On 2/5/20 8:09 AM, Kevin Wolf wrote:
> Am 28.01.2020 um 11:59 hat Kevin Wolf geschrieben:
The other part that it needs to solve is how to be available by default
without
On 2/6/20 7:11 AM, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
>> On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
If the user screwsup, it should give an error that prompts the user
to the parameter they got wrong.
Output from commands should
On 2/6/20 4:40 AM, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" writes:
>
>> * John Snow (js...@redhat.com) wrote:
>>> I'm forking the subject as I believe Markus wanted to focus on the
>>> machine interface aspect.
>>>
>>> I feel that a new human interface is *related* to that goal:
Am 06.02.2020 um 19:26 hat Dr. David Alan Gilbert geschrieben:
> * Kevin Wolf (kw...@redhat.com) wrote:
> > Am 06.02.2020 um 10:40 hat Markus Armbruster geschrieben:
> > > >> On 2/5/20 8:09 AM, Kevin Wolf wrote:
> > > >> > Am 28.01.2020 um 11:59 hat Kevin Wolf geschrieben:
> > > >> The other
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
> That I wrote:
>> >
>> > I believe it should be a python shell with added commands.
>> >
>> > Simple things should be simple.
>> > e.g. adding a disk from a local file should be trivial.
>> >
>> > Complex
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 06.02.2020 um 10:40 hat Markus Armbruster geschrieben:
> > >> On 2/5/20 8:09 AM, Kevin Wolf wrote:
> > >> > Am 28.01.2020 um 11:59 hat Kevin Wolf geschrieben:
> > >> The other part that it needs to solve is how to be available by
> > >>
* Markus Armbruster (arm...@redhat.com) wrote:
That I wrote:
> >
> > I believe it should be a python shell with added commands.
> >
> > Simple things should be simple.
> > e.g. adding a disk from a local file should be trivial.
> >
> > Complex things can be complex - but it would be better if
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Feb 06, 2020 at 01:11:58PM +0100, Markus Armbruster wrote:
> > Daniel P. Berrangé writes:
> >
> > > On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
> > >> > If the user screwsup, it should give an error that prompts
Am 06.02.2020 um 10:40 hat Markus Armbruster geschrieben:
> >> On 2/5/20 8:09 AM, Kevin Wolf wrote:
> >> > Am 28.01.2020 um 11:59 hat Kevin Wolf geschrieben:
> >> The other part that it needs to solve is how to be available by
> >> default
> >> without specifying anything on the
On Thu, Feb 06, 2020 at 01:11:58PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
> >> > If the user screwsup, it should give an error that prompts the user
> >> > to the parameter they got wrong.
> >> >
> >>
Daniel P. Berrangé writes:
> On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
>> > If the user screwsup, it should give an error that prompts the user
>> > to the parameter they got wrong.
>> >
>> > Output from commands should normally be pretty formatted (with an option
>> >
On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
> > If the user screwsup, it should give an error that prompts the user
> > to the parameter they got wrong.
> >
> > Output from commands should normally be pretty formatted (with an option
> > to display raw json for those needing
"Dr. David Alan Gilbert" writes:
> * John Snow (js...@redhat.com) wrote:
>> I'm forking the subject as I believe Markus wanted to focus on the
>> machine interface aspect.
>>
>> I feel that a new human interface is *related* to that goal: the
>> splitting of, and commitment to, separate human
* John Snow (js...@redhat.com) wrote:
> I'm forking the subject as I believe Markus wanted to focus on the
> machine interface aspect.
>
> I feel that a new human interface is *related* to that goal: the
> splitting of, and commitment to, separate human and machine interfaces
> powered by a
21 matches
Mail list logo
