webadmin-devel

Webmin RPC

[Wil C. <wc...@na...>]

I've been thinking about it a bit lately and wanted to know what
anyone else thought about this: Webmin uses a "proprietary" RPC
mechanism (I say "proprietary" because it's not really a standard;
not because it's locked away by copyright or whatnot) and was
wondering if it might not be possible or desirable to re-work the
HTML-RPC mechanism to use a "standardized" XML-RPC mechanism.
There are Perl modules (and modules for other languages) for
developing XML-RPC clients and servers; so it might be nice to be
able to develop client-applications or non-Webmin-integrated web
applications using the interface.  Has anyone else considered this
or agree with me?

Wil
--=20
W. Reilly Cooley                           wc...@na...
Naked Ape Consulting                        http://nakedape.cc
irc.linux.com                                     #orlug,#lnxs

The older I grow, the more I distrust the familiar doctrine that age
brings wisdom.
		-- H.L. Mencken

Re: Webmin RPC

[Joe C. <jo...@sw...>]

The two pence version:

I am of two minds on things like this.  On one hand, using standardized 
and heavier protocols (heavier merely in the sense of the implementation 
of the protocol--not necessarily that the communications are heavier or 
more taxing on the network or the machines) leads to Webmin being less 
'standalone'.  It will need other perl modules--against the Webmin 
rules, generally.  On the other hand, it would allow integration of 
Webmin with things that may not be 'Webmin-ified'...and potentially 
leverage existing development efforts in Webmin into less redundant 
efforts.  Modules save time--I use them all the time in my perl 
programming and I really couldn't be very productive without them (I'm a 
rank amateur at many complex Perl topics).

The longer version:

I am constanty torn between this dichotomy in general--not just the 
specific RPC case.  The problem of, balancing code reuse with Webmin 
usability.  If Webmin used a standard web template system (TT2, etc.) 
the GUI could break free of the constraints of the current 
half-templated and half-hardcoded system, but then everyone has to 
install TT2 before using Webmin.  Integration is difficult if not 
impossible, and that extra labor takes away a primary motivation for 
code reuse (i.e. saving Jamie from having to spend time developing a 
template system or an RPC system or whatever).

The negatives (the primary one being, everyone has to install a bunch of 
extra perl modules) don't bother me in the least.  Me and cpanflute got 
this deal going--anything from CPAN that I can build without any hassle 
I can make a package that goes into my default system kickstart install 
in a matter of minutes.  Maybe this isn't a deal casual users are 
willing to make.  So I would happily encourage Jamie to make Webmin less 
standalone, if it will add functionality, flexibility, and give Jamie 
more time that would have been spent reinventing wheels.  I'd probably 
make enemies of Webmin users, though...

That said, XML-RPC is one of those that might just be a no-brainer.  It 
would be transparent to folks doing casual Webmin work (i.e. they only 
work directly on a single machine) and would give those of us with 
nerdier tendencies a standardized way to link into a variety of systems. 
  There will probably still be a few folks for whom this would be a 
negative--folks doing embedded installs of Webmin, perhaps?  But they've 
got to strip Webmin to the bone anyway, so this wouldn't be any major 
hurdle for them, I wouldn't think.

So, the summary: I don't know.  I can't make up my mind.  I enjoy 
ranting about it from both sides.

Wil Cooley wrote:
> I've been thinking about it a bit lately and wanted to know what
> anyone else thought about this: Webmin uses a "proprietary" RPC
> mechanism (I say "proprietary" because it's not really a standard;
> not because it's locked away by copyright or whatnot) and was
> wondering if it might not be possible or desirable to re-work the
> HTML-RPC mechanism to use a "standardized" XML-RPC mechanism.
> There are Perl modules (and modules for other languages) for
> developing XML-RPC clients and servers; so it might be nice to be
> able to develop client-applications or non-Webmin-integrated web
> applications using the interface.  Has anyone else considered this
> or agree with me?
> 
> Wil
-- 
Joe Cooper <jo...@sw...>
http://www.swelltech.com
Web Caching Appliances and Support

Re: Webmin RPC

[Jamie C. <jca...@we...>]

The need for extra modules is part of the reason for not using XML-RPC,
but another is that (as far as I know) it doesn't support the passing
of complex structures as parameters or return values. Because many of
the remote webmin functions pass or return arrays and hashes, the lack
of structures really rules out XML-RPC, which only supports simple
types like strings and numbers.

Correct me if I am wrong about this though, because it probably wouldn't
be too hard to add some kind of gateway between XML-RPC and Webmin RPC
if they both have the same capabilities ..

 - Jamie

Joe Cooper wrote:
> 
> The two pence version:
> 
> I am of two minds on things like this.  On one hand, using standardized
> and heavier protocols (heavier merely in the sense of the implementation
> of the protocol--not necessarily that the communications are heavier or
> more taxing on the network or the machines) leads to Webmin being less
> 'standalone'.  It will need other perl modules--against the Webmin
> rules, generally.  On the other hand, it would allow integration of
> Webmin with things that may not be 'Webmin-ified'...and potentially
> leverage existing development efforts in Webmin into less redundant
> efforts.  Modules save time--I use them all the time in my perl
> programming and I really couldn't be very productive without them (I'm a
> rank amateur at many complex Perl topics).
> 
> The longer version:
> 
> I am constanty torn between this dichotomy in general--not just the
> specific RPC case.  The problem of, balancing code reuse with Webmin
> usability.  If Webmin used a standard web template system (TT2, etc.)
> the GUI could break free of the constraints of the current
> half-templated and half-hardcoded system, but then everyone has to
> install TT2 before using Webmin.  Integration is difficult if not
> impossible, and that extra labor takes away a primary motivation for
> code reuse (i.e. saving Jamie from having to spend time developing a
> template system or an RPC system or whatever).
> 
> The negatives (the primary one being, everyone has to install a bunch of
> extra perl modules) don't bother me in the least.  Me and cpanflute got
> this deal going--anything from CPAN that I can build without any hassle
> I can make a package that goes into my default system kickstart install
> in a matter of minutes.  Maybe this isn't a deal casual users are
> willing to make.  So I would happily encourage Jamie to make Webmin less
> standalone, if it will add functionality, flexibility, and give Jamie
> more time that would have been spent reinventing wheels.  I'd probably
> make enemies of Webmin users, though...
> 
> That said, XML-RPC is one of those that might just be a no-brainer.  It
> would be transparent to folks doing casual Webmin work (i.e. they only
> work directly on a single machine) and would give those of us with
> nerdier tendencies a standardized way to link into a variety of systems.
>   There will probably still be a few folks for whom this would be a
> negative--folks doing embedded installs of Webmin, perhaps?  But they've
> got to strip Webmin to the bone anyway, so this wouldn't be any major
> hurdle for them, I wouldn't think.
> 
> So, the summary: I don't know.  I can't make up my mind.  I enjoy
> ranting about it from both sides.
> 
> Wil Cooley wrote:
> > I've been thinking about it a bit lately and wanted to know what
> > anyone else thought about this: Webmin uses a "proprietary" RPC
> > mechanism (I say "proprietary" because it's not really a standard;
> > not because it's locked away by copyright or whatnot) and was
> > wondering if it might not be possible or desirable to re-work the
> > HTML-RPC mechanism to use a "standardized" XML-RPC mechanism.
> > There are Perl modules (and modules for other languages) for
> > developing XML-RPC clients and servers; so it might be nice to be
> > able to develop client-applications or non-Webmin-integrated web
> > applications using the interface.  Has anyone else considered this
> > or agree with me?
> >
> > Wil

Re: Webmin RPC

[Wil C. <wc...@na...>]

Also Sprach Jamie Cameron <jca...@we...> on Mon, Mar 18, 2002 at 05:=
39:14PM PST
> The need for extra modules is part of the reason for not using XML-RPC,
> but another is that (as far as I know) it doesn't support the passing
> of complex structures as parameters or return values. Because many of
> the remote webmin functions pass or return arrays and hashes, the lack
> of structures really rules out XML-RPC, which only supports simple
> types like strings and numbers.
>=20
> Correct me if I am wrong about this though, because it probably wouldn't
> be too hard to add some kind of gateway between XML-RPC and Webmin RPC
> if they both have the same capabilities ..

I've been thinking more about this, and the complex
datastructures should pose no problem.  I did a little
looking around my Perl installation (including CPAN modules
RH shipped) and found XML::Dumper, which will take a Perl
structure and output XML.  Here's an example from the man
page:

#!/usr/bin/perl

# Convert Perl code to XML
use XML::Dumper;
my $dump =3D new XML::Dumper;
$data =3D [
          {
            first =3D> 'Jonathan',
            last =3D> 'Eisenzopf',
            email =3D> 'ei...@po...'
          },
          {
            first =3D> 'Larry',
            last =3D> 'Wall',
            email =3D> ' la...@wa...'
          }
         ];
$xml =3D $dump->pl2xml($data);

print $xml, "\n" ;

# EOF

Which produces:

<perldata>
 <array>
  <item key=3D"0">
   <hash>
    <item key=3D"last">Eisenzopf</item>
    <item key=3D"first">Jonathan</item>
    <item key=3D"email">ei...@po...</item>
   </hash>
  </item>
  <item key=3D"1">
   <hash>
    <item key=3D"last">Wall</item>
    <item key=3D"first">Larry</item>
    <item key=3D"email"> la...@wa...</item>
   </hash>
  </item>
 </array>
</perldata>


Viol=E1!

Wil
--=20
W. Reilly Cooley                           wc...@na...
Naked Ape Consulting                        http://nakedape.cc
irc.linux.com                                     #orlug,#lnxs

"There was a vague, unpleasant manginess about his appearence; he somehow
seemed dirty, though a close glance showed him as carefully shaven as an
actor, and clad in immaculate linen."
-- H.L. Mencken, on the death of William Jennings Bryan

Re: Webmin RPC

[Jamie C. <jca...@we...>]

Wil Cooley wrote:
> 
> Also Sprach Jamie Cameron <jca...@we...> on Mon, Mar 18, 2002 at 05:39:14PM PST
> > The need for extra modules is part of the reason for not using XML-RPC,
> > but another is that (as far as I know) it doesn't support the passing
> > of complex structures as parameters or return values. Because many of
> > the remote webmin functions pass or return arrays and hashes, the lack
> > of structures really rules out XML-RPC, which only supports simple
> > types like strings and numbers.
> >
> > Correct me if I am wrong about this though, because it probably wouldn't
> > be too hard to add some kind of gateway between XML-RPC and Webmin RPC
> > if they both have the same capabilities ..
> 
> I've been thinking more about this, and the complex
> datastructures should pose no problem.  I did a little
> looking around my Perl installation (including CPAN modules
> RH shipped) and found XML::Dumper, which will take a Perl
> structure and output XML.  Here's an example from the man
> page:
> 
> #!/usr/bin/perl
> 
> # Convert Perl code to XML
> use XML::Dumper;
> my $dump = new XML::Dumper;
> $data = [
>           {
>             first => 'Jonathan',
>             last => 'Eisenzopf',
>             email => 'ei...@po...'
>           },
>           {
>             first => 'Larry',
>             last => 'Wall',
>             email => ' la...@wa...'
>           }
>          ];
> $xml = $dump->pl2xml($data);
> 
> print $xml, "\n" ;
> 
> # EOF
> 
> Which produces:
> 
> <perldata>
>  <array>
>   <item key="0">
>    <hash>
>     <item key="last">Eisenzopf</item>
>     <item key="first">Jonathan</item>
>     <item key="email">ei...@po...</item>
>    </hash>
>   </item>
>   <item key="1">
>    <hash>
>     <item key="last">Wall</item>
>     <item key="first">Larry</item>
>     <item key="email"> la...@wa...</item>
>    </hash>
>   </item>
>  </array>
> </perldata>
> 
> Violá!

That's a good solution .. as long as callers are willing to
convert all structures into this format, then I can't see any
problems with it.  What someone needs to do is write a gateway
of some kind between webmin-RPC and XML-RPC .. or even add
XML-RPC support directly to webmin. I wouldn't want to get rid
of the existing RPC right away, in order to preserve backwards
compatibility, but there is no reason why they both cannot
exist side-by-side.

What kind of network transport does XML-RPC use? Does it make
an HTTP connection for each function call, or use some other
special protocol?

 - Jamie

Re: Webmin RPC

[Wil C. <wc...@na...>]

Also Sprach Jamie Cameron <jca...@we...> on Tue, Mar 26, 2002 at 09:=
26:06PM PST
>=20
> That's a good solution .. as long as callers are willing to
> convert all structures into this format, then I can't see any
> problems with it.  What someone needs to do is write a gateway
> of some kind between webmin-RPC and XML-RPC .. or even add
> XML-RPC support directly to webmin. I wouldn't want to get rid
> of the existing RPC right away, in order to preserve backwards
> compatibility, but there is no reason why they both cannot
> exist side-by-side.

Well, that's the thing--they don't have to; the conversions can be
made within the remote_foreign_* calls and be done transparently
to the modules.  I'm sorta interested in this issue, and if my
schedule allows it, I'll take a hack it at.

> What kind of network transport does XML-RPC use? Does it make
> an HTTP connection for each function call, or use some other
> special protocol?

It uses HTTP to transfer the XML back and forth; it's a lot like
SOAP AFAICT.  I need to read up on it a bit.

Wil
--=20
W. Reilly Cooley                           wc...@na...
Naked Ape Consulting                        http://nakedape.cc
irc.linux.com                                     #orlug,#lnxs

"There was a vague, unpleasant manginess about his appearence; he somehow
seemed dirty, though a close glance showed him as carefully shaven as an
actor, and clad in immaculate linen."
-- H.L. Mencken, on the death of William Jennings Bryan