Discussion of the download / upload tools

[Dick Needle]

I have carried out a test on the Men's World thread using halvar's latest version and everything seems to be in order. Not being an expert in these matters, is it safe to delete the dot-files AFTER the download? I know they are very small but I don't see the point of keeping them if there is no need. Thanks.

[BCFC_1982]

Hi Mr Needle. Can you let me know which thread number you've used please? i.e. which Men's World Thread? Cheers

[Dick Needle]

Yes, it's number 17433 - apologies if it's a stupid question!

[BCFC_1982]

Do you plan to reup any of the images for those posters at some point in that thread?

Not a stupid question. I would imagine it's ok to remove them, UNLESS you want to rerun the grabbing tool at a later point on that thread.

BUT I'd wait for halvar to answer you my friend - he's the boss

[Dick Needle]

Thanks, I'll leave them for the time being, they don't exactly use much space!

[halvar]

Originally Posted by Dick Needle

I have carried out a test on the Men's World thread using halvar's latest version and everything seems to be in order. Not being an expert in these matters, is it safe to delete the dot-files AFTER the download? I know they are very small but I don't see the point of keeping them if there is no need. Thanks.

Please do not delete them before 1st of July. As there are still bugs it may be necessary to run threads again to fetch missed images.

I made them dot- files because this is how files are hidden in Linux/Unix. I could try to set the hidden flag on windows.

Edit: And I plan to create a post repair tool that uploads images end edits posts. To replace links in posts I need to match links with filenames. The dot files provide this match. They contain the file name for a file id.

[effCup]

Originally Posted by halvar

I made them dot- files because this is how files are hidden in Linux/Unix. I could try to set the hidden flag on windows.

Don't bother hiding them. Paraphrasing part of the Zen of Py: better to be explicit. & also: we're all grown ups here.

@halvar: I had been thinking about your "queuing" of thread ids for processing by terminal/cmd.

My problem/query: can you create/assemble such a queue of threads from a single vef forum? Do you understand the question I'm asking?

Further problem: many vef forums have sub-forums, and my response there would be: leave them alone, i.e. allow the user to choose only one forum at a time. Do not use recursion.

The risk: not all forums are equal. The above usage would be great in model id request section as there there's forums with lots of short/small threads to process. Elsewhere it would be a big problem--people may try it on mags. or models forums without realising just how big the content to save from a whole forum might be.

So, it's just an idea to ponder.

addendum: the above should be kept separate from vef-imagerescue. It would just be a tool for assembling a list of thread ids from a specified forum ready for use with the vef-imagerescue tool--maybe a text output file. That would allow, say, a group of people to then split up between them that list for that single forum into manageable chunks, e.g. so they can take 1/3 each, or whatever.

[halvar]

Originally Posted by effCup

My problem/query: can you create/assemble such a queue of threads from a single vef forum? Do you understand the question I'm asking?

Further problem: many vef forums have sub-forums, and my response there would be: leave them alone, i.e. allow the user to choose only one forum at a time. Do not use recursion.

I think I understand what you mean: print a list of thread ids for a forum to create a batch file.
I could print a line for each thread of a forum, like
thread id, thread title, number of pages
Then you could easily extract a batch for threads that are most important to you. I need something like this myself.

[halvar]

Originally Posted by effCup

addendum: the above should be kept separate from vef-imagerescue. It would just be a tool for assembling a list of thread ids from a specified forum ready for use with the vef-imagerescue tool--maybe a text output file. That would allow, say, a group of people to then split up between them that list for that single forum into manageable chunks, e.g. so they can take 1/3 each, or whatever.

Why should it be separate? There could be another Tab with a textfield and button.

for the idea of organising who downloads what.

[effCup]

Originally Posted by halvar

Why should it be separate? There could be another Tab with a textfield and button.

for the idea of organising who downloads what.

OK, your call to make. All I was meaning was: people should still be able to use vef-imagerescue tool as at present: single thread id input.

Try not to complicate the UI for the many folk on vef who aren't "skilled" computer users?

In terms of program flow, what I described before requires zero changes to the functionality of vef-imagerescue. What I described before is like a "wrapper" functionality.

I guess I was thinking a bit along the lines of the bash shell--each additional "piece"/program takes inputs & makes outputs, so that they can be "chained" if required, but not if not.

And: I don't want to force the user to "run" it all now against the list of threads compiled from the forum, e.g. if they want to split that list up into "chunks" for different users to then apply. They may not necessarily have already decided how many splits to make when they trigger it? /shrug/

Do whatever is simplest/easiest for you, but also try to stay "clean".

If your output is to a text file, try to make it so that it can simply be input to terminal/cmd for users to "run" the next step, using vef-imagerescue, i.e. the text file is just a "parameter" input?