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