Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stu Redman]

I don't get it how the feature can be useful in the current form.
So your search reveals 16 hits, 5 of which are known (downloaded before) and marked. What do you want to do with the others ? You can only start downloading them, and then quickly determine by the upcoming filenames which are fake. So the "mark as known" should rather be a "mark as fake and cancel" in the transfer window. Also a "mark as fake and delete" in the share window if you only detect it after downloading. And fake files should be stored in a different file. Master hash (and maybe size) should be enough.
Right now - why would you mark the extra 11 as known without ever checking them? Except if you did start downloading them and then mark them in the search window as known having no other option.

If nobody disagrees I'd implement the "mark as fake" and ditch the "mark as known". This also does away with the risky storage of information inknown.met which doesn't belong there.

[LittleAbacus]

I wouldn't count this feature out just yet. Imagine this use-case:

1. You enter a certain combination of keywords (rather coarse) and geht several hundred results.
2. Now you want to do some refining, so you enter some keywords you don't want to have, filter by them negatively and mark the yielded result as known.
3. repeat #2 arbitrary
4. remove the filter, press Ctrl+A and hit enter.

Got the idea? On the other hand, your "mark as [fake|known] and cancel" for the transfer window would be a nice (complementary) feature, no doubt. However, why replace it? Why start downloading only to have to cancel downloads again which you hadn't had to start, had you exercised the above use-case? Let alone the transfer window allows no filtering (which is just fine).

[Stu Redman]

Got the idea?

No, sorry.

Why start downloading only to have to cancel downloads again which you hadn't had to start, had you exercised the above use-case?

Because the filename may be exactly what I'm searching, but the content still be just some cheap porn. Exercising your usecase won't help against that. Also it will spam known.met. Permanently.

[LittleAbacus]

No, sorry.

Ok. I've made the experience that (since the mark-as-known-feature) it's often easier to search by coarse keywords and refining the search than to do fine-grained searches in the first place.

Because the filename may be exactly what I'm searching, but the content still be just some cheap porn.

ACK. However when you start searching, you of course know everytime what you don't want to be yielded in the result list right from the beginning? Well, I don't and therefore BY looking at a coarse result list I can approach the results I want step by step without having to engage a whole new search.

Exercising your usecase won't help against that.

Of course not, it was never meant to. That's why I consider your proposed cancel-and-mark-as-<whatever>-from-transfer-window a useful complement to mark-as-known-from-searchresults.

Also it will spam known.met. Permanently.

What's the difference to "spamming" a file called let's say fakes.met? Somebody engaging in p2p might as well have a few spare MBs for amule's config itself. How those "known"-data is divided and where it's saved is but a paradigma and has nothing to do with the actual functionality discussed here.

[Stu Redman]

What's the difference to "spamming" a file called let's say fakes.met?

A "known file"  is a rather heavyweight structure, and the list of known is files held permanently in memory. Blowing it up with remainders from searches is way besides its intention and a waste of resources.

I still don't grasp how you want to refine your searches using "mark as known", but a permanent marker is definitely the wrong approach for that.

[LittleAbacus]

It's beside the point because the CSearchFile is just cast to CKnownFile instead of creating a new CKnownFile and setting the appropriate fields.

@grasp
Sorry, my fault, I forgot to mention that I employ the checkbox "hide known files" within the search dialog.

@wrong approach
What's wrong when it does the trick? Of course, speaking strictly technically you're right. However unless you provide a function which gives an equivalent functionality, don't remove it - or better: don't cripple amule. (speaking of equivalent: your proposal for the transfer window is not equivalent but complementary... but I already stated that).

If I still didn't convince you, at least just don't remove the feature but please post a reverse-diff-patch so those people who still want it can reverse-patch your reverse-diff. Or so.

[phoenix]

If nobody disagrees I'd implement the "mark as fake" and ditch the "mark as known". This also does away with the risky storage of information inknown.met which doesn't belong there.

I disagree. It is made to be "mark as known" and the file actually becomes "known". The semantics given to "known" is a problem of the user. I have implemented and used it myself and in spite of some people considering it not useful, it actually IS usefull to some people (me included).

What can be argued is that the present implementation sucks, and I certainly agree with that, it has been a quick and dirty hack that can be improoved. The "risky storage of information inknown.met" should not be an issue in a proper implementation. My idea was that the patch evolved from there, if I thought it was totally useless, I would not have wasted my time implementing it at all.

A question to be raised is: what if you "mark as known" by mistake? That means that "Unmark as known" should probably be implemented too.

And now that we are at it let me suggest a related and also usefull feature: weak sort by "knownness".

Cheers!

[LittleAbacus]

The sorting by status is a nice idea. Shouldn't be too hard, so I'll see to it over christmas...

[Stu Redman]

What can be argued is that the present implementation sucks, and I certainly agree with that, it has been a quick and dirty hack that can be improoved.

I'm glad you joined the discussion, phoenix, I was hoping for a word from you.
Sorry, but I don't count commented-out code as "implementation", rather as unfinished business. If you still find the feature useful, please go ahead and finish and release it.

The "risky storage of information inknown.met" should not be an issue in a proper implementation.

So - is it useable right now or not ? What happens if a user switches back to eMule and eMule tries to open the known.met ?

A question to be raised is: what if you "mark as known" by mistake? That means that "Unmark as known" should probably be implemented too.

Another issue with it.

I can of course leave it as it is and implement the "mark as fake" side-by-side. Problem is we have then two different approaches for almost the same purpose which is not helpful for the useability.
So I'd rather cover LittleAbacus' usecase with a "preselect" feature. You could select (or deselect) search entries and show all/preselected/not preselected entries. But the preselection would not be persistent (not stored after exiting the app). Persistance would only be available for known files like today, and for files marked as fake.

[phoenix]

I'm glad you joined the discussion, phoenix, I was hoping for a word from you.
Sorry, but I don't count commented-out code as "implementation", rather as unfinished business. If you still find the feature useful, please go ahead and finish and release it.

Call it whatever you like, that is just semantics. The fact it that I have put this for trial for those who got interested and want to test it. I have no resources to go on hacking aMule right now, so all I can say is that I will do it Soon(TM).

So - is it useable right now or not ?

It is useable and works. But it could eat your cat or wash your brain.

What happens if a user switches back to eMule and eMule tries to open the known.met ?

You tell me, I don't use windows. If there is a problem, aMule should suffer it too. And it should definetely be fixed. The only reason why I have put this under comments is that I don't have the time to study the implementation properly, and any such feature, even if experimental, should be carefully planned.

I can of course leave it as it is and implement the "mark as fake" side-by-side. Problem is we have then two different approaches for almost the same purpose which is not helpful for the useability.

I agree. But why do you want the separate "mark as fake"? You are just imposing semantics, I don't see the gain. Also, I don't see spamming know.met as a problem, this is rather a user's choice.

So I'd rather cover LittleAbacus' usecase with a "preselect" feature. You could select (or deselect) search entries and show all/preselected/not preselected entries. But the preselection would not be persistent (not stored after exiting the app). Persistance would only be available for known files like today, and for files marked as fake.

Not usefull to me, I would need persistency. I also find it unnecessary GUI compication (bloat), but if someone sees a reasonable use for it, go ahead. I personally don't.

Cheers!

[Stu Redman]

The only reason why I have put this under comments is that I don't have the time to study the implementation properly, and any such feature, even if experimental, should be carefully planned.

Well, so it will stay on hold until Soon(TM).

But why do you want the separate "mark as fake"? You are just imposing semantics, I don't see the gain.

Several people have asked for this already. The gain is:

• It will be available from the transfer and share windows, when you have had a chance to detect if it's fake or not.
• You can distinguish between files you have and files you rejected as fake.
• Fakes can be stored way more compact than known files, both on disk (unimportant) and in RAM (important).

[phoenix]

You're just missing the point.

[Stu Redman]

Then put me back on track please and explain to me what I'm missing.

[LittleAbacus]

Hi phoenix,

here's your sort feature. I refrained from determining the exact status the search results have in the DownloadList but just distinguished between "queued" and "finished", but see for yourself. For I made some other (private-to-me) changes, the patch should apply with an offset of a few lines but otherwise cleanly.
Cheers

Update: please use the v2.patch

[phoenix]

Hi LittleAbacus,

Nice patch, I have committed it with a simple modification, because although aMule compiled fine, it was breaking the aMuleGUI build. SearchFile.cpp is "core", and amuleGUI does not use "core" files. I have passed the function DetermineStatusPrintable() to SearchListCtrl.cpp as a static member. If you disagree with something, please tell me. The committed patch is attached for your appreciation.

Thanks for your cooperation!