New version of mock working (I think)

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael_E_Brown at 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-----