Similar to the clive 1.x --emit-csv option? Any thoughts on the output formatting are
welcome.

Similar 1.x is good. I have now integrated it into the extension for 1.x (with 2.x
using the old behavior). I somehow didn't realize what the output meant when I was
searching for this (I don't know why).

It's a little known feature and even less documented one so it's understandable. I'll
look into this.

Ported the --emit-csv from 1.x with a minor change: each csv line starts now with "csv:".

Added --emit-xml while at it.

You can use --quiet if you don't care for the status messages, the emitted output
gets still printed with it. Note that any errors are printed to stderr whether
--quiet is used or not.

  git clone git://repo.or.cz/clive.git

Feedback welcome.

That minor change is no problem for my code and certainly a good idea. However there
is a major difference between 1.x output and 2.x output of "clive --quiet --emit-csv
http://de.youtube.com/watch?v=jyQMtvHQ8Fs"

1.x (tested with Debians "0.4.19 20080722" and subversions "1.1.0 r1813"):


==> Passed:
OK:
"http://de.youtube.com/watch?v=jyQMtvHQ8Fs&fmt=18","http://www.youtube.com/get_video?video_id=jyQMtvHQ8Fs&t=OEgsToPDskIHlB69dh9ZOPehbFqym9Nc&fmt=18","paffthebeginning.mp4","12.35MB"


2.x (git current, how do I figure the version of a repo?)


csv:"http://de.youtube.com/watch?v=jyQMtvHQ8Fs","2008-10-23
01:56:05","http://youtube.com/get_video?video_id=jyQMtvHQ8Fs&t=OEgsToPDskJfZPPWs--bxRBsUcVu9Spw","7544533","7544533","0","jyQMtvHQ8Fs","YouTube
- paff - the beginning","flv","paffthebeginning-(jyQMtvHQ8Fs)-[youtube].flv","flv"


Compared with --emit-xml this output seems to be:

$page_url,$video_url,$recommended_filename,$file_size

vs.

$page_url,$upload_date,$video_url,$remaining_file_size,$file_size,$bytes_already_downloaded,$video_id,$page_title,$file_suffix,$recommended,$video_format

I don't understand the logic of this order. As I process $video_url and
$recommended_filename I wouldn't need to have a 1x-2x-switch if these are at the same
location (this isn't a big problem, but nice if avoidable). It is also worth thinking
about grouping the columns having the urls first, followed by the meta-data, followed
by the status information (having $file_suffix seems redundant):

$page_url,$video_url,$recommended_filename,$video_id,$video_format,$upload_date,$page_title,$file_size,$bytes_already_downloaded,$remaining_file_size

Except for the position of $video_url and $recommended_filename, this is purely
cosmetic, minor and vulnerable to personal taste, so feel free to disagree and ignore.

Thanks for the constructive comments.

> 2.x (git current, how do I figure the version of a repo?)

Being fairly new to git myself: http://git.or.cz/course/svn.html
Under "Things You Should Know" and "Revisions".

> I don't understand the logic of this order.

No other than "dump hash values order to stdout". The 1.x --emit-csv is fairly 
restricted. Who's to say someone would not want to use the page_title or 
continue_from details someday? Keeping in mind the the significant changes 
between 1.x and 2.0, it made sense (to me) to overlook the version 
compatibility and allow the users of 2.0+ to tap into the other available info.

But I agree. It does break the compatibility with 1.x, and even if 2.x
is a different program altogether, it may be best to have --emit-csv
print the same details as the predecessors. I've made the necessary
changes to --emit-csv so that it now prints:
  $page_url,$video_url,$filename,$file_length_mb

As for the --emit-xml. Since XML is more flexible than CSV, and since the
extra details do not really bloat the output that much. I think it can
remain as it is. I see little reason to add code to single out specific
details (e.g. file_suffix) and turn the loop into a if-condition -fest unless
there's a very good reason for this. The users can grab whatever they need
and ignore the rest.

Patch included.

	emitcsv-1.x.patch
	692 bytes Download

With regards to emit-xml 100% agree.

I also agree that the csv of 1.x is very limited, but I don't think that emit-csv
needs to be crippled forever because of 100% backwards compatibility. With csv the
important thing is that the order of the used columns are the same. It isn't a
problem if more columns are added. So I think it would make sense to have the
additional columns added to the end.

In addition the patch changes the preference of --emit-xml over --emit-csv. If both
options are given clive would output a messy mixture of the xml and csv. Now it just
outputs --emit-xml instead and ignores --emit-csv (this is at zero cost).

	emitcsv-1x-extended.patch
	1.4 KB Download

> In addition the patch changes the preference of --emit-xml over --emit-csv.

Good catch. I've committed the changes to the repo. Thanks.

(No comment was entered for this change.)