-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael_E_Brown(a)Dell.com wrote:
>
> Ugh. I get the feeling that this is a case of "Oooo shiny!".
>
> What benefit is it to mock to add either client or server RPC
> capabilities so that someone can determine mock's state? Are
> we talking about communicating something besides a string?
> XML-RPC works GREAT as a marshaling/unmarshaling mechanism to
> describe complex data structures. In this case however we're
> talking about telling someone that we're in the "prep" state,
> or in the "cache_unpack" state.
>
> If there is a wealth of information that we're not making
> available to the outside world (i.e. distributed build
> systems) then yeah, lets set up a series of remote procedure
> calls and publish them; I'll gladly work on client/server
> code in the mock codebase if it's justified. But if we're
> only changing state and not allowing the outside world to
> interact with us to change our behavior while building, then
> let's keep it simple.
It is simple, we can do an xmlrpc client in about 7 lines of code and
add it to the status() function. Here are all the lines that I can think
to add that would fully enable this:
In setup_default_config_opts():
config["status_server"] = None
In command_parse():
parser.add_option("--statusserver", action="store",
type="string",
dest="status_server",
default=None, help="server to contact for status info.")
In set_config_opts_per_cmdline():
if options.status_server is not None: config["status_server"] =
options.status_server
In state():
if self.config["status_server"]:
import xmlrpclib
server = xmlrpclib.Server(config["status_server"])
server.set_mock_status(some_string)
A server would probably take another 10-20 lines of code.
An additional argument could probably be made for shared mem or a named
pipe, but I havent coded those, so I don't know. As for simplicity,
another file descriptor pre-opened by plague, or a named pipe passed via
command line would probably be "simpler", but probably not in terms of
lines of code.
--
Michael
I can see I'm on the losing end of this argument. My first suggestion
would have been to use mmap to map the status file, but re-reading
Dan's email, my guess is that's not significantly different from
reading the file. And on the plus side, we can pass structured data
using XML-RPC, so that might "suck less" :).
Let me just state two things and then I'll shut up on this issue:
1. I think that adding XML-RPC has great potential to be a Pandora's
Box, in terms of potential code bloat. We need to be on guard to
avoid the "Now that we have XML-RPC, let's add this feature!". Please
remember that the intent behind mock is to rebuild an SRPM inside a
chroot. Everything else is secondary.
2. We need to hear from Dan as to whether the likes the idea. My guess
is he will since plague already has XML-RPC elements.
Clark "Back in my day we didn't need fancy XML-RPCs! We had DCE!"
Williams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org
iD8DBQFEoDlfHyuj/+TTEp0RAjfhAKCeX6yfVFTudHZ9ox1JTU4vwLXGWgCggQbu
vOpb6nSP6QQJgK4jCd4tvk0=
=0Wvu
-----END PGP SIGNATURE-----