--On Monday, April 19, 2010 07:59:58 PM -0400 Jason Edgecombe
<[email protected]> wrote:
Steve Simmons wrote:
On Apr 19, 2010, at 9:54 AM, Jeffrey Altman wrote:
On 4/19/2010 2:17 PM, Sanket Agarwal wrote:
I would wrap this blob with
<cell name="cellname">
I'm torn on this one. You can't run vos e on more than one cell at a
time, so don't see this as particularly useful in most circumstances.
However, if it *is* decided that it should be useful, I'd implement as
jaltman suggests - in particular, don't put the cell name inside the
volume-specific detail.
Similarly, data like server, server IP address and partition is largely
redundant when you're dumping many volumes. My xml-foo is amazingly
week, but something like
<cellname="cellname">
<server=1>
<uuid="xxxx">
<ipv4list>
<ipv4="192.168.1.1">
<ipv4="10.0.0.1">
</ipv4list>
<partitions>
<vicepa="/vicepa">
<vicepb="/vicepb">
</partitions>
</server>
</cellname>
<volume>
<name>root.cell</name>
<id>536870915</id>
<server=1>
<partition="/vicepa">
...
would eliminate a helluva lot of redundancy. It might also be worthwhile
to do this down to a vice partition level, eg,
...
<partitions>
<partition>
<partid="1">
<vicepa="/vicepa">
</partition>
<partition>
<partid=2>
<vicepb="/vicepb">
</partition>
</partitions>
...
<volume>
<name>root.cell</name>
<id>536870915</id>
<partid=1>
...
why <serv> and not <server>?
Ditto for partition vs part. Right now he's just using the tags as
reported by -format. I suspect that 'serv' vs 'server' and 'part' vs
'partition' was intentional on the original author's part; it does make
parsing of the original ascii output easier. I've used that distinction
myself for that purpose.
Steve_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
would it be better to have <ip version="4" address="192.168.1.1" /> ?
Would that be better to anticipate ipv6?
No, I don't think so. IMHO it is better to think of IPv6 as a different
protocol, rather than as a new version of an existing protocol.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
