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