Re: [Xen-devel] Using the C library

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> It probably should be under /var/run since it is something that is only good 
> for the curent xen kernel boot, and if Domain-0 dies, so does the box (I'm 
> assuming that this is true, and if so, only a temporary situation)

Agreed -- it should move before 2.0.  We could in principle have
a 'hot standby' management domain that takes over if domain 0
dies. It probably makes sense for the two management daemons to
replicate their state directly rather than transfer information
via the filessytem. 

> Personally I have a bias against interpreted languages.  But that's just me. 
> :) I have this thing about too many dependancies and unused chunks of bloat 
> that aren't necessary, but are done in the name of "convenience" in final 
> products. But this debate of preference  is for another time/place. :) It's 
> your project, you decide what it uses (deference only, no insult/attude 
> intended).

Fair point, but rapid development and stability are our biggest
concerns right now. Nothing to stop someone else producing some
alternative tools ;-)

> Why is it that everyone wants to use HTTP as a network
> connectivity base? It seems kind of semi-one-wayish to
> me. While it can do 2-way communication, it's stateless, and
> has a limit of the amount of "sent" data to the httpd without
> the special method of an uploaded "file" which takes you
> outside of the protocol itself....

HTTP is a fine for RPC, but I agree it doesn't work well for
notifications. One of the good things about using the Twisted
framework is that changing transport protocol is trivial.

Ian




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel