On 4/30/20 2:20 PM, Daniel Henrique Barboza wrote:
On 3/19/20 4:00 PM, Laine Stump wrote:
TL;DR - I'm not as anti-XML as the proposal seems to be, but also not
pro-XML. I also (after thinking about it) understand the advantage of
putting this in a separate library. So yeah, let's go it!
[...]
Anyway, in the end I think my opinion is we should push ahead and
think about consequences of the specifics later, after some
experimenting. I'd love to help if there's a place for it. I'm just
not sure where/how I could contribute, especially since I have only
about 4 hours worth of golang knowledge :-) (certainly not against
getting more though!)
I'll start writing some code here and there for this initiative. Does
anyone already started doing something? Otherwise I'll push code in
github/gitlab when I have stuff to show.
Since I've been involved with libvirt's PCI address assignment code for
quite a long time (and so there's a lot of knowledge about it embedded
in my brain) I *should be* starting to do something with
libvirt-devaddr, although I've been deliquent in asking danpb for more
specific direction - as I said before this is a completely new medium
for me, so I don't really know where to start.
Based on your enthusiasm, I'm guessing you have more experience than me
with using go and various go libraries, is that right? If so that could
be very helpful in getting it off the ground.
Here are two things that would help enable me to make useful contributions:
1) a basic "source tree for a go library" setup in a libvirt-subproject
on gitlab (since gitlab is the official location of libvirt projects
now), including basic commit and CI hooks/test cases. I'm guessing we
could borrow/steal a lot from what was done by the people who
participated in "virt-blocks" last fall. Andrea - any advice/suggestions
to give here?
(A side question - should we put it under the libvirt umbrella on gitlab
right away? Or play around in personal trees at first and then later
fork it into an official libvirt project?)
2) a more concrete idea of what the API should look like. This is always
the toughest part for me, since it is what the rest of the world sees,
so it needs to be intelligible and capable of expansion, and I have a
long history of making questionable choices that come back to haunt me
(and everybody else! :-P). Since danpb has made good decisions in this
area in the past (and since the original proposal is his), I'm
thinking/hoping he can help provide direction to minimize mis-steps (on
the other hand, I know he's really busy, so maybe he was just hoping
that someone else would grab up his proposal and run with it).
Once those things are agreed upon and mostly in place, I think it will
be more practical for multiple people to contribute, and in particular I
will be able to put my memories of the idiosyncracies of libvirt and its
PCI and other address allocation to better use (and hopefully I'll
become more familiar with go in the process).
My understanding from the discussions is that the API is going to supply
JSON responses instead of domxml (domXML might be supplied as an option,
but it wouldn't be the default format used). Is that correct?
I don't think there was any hard specification of the output format,
just that it doesn't need to be married to XML. I've tended to view the
current love affair with JSON as similar to 200x's love affair with XML,
so I don't have any assumption that it's the best choice, but if there's
nothing better, then I guess why not?
