> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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
>
> [EMAIL PROTECTED] 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
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
