Re: xml list format

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wesley Leggette wrote:

[...]

|>
|>I don't see much application on XML output provided by the patch. Could
|>you bring me some lights on theses? Thanks.
|
|
| I'm writing a python script that displays archive change histories and
| it would be much easier to get catalog data from an xml file that parse
| the command line input (plus you can get more detailed data).
|
| The idea is that a series of catalogs are combined into a tree that can
| be dynamically searched. dar_manager has some of the functionality that
| I'm working on. The main improvement here would be explorable listings
| with color showing the latest archive.
|

Interesting! :-)

|
|>Next point, integrating your patch I found something strange, the
|>'action' field for a given inode has the value "add" if the data is
|>saved in the archive (I would rather chose "restore", because the
|>operation can also overwrite a file, not only add it, depending on the
|>switchs provided at restoration time, or maybe if we don't want to be
|>too restoration-related the "action" word is not the most suite, I would
|>suggest "state" or "data" with the values "saved", "not saved" ...)...
|>so, action is based on the inode data ("add" value), and also on the
|>Extended Attributes status, ("modified" value).
|>
|>Extended Attributes and file data are not the same. First file data is
|>only possible with plain files, while EA are possible with any type of
|>inode (directories, symlinks ...).
|>
|>My suggestion would be to replace "action" by two indicators:
|>- - "data" with "saved" / "identical" values for example
|>- - "EA" with "saved" / "identical" / "absent" values for examples.
|>
|>What's your idea?
|
|
| I choose 'action' because I wanted to indicate what was going on in a
| particular operation at the time the archive was created as opposed to
| what state the archive was currently. The idea is that a bunch of
| listings can be collected together to show a history.

I think I guess what you mean.

|
| Thus the xml listing would really be more for consuming programs than
| for dar users, which would mean it would be less necessary to use a
| 'restore time' metaphor, so to say.

To my point of view, the 'restore time' metaphor or the 'archive time'
metaphor bring both confusion. The listing by itself is an operation
that show the contents of an archive, I may be today straigh forward
seen the contents of an archive to guess what operation has been done at
~ archive time, ... but this may lead to confusion, when for example the
user asked to backup only certain EA not all... this many switchs that
alters the way the backup is done do not let any trace in the archive
once it is built. This may lead to not properly extrapolate the
performed action at backup time based solely on the archive contents.
For that reason, I would prefer a "status" metaphor: what is in the
archive, not an action.

Anyway, I have just finished integrating/adaptating your patch to CVS,
and only now read your email. For the reason above I have removed the
"action" attribute and replaced it by "data" and "metadata" ones, with
some modifications in their values, see below.

|
| As far as extended attributes, I thought about this and in this patch
| excluded the EA and data distinction on purpose, mostly because you
| can't get the actual values so they were useless for my purposes.

We can't limit a given feature to one's particular needs. Today you are
the only real user of the xml formating output, but tomorrow? If this is
not general and complete enough, we will have to break a limited feature
to build a new more general one... In a way, I am lazy, so I prefer to
directly build the more general feature possible at first (at least not
*design* something with restrictions (*implementation* can be partially
done at first) or obscur informations). Don't you agree?

| When I
| thought about it later I was going to add a 'modify' action to show EA
| changes without actual data changes.

Things are a bit more complicated, in particular a given file may have
its EA changed and its data unchanged... it may have both changed and
also both unchanged... I may also have or not have EA, EA may thus be
absent because none were associated to the file *or* because no changes
occured since the time the archive of reference has been done.

|
| However, in thinking about it I suppose it's best to get all the data we
| possibly can in now so the dtd doesn't have to be changed later. How
| about this:

Yes, I completely agree with that: "it's best to get all the data we
possibly can in now so the dtd doesn't have to be changed later".

|
| property       value        meaning
| -----------------------------------------------------------------
| action
|                add          Data added or changed, maybe with EA.
this is redundant with data=saved
|                delete       Entry marked as deleted.
this is redundant with data=absent
|                modify       EA changed, data the same.
Nop, because when a modification occured, the file is "saved" so here
the action is "add" too. To handle cases where a file's data or a file's
EA has not changed since the archive of reference we need to cast three
other states : "EA-changed not data", "neither EA nor data changed" and
"EA  unchanged, data changed" (even if today this later one never
occures)...
|                none         No action.
There is always an action, 'none' is really not explicit! :-)
|


| data
|                saved        Data present in archive.
OK
|                absent       Data absent (meaning entry deleted).
I would prefer "deleted" which is more explicit than "absent" (the file
is recorded as being deleted from the archive of reference).

is missing the state where the file has not changed since the archive of
reference. I've been using "referenced" in CVS for that case.

|
| metadata
|                saved        EA present in archive.
OK
|                absent       EA not present.
OK, EA are really absent, not recorded as "deleted since archive of
reference".

here also is missing the case where EA have ,not changed since the
archive of reference "referenced" has been used here too in CVS.

|
|
| Obviously as you suggested the 'action' value is somewhat extraneous,
| but I'd prefer to keep it because it would make history rebuilding logic
| simpler (e.g. only modify a property if 'action' != 'none').

Here this means if: data != "referenced" && metadata != "referenced"

|Also, I
| personally like keeping action concept separate from the state data.
| (And as far as efficiency, this it shouldn't be a big issue because this
| stuff isn't going to be stored in files).

This is redundant information, so you need a single attribute that tells
you if a given entry has no Data and no EA, right? If so, this is
possible to have it beside data and metadata.

|
| Also, I like 'metadata' as opposed to 'EA' just because I like the
| lowercase for the xml output better.

No problem.

|
| A further note, you mentioned replacing 'add' with 'restore', the
| concern being the file can be changed relative to the reference backup.
| I chose 'add' because I wanted the listing to represent actions at
| archive creation time, which I think is a better metaphor to use when
| comparing catalogs (not just restoring files).

Whatever the way the information is produced, I would not label it by an
action name, as a listing in semantic, is the status of an archive,
something that does not move...

|
|
| Thanks,
| Wesley
|
|

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDn0RzpC5CI8gYGlIRAjpVAJ9sjJlMiPZ1QwalwRzyjiRSpK5AYQCfTeYZ
5DDg9mQOeuPD90qU8YF3uR0=
=vTFW
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click