Re: Re: xml list format

On Mon, 2005-12-12 at 18:00 +0100, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Wesley,
> 
> Wesley Leggette wrote:
> |
> | I've implemented an xml listing mode for dar. (See patch).
> |
> |
> http://sourceforge.net/tracker/index.php?func=detail&aid=1377733&group_id=65612&atid=511614
> |
> |
> | I know that the API was frozen on 5 Dec, but I'm hoping that if you like
> | this it could be fit in soon.
> 
> That's OK, the impact is not huge on the API, since this is only the
> change of one argument's type (which argument keeps the same role) and
> this in only one method.
> 
> 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.

> 
> 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.

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.

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. When I
thought about it later I was going to add a 'modify' action to show EA
changes without actual data changes.

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:

property       value        meaning
-----------------------------------------------------------------
action
               add          Data added or changed, maybe with EA.
               delete       Entry marked as deleted.
               modify       EA changed, data the same.
               none         No action.

data
               saved        Data present in archive.
               absent       Data absent (meaning entry deleted).

metadata
               saved        EA present in archive.
               absent       EA not present.


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'). 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).

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

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).


Thanks,
Wesley



> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions
-- 
Wesley Leggette <[email protected]>
-- 
Wesley Leggette <lists-+42/j/[email protected]>

GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDnfAbKiBWiPhIm90RAqFmAKCbWMj2GZ+Qo9LgNDeqeSj9COHcVQCghgWL
IiceQfESfVB4GcbGexzGb9E=
=hs+T
-----END PGP SIGNATURE-----