allow multiple !doc requests in one message

[cebe]

(02:34:46) CeBe: sherry: yes, you can use !doc CAccessControlFilter or !doc CWebUser::checkAccess() there
(02:34:47) MrFisk: sherry: CAccessControlFilter Performs authorization checks for the specified actions. 
http://www.yiiframework.com/doc/api/CAccessControlFilter

should add answer for any of the !doc's.

but we have to think about what it is doing with choices...

[rawtaz]

@cebe Yeah. Multiple inline commands has so far been put on ice as there were more important things to attend with MrFisk, but also due to the question of how to deal with the situation where one does multiple commands and the/a not-last one or all of them result in a choice list.

We can't store both of them for the user, so which one should go? If we store the last one then the previous ones are invalidated, and if we store only the first one the second one isn't usable either.

One way would be to merge them, but im not sure that is ideal, as the two commands can contain such different queries that the choices listed are just confusing to concatenate. But it's an option at least.

[tom--]

i suggest requirements as follows:

• MrFisk shall prompt for selection (from a list of search results) on the first ambiguous !doc command in a message and ignore all subsequent ambiguous !doc commands in the same message.
• MrFisk shall respond to multiple non-ambiguous !doc commands in a message (up to some safety limit) regardless of the presence of any ambiguous !doc commands in the same message.

[rawtaz]

MrFisk shall prompt for selection (from a list of search results) on the first ambiguous !doc command in a message and ignore all subsequent ambiguous !doc commands in the same message.

Wouldn't this basically make the commands following the first ambiguous one useless, nullifying much of the idea in the first place? I realize things will be fine if there are none or at most one ambiguous command(s) (assuming we follow both requirements you suggested), but the chance of ambiguity is pretty high usually, I don't see how it would be less given multiple commands.

[tom--]

@rawtaz The objective is: MrFisk answers both commands in something like:

CeBe: sherry: yes, you can use !doc CAccessControlFilter or !doc CWebUser::checkAccess() there

I proposed two functional requirements aimed at meeting the objective without complex implementation. They are perhaps given in the wrong order. The second requirement expresses the additional functionality that fulfills the objective. The first formalizes a compromise functionality that addresses the point you raised about search result lists 7 days ago while allowing the first requirement to still fulfill its purpose. The first requirement does not nullify !doc commands after the first ambiguous one—it nullifies subsequent ambiguous ones after the first ambiguous one. Thus MrFisk can answer any number of !doc commands per message but maximally one ambiguous command.

As i see it, the functionality expressed in these two requirements meets the objective.

If your new probabilistic argument asserts that it is unlikely that in a message with more than one !doc command any of them are unambiguous then I regard that as an argument against the original objective, not the requirements I proposed.

[rawtaz]

@tom-- I completely realize that your proposed requirements fulfill the goal of having MrFisk answer multiple requests, which was the goal set forth in this issue. I also didn't phrase my previous comment 100% accurately. Indeed the non-ambiguous commands are clear; The concern I raised are only about multiple ambiguous commands.

But perhaps, in a long-term perspective, that is not the only thing that we should focus on here. Perhaps it would also be useful to arrive at functionality that actually enhance MrFisk from a usability perspective, instead of just meeting a couple of technical/logical requirements.

To clarify, my concern was/is that when there are more than one ambiguous command, the second and later one(s) will effectively be "useless", because only the first one of them is answered (the others will be ignored/not replied to). That, combined with it being likely that multiple ambiguous commands are given now and then, is why I raised the question.

To sum it up, I think we both understand your proposed requirements and what objective/goal they meet, and the question at hand is whether the concerns I raised are relevant or not, and, if they are, what options there are to deal with that.

Personally I don't think it's ideal that some commands of a message are not responded to, especially when the original objective was to have MrFisk respond to all commands in a message.

The other option of concatenating the choice lists for ambiguous commands is a bit diffuse, and having multiple active choice lists for a user is very impractical in that one would then need to do something like !n listNumber or similar, which isn't great either.

Throwing out another option; When multiple ambiguous commands are given in one message, instead of replying with the result for any of them, MrFisk could give a message like: "foo: Too many ambiguous results. Please be more specific for: !doc firstAmbiguous, !doc secondAmbiguous, ...". That, or replying as usual for the non-ambiguous ones and doing this for the ambiguous ones.