On Sun, Jun 13, 2021 at 09:17:44PM +0200, Mischa wrote:
> On 13 Jun at 20:45, Andrew Hewus Fresh <andrew@afresh1.com> wrote:
> > On Sun, Jun 13, 2021 at 03:40:22PM +0200, Mischa wrote:
> > > This module implement JSON-RPC 2.0 protocol in transport-independent
> > > way.
> > >
> > > Also it support non-blocking client remote procedure call and both
> > > blocking and non-blocking server method execution. This can be very
> > > useful in case server methods will need to do some RPC or other
> > > slow things like network I/O, which can be done in parallel with
> > > executing other server methods in any event-based environment.
> > >
> > > meta::cpan: https://metacpan.org/pod/JSON::RPC2
> > >
> > > JSON RPC is for example needed to use the eAPI from Arista.
> > >
> > > Any comments / suggestions welcome!
> >
> > Most of the other JSON perl modules are in converters, not devel. This
> > one should probably go there as well.
>
> That was my first instict as well, until I checked some of the other
> JSON RPC packages and they are all in devel, so was a little
> conflicted. Using converters now as it does make more sense considering
> the other JSON Perl modules.
Well, the perl RPC ports I see are in net/, so not really sure where
the best place is. Perhaps someone else will chime in.
I might recommend that you add yourself as MAINTAINER, but that's not
necessary.
<SNIP>
> New tgz attached.
I'm not sure about the DESCR, might be better with the second paragraph
as well, or more specifically exactly what you included above.
If someone else has an opinion, mine aren't strongly held on either of
those points and we can go with theirs.
OK afresh1@ whichever way those two things go, if someone wants to
decide and commit.
l8rZ,
--
andrew - http://afresh1.com
Speed matters.
Almost as much as some things, and nowhere near as much as others.
-- Nick Holland
No comments:
Post a Comment