Michael DeHaan wrote:
http://qpid.apache.org/qmf-python-console-tutorial.html
It does sync, async, routing (like our delegation), publish/subscribe
type things, and offline delivery. I think the plan is to rely on
kerberos for security though, but perhaps you could also use certmaster.
Func-over-QMF, anyone? (I know we talked about AMQP earlier, this is
a level above).
I think Func's interest in the API, so the transport (and even
certmaster) may not be critical. Perhaps it could do both.
I'm kind of undecided on this. I've thought about trying to transition
func to use some sort of message broker
protocol like AMPQ or stomp. It has a nice feature that it would help
get rid of some of the more complicated
aspects of func (async, delegation, etc) that we've bolted around
xml-rpc. I wouldn't mind if that complexity became someone else's
problem myself.
I'm concerned about how authentication and session encryption would work
though. My previous attempts to
use AMQP for this sort of thing ran into issues with integrating SSL
like auth into it.
I'd rather not have to rely on kerberos. Just doesn't seem like it fits
well in the circumstance people tend to use
func.
QMF seems to provide alot of nice abstractions over the rather raw AMQP
protocol/api that would make an
implementation more pleasant.
Another concern I had was about the xml-rpc interface going away. Since
exposing an xmlrpc api for systems management was one of the goals of
func. With other clients being able to talk to and use that API.
Unfortunately, I don't think that is actually a common use case at this
point. It seems like everything either uses the python overlord API or
func-transmit. The SSL layer is probably part of the reason (it seems
somewhat difficult to properly implement all the ssl bit we require to
talk to funcd). So the xml-rpc api is not a huge win at this point.
Adrian
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
