UX feedback

Way to technically. Why should I enable it and why not? Honestly, I don't know either.

Honestly, I don't know either. ^^"" There was just this comment in the discussion that I should somehow not use the rare data but build the view, and as I told you, there was no real way. Best I could do was call entity_prepare_view(), without really knowing what that would do, so I provided an option for it.
Now that the Entity API supports viewing, this will probably be useless anyways, once I implement the viewing stuff. So I just deleted the callback.

To which data do those processors apply!? To the fulltext only? I'm rather confused by that. What are the pros/cons of the single processors? When should I use them? Perhaps a link to some more help would be nice here.

The processors can choose themselves what fields to process, though probably most will only process fulltext fields.
I don't think a link is needed, I should probably just write longer descriptions for the individual processors (and add a sentence stating the previous sentence to the overall description).
Do these descriptions sound better?

Select processors which will pre- and post-process data at index and search time, and their order. Most processors will only influence fulltext fields, refer to their individual descriptions for details regarding their effect.
Enabled processors

Ignore case

This processor will make searches case-insensitive for all fulltext fields (and, optionally, also for filters on string fields).

HTML filter

Strips HTML tags from fulltext fields and decodes HTML entities. Use this processor when indexing HTML data, e.g., node bodies for certain text formats.
The processor also allows to boost (or ignore) the contents of specific elements.

Tokenizer

Tokenizes fulltext data by stripping whitespace. This processor allows you to specify which characters make up words and which characters should be ignored, using regular expression syntax.

You mean I should look up the code to know is supported? Not very user friendly :P

No, I mean the README.txt, and it's got a capitalized "read me!" in it for a reason. ;)
Also, when viewing a search server, it's description is displayed. I could (and probably should) add information there on what the server supports or doesn't support.

also a sensible default of fields to index by default might make sense as it requires much thought of what is need afterwards. At least fulltext field should be checked by default, as the user has already expressed his desire to have it :)

You can't really do a generic "sensible default". And when you can't do that, I don't think that checking fields added by data alter callbacks by default will improve UX significantly.

also "data alter callback" is very technically. Perhaps we could come up with a more user friendly name for the UI.

That's what I said from the beginning, but up till now, no one (including me, of course) came up with a better one. I'm more than open to suggestions.

I see. "server's service class' documentation" suggests me it is class - thus code - documentation. Perhaps say server's service module documentation instead.

I just enhanced the service class descriptions provided in the hook and linked to the server page (if one is available). I think this is the best solution, even if the information is now slightly duplicated.

Why do I have to check the full-text field manually when I already said I want it? I'd assume it's there once I checked it once.

OK, I found an easy and clean way to do it, so: done.

But well, perhaps we just provide a useful default index for nodes so people have an easy start?

Seems like a good idea. Done.

@ "data alterations": Hm, I'll have to think about that one. It's right, users shouldn't see the word "callback", but now it's everywhere in the whole module, so it's quite some work to correct it. Which doesn't mean that I won't do it, but then it should be final, so I'll have to make sure we got with the right one this time.

You can easily change the name for users only, so it doesn't involve callback but use the stay with the old name in code. If you call it just "data alterations" for every developer it should be still clear that this is about the data alter callbacks.

Yes, of course – I wouldn't have considered changing the hook anyways. And as I took a quick look, the name "Data-alter callback" was only used on a single page (index/%/workflow) and in the README.txt, so I just changed it. If someone comes up with a better name, great, otherwise this is already definitely an improvement. (Even though it's a little awkward having two Austrians discuss what sounds best in English. ;))