-----Original Message-----
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Clark Williams
Sent: Monday, June 26, 2006 1:52 PM
To: Discussion of Fedora build system
Subject: Re: New version of mock working (I think)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael_E_Brown(a)Dell.com wrote:
>>
>> Does it really have to be a server? Could it be a push
rather than a
>> poll? Mock could make xml-rpc calls to whatever wraps around it.
>
> Just catching up on weekend traffic here. XMLRPC is a great idea. I
> have implemented several xmlrpc servers in the past, and this is an
> idea that could work out well. Given the nature of mock, it would
> probably be best if it made calls into plague, rather than
the other
> way around, but it wouldn't be _too_ much overhead to have a server
> that could be polled for status.
>
> I have mock hacking on my todo list for this week, so after
I finish
> catching up with list traffic and get the latest prototype
downloaded
> and building, I'll take a look at this.
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