Re: Re: xml list format

On Tue, 2005-12-13 at 23:00 +0100, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Wesley Leggette wrote:
> 

[...]

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

What about the second patch I sent in?


> 
> |
> | 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
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions

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

iD8DBQBDoBEnKiBWiPhIm90RApGrAKCsXf+pz5bvDAONUp93aJpMFnrZqQCeMgAz
ed92btIAczK1PE5GunoghfI=
=WJOq
-----END PGP SIGNATURE-----