New version of mock working (I think)

[Clark Williams]

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

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

Clark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEoCznHyuj/+TTEp0RAptnAKCaXCE2IAF7W/M8beGRkJQw+aajgQCg2jw4
U5Z6cwHzbLGQWcoZZuALPNc=
=rYkJ
-----END PGP SIGNATURE-----