qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 09/25] python/aqmp: add AsyncProtocol.accept() method


From: Eric Blake
Subject: Re: [PATCH v3 09/25] python/aqmp: add AsyncProtocol.accept() method
Date: Thu, 19 Aug 2021 09:50:09 -0500
User-agent: NeoMutt/20210205-732-28786f

On Wed, Aug 18, 2021 at 10:24:52AM -0400, John Snow wrote:
> > >
> > > +    @upper_half
> > > +    @require(Runstate.IDLE)
> > > +    async def accept(self, address: Union[str, Tuple[str, int]],
> > > +                     ssl: Optional[SSLContext] = None) -> None:
> > > +        """
> > > +        Accept a connection and begin processing message queues.
> > > +
> > > +        If this call fails, `runstate` is guaranteed to be set back to
> > `IDLE`.
> > > +
> > > +        :param address:
> > > +            Address to listen to; UNIX socket path or TCP address/port.
> >
> > Can't TCP use a well-known port name instead of an int?  But limiting
> > clients to just int port for now isn't fatal to the patch.
> >
> >
> The old QMP library didn't support this, and I used the old library as my
> template here. I'm willing to change the address format and types to be
> more comprehensive, but I was thinking that it should probably try to match
> or adhere to some standard; de-facto or otherwise. I wasn't sure which to
> pick, and we use a few different ones in QEMU itself. Any recommendations
> for me?

I asked because I know QAPI specifies TCP as string/string (the
hostname as a string makes absolute sense, but the port number as a
string is because of the less-used feature of a well-known port name).
I'm fine if the initial patch uses an int for the port number here; we
can always add support for more formats down the road when someone
actually has a use for them.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]