TabSRMM: Improve/rework "SendLater" to become faux offline messaging

[Vulpix]

For me, when I know the user is offline (i.e. on Tox), the workaround is to press CTRL+S and select "send later".

In this mode, all of the messages that you enter are queued for send later, circumventing the need to wait for the timeout and the prompt.

Still, the faux offline messaging (as outlined in the first post) is a better alternative, I think.

[Robyer]

Well, now I think I'll lower that limit for TabSRMM. It doesn't make sense to force users such big limit. In Scriver it has minimum interval allowed to 4 seconds (default 10), so why it is so high in TabSRMM?

Edit: Done: http://trac.miranda-ng.org/changeset/10476/

[Wishmaster]

Well, now I think I'll lower that limit for TabSRMM. It doesn't make sense to force users such big limit. In Scriver it has minimum interval allowed to 4 seconds (default 10), so why it is so high in TabSRMM?

Well, as I remember at least MSN needs such a limit:

From msn_svcs.cpp

Code: [Select]

        if (hContact == NULL)
        {
               if (MyOptions.SlowSend && strcmp(cws->szSetting, "MessageTimeout") == 0 &&
                  (strcmp(cws->szModule, "SRMM") == 0 || strcmp(cws->szModule, "SRMsg") == 0))
               {
                        if (cws->value.dVal < 60000)
                                      MessageBox(NULL, TranslateT("MSN requires message send timeout in your Message window plugin to be not less then 60 sec. Please correct the timeout value."),
                                        TranslateT("MSN Protocol"), MB_OK|MB_ICONINFORMATION);
                }
                return 0;
        }
And there are also p2p protocols like Tox, which may need it, I'm not sure about it.

[Robyer]

Wishmaster, Hmm... well then it's up to user to set it as high as he need. But this forcing in MSN protocol is weird too. Don't you think?

I commited that change too fast, maybe we should get that default value back to 60 seconds for MSN, or remove/change that check in MSN. Because Scriver has default value of 10 seconds - which is imho ok.

Btw when that limit expires, it just show error, but until you close that error, that message still could be sent and showed in tabsrmm/scriver. That's also why I think this limit in MSN is stupid. (Also dead of MSN is very close.)

[Wishmaster]

Btw when that limit expires, it just show error, but until you close that error, that message still could be sent and showed in tabsrmm/scriver. That's also why I think this limit in MSN is stupid. (Also dead of MSN is very close.)

Yes, this will obviously happen if you set that limit too low. So I think previous limit from tabsrmm was okay.  There can be many reasons why an ack takes longer time then usual.

[mida]

Wishmaster, i know that my written english isnt perfect but hope that other understand me and if not than i try it a second time 

[Vulpix]

Back on topic, as my topic has been kinda hijacked...

Do you think this is implementable? Would it require a lot of work?

Quoting myself below:

Hello all!

I'm curious how difficult it would be to change / implement a so-called "faux offline messaging" into tabsrmm.

Currently, tabsrmm has an option to send later / retry / keep trying etc.  This is _almost_ good enough, but not quite.. since the time between attempts increases exponentially, and in the end, the plugin sort of gives up until you restart miranda (which is documented; I'm not saying this is a bad behavior).

What I'm looking for is the ability to handle offline messages like Skype used to:

Core features:

    Keep trying to deliver the message until it is received or cancelled by the sender or a long period of time passes.
    Only start trying when the target (contact) comes/is online (protocols that support offline messages don't _really_ need this feature)


Quality of life features:

    Automatically switch into "faux offline messaging" when talking to an offline contact of a protocol that does not support offline messaging.
    Possibly handle the message with its original timestamp, ie. so that it appears in the history at the time when it was sent


The advantage of this would be the protocol-independent nature of these messages, i.e. no support in protocol required for this to work. Kind of like FileAsMessage does file transfers over any protocol as well.

Thoughts?

[Wishmaster]

Back on topic, as my topic has been kinda hijacked...

Do you think this is implementable? Would it require a lot of work?

Doesn't BuddyPounce do what you want? AFAIK TabSRMM supports it.

Anyways, I don't think it should be implemented in TabSRMM itsself. Telling people they must switch to TabSRMM just because they want to use that feature isn't a good idea, as most of them are overwhelmed with too many options.

[Vulpix]

Hmm,

I looked into BuddyPounce and it _almost_ does what I need.

It's just inconvenient, I guess. The point of having it in tabsrmm would be to be more convenient. But yeah, pretty much buddypounce functionality, just "more apparent".

Sidenote:
This somewhat sheds light on a 'problem' of Miranda.

Plugin for offline messaging-ish is called "BuddyPounce"

Plugin for tabbed messaging is called "Tabsrmm"

A miranda newcomer (a friend of mine) complains to me all the time that the plugin names make no sense, because without knowing them already, you'll never know what the plugin does.

[Wishmaster]

Hmm,

I looked into BuddyPounce and it _almost_ does what I need.

It's just inconvenient, I guess. The point of having it in tabsrmm would be to be more convenient. But yeah, pretty much buddypounce functionality, just "more apparent".

Well, I'm not sure if the Dropdown menu on the Send button supports BuddyPounce somehow. Is that the "almost"?

Sidenote:
This somewhat sheds light on a 'problem' of Miranda.

Plugin for offline messaging-ish is called "BuddyPounce"

Plugin for tabbed messaging is called "Tabsrmm"

A miranda newcomer (a friend of mine) complains to me all the time that the plugin names make no sense, because without knowing them already, you'll never know what the plugin does.

"BuddyPounce" is a little confusing, thats why there is a plugin list on the wiki. Im not sure if it makes sense to rename the plugin.

[Vulpix]

D: buddy pounce crashes my miranda (no crash log). Latest dev buddy pounce + latest dev miranda. Every time the buddy comes on, miranda freezes.

Every time a contact for which I had scheduled a buddy message comes online, my miranda freezes.

Disabling the plugin for now; and really, it's too inconvenient. For offline messages to be worth it, the integration has to be seamless, i.e. you can just start typing to an offline contact like you would speak to an online contact; messages will be delivered when you're both online.

Buddy pounce is rather strange in how it works, and definitely doesn't work seamlessly.

I guess this would really need to be implemented in srmm plugins (like tabsrmm), as they are the ones responsible for message-handling.

[Wishmaster]

BuddyPounce is a really old plugin, I'm not sure if it still works, and since almost every protocol used to support real offline messaging, there was not much interest in continuing it. Anyways, the message plugins would have to support such plugins, but they don't have to implement all of the code. I don't really like to duplicate code in all existing message plugins.

[AnrDaemon]

The whole thread sounds like there needs to be a callback service in miranda to support such mechanics. A simple proxy that do nothing by default, with an option for plugin to hook onto it and provide any additional services it wishes.

@mida, you can always close the window and tell it "yeah, yeah, I know".

[Vulpix]

Well, I suppose my point with tabsrmm was - it pretty much supports this feature already, sort of. It's just not good for the purposes of faux offline messaging -i.e. it gives up too early, it doesn't send my stuff when I'm set as away etc.

Depends on whether someone has the time to look into this or not really; I believe it's a perfectly valid feature