i think of zeroconf as just a way of identifying a server from which to
obtain a config file (which could be text). in other words, we could
distribute our *existing* config files via zeroconf plus a getconfig.
rob
Sam Lang wrote:
On Jun 20, 2007, at 7:54 PM, Rob Ross wrote:
Since our config file is text, can't we skip any encoding? I agree
that it would be more concise, but we don't send config files around
all that often.
With zero conf they would be generated on the fly, so a text format
isn't really necessary, and would be harder to update change than an
internal struct representation that we just encode/decode.
-sam
Rob
Sam Lang wrote:
On Jun 20, 2007, at 1:54 AM, Murali Vilayannur wrote:
Hi Sam,
I see..So do you wish that we fallback to parsing from server config
file if that were to be specified in place of a server-alias string in
command line..
That shouldn't be too hard, no?
Hmm...well if the server config file isn't specified, why can't the
server just get the hostname instead of requiring an alias?
Yeah I was thinking that if a server config was specified as the
second argument to the pvfs2-server, the server would go ahead and
use those values for endpoint, storage location, logfile, etc.
Any updates on what the current stance on zero-conf based server
startups, i.e. is there still any interest and/or preferred
approaches? :)
Definitely still interest. I'm not sure we've come up with an
approach yet. I would argue a first step toward zero conf would be
encoding/decoding the config using the lebf encoding layer. This
would give us a more efficient representation of the config, as well
as make it easier to modify at runtime.
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
