Notices by AndStatus (andstatus@loadaverage.org), page 29
-
AndStatus (andstatus@loadaverage.org)'s status on Saturday, 26-Nov-2016 12:14:35 UTC 
AndStatus
@d0e For GNU social please set basic authentication in AndStatus. OAuth works for Pump.io and Twitter -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 23-Nov-2016 10:19:32 UTC
AndStatus
@takeshitakenji Regarding AndStatus, you can lookup errors in the "Commands in a queue" menu item / view -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 16:16:51 UTC
AndStatus
@archaeme I will add the simplest check for the ”favorited something by”, but unfortunately there are other variations of the "favoriting activity”, sent by GNU Social server to a client application...
@theru @vinzv @takeshitakenji -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 16:07:27 UTC
AndStatus
@maiyannah Because you took part in this conversation,and we are Replying to all :-)
@theru @vinzv @archaeme @takeshitakenji https://loadaverage.org/attachment/3315107 -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 15:25:16 UTC
AndStatus
@takeshitakenji Agree, so one existing "Reply to all” action will be replaced with two, to avoid confusion: ”Reply to all participants" (what we actually have now) and "Reply to all mentioned users” ?!
@maiyannah @theru @vinzv @archaeme -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 15:15:24 UTC
AndStatus
@takeshitakenji Do you mean an option to include into "Reply to all” all users, mentioned in all messages of the conversation?
I think a separate action "Reply to all including mentioned” would be more flexible?! (but longer context menu...)
@maiyannah @theru @vinzv @archaeme -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 15:04:06 UTC
AndStatus
@archaeme Yes, AndStatus includes in ”Reply all” only users, who actually took part in the conversation (i.e. ignoring mentioned users). This is not a limitation: I think this is proper behavior.
@theru @vinzv @takeshitakenji -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 20-Nov-2016 08:33:14 UTC
AndStatus
@takeshitakenji Please point me to an example and describe, what you are doing and and what you expect to see.
The best way way to show me that message is to reply to it and mention me in that reply. -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 14-Nov-2016 11:59:33 UTC
AndStatus
@maiyannah If you really want to discuss this issue, please do it in https://github.com/andstatus/andstatus/issues/83
Otherwise we are going in circles :-( -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 14-Nov-2016 06:24:54 UTC
AndStatus
@maiyannah I see. I am talking not about personal preferences, but about proper system's design... -
AndStatus (andstatus@loadaverage.org)'s status on Monday, 14-Nov-2016 06:20:14 UTC
AndStatus
@maiyannah I evidently couldn't explain to you, why current behavior is correct :-(
Instead of pointing to inexistent bugs, please read our discussion on this topic and take part in it here: https://github.com/andstatus/andstatus/issues/83 -
AndStatus (andstatus@loadaverage.org)'s status on Sunday, 13-Nov-2016 08:03:52 UTC
AndStatus
@takeshitakenji We have AndStatus Settings -> Syncing -> Don't synchronize old messages... See https://github.com/andstatus/andstatus/issues/354 @lnxw48 @tknjshiftbot -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 10:48:54 UTC
AndStatus
@maiyannah I think that relying on a client application to check for duplication is conceptually wrong, because this solution won't guarantee absence of duplicated posts at a server side. E.g. a client application reposts intentionally, or has a bug...
@gargron -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 10:27:00 UTC
AndStatus
@maiyannah The point of view is incorrect, but it doesn't mean that this is a client's error or bug! And this why I proposed an intelligent fix at a server side... -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 08:12:57 UTC
AndStatus
@maiyannah@community.highlandarrow.com I agree, and as I wrote, AndStatus resends only those posts, which were not successfully delivered to the server from the application's point of view. -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 05:57:00 UTC
AndStatus
@maiyannah There could be many reasons, why a client application resends a message, not only its own error ;-)
Another quote from the old discussion:
---
In this case, I guess, we need to decide on the expected behavior of AndStatus first.
My intention is to ensure that messages, posted via AndStatus, will be actually delivered to the server. Hence it is expected that in a case of an error while sending a message, AndStatus will retry sending the message later (up to 10 times for now).
There may be different errors during sending, including errors sending delivery confirmation (actually, synchronous response with a posted message) back from the server to the client resulting in re-sending of the message that was already successfully delivered to the server (because AndStatus doesn't know that the message was successfully delivered). This is a normal situation and it should be handled by communicating systems...
Do you agree so far?
---
@gargron -
harmlessgryphon (harmlessgryphon@sealion.club)'s status on Tuesday, 08-Nov-2016 12:48:09 UTC 
harmlessgryphon
@dwmatiz @andstatus I'd like to see AndStatus automatically jump to the top of the timeline when opened.
I do most of my reading here on the website, so the application gets several weeks behind at times. -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 05:48:03 UTC
AndStatus
@harmlessgryphon "when opened" isn't clear enough. Currently AndStatus stores last viewed position of each timeline in a database i.e. forever. Twidere stores timeline position until Android system or a User kills it, this can be a minute or a day...
I can add an option ”Store timeline position for one user session only" making that ”session" dependent on both actual application loading and on time passed since the timeline was last viewed (position expiration in, say, 2 hours)
?!
@dwmatiz -
AndStatus (andstatus@loadaverage.org)'s status on Wednesday, 09-Nov-2016 05:35:56 UTC
AndStatus
@maiyannah As written in the above mentioned discussion, I think this behaviour of the server would be much better, even better than Twitter does ;-):
---
Meanwhile I checked how Twitter responses to posting the message ("tweet") with duplicated text. It returns HTTP error "Forbidden", even if the duplicated message is not the last message sent by this user.
It will be far more intelligent to respond not with an error but as a successful sending of that previous message.
Thus a client application (and a User of that application! ) will know that the message it's trying to resend was actually sent earlier. And stop resending!
---
See https://github.com/andstatus/andstatus/issues/83
What do you think?
@gargron -
AndStatus (andstatus@loadaverage.org)'s status on Tuesday, 08-Nov-2016 20:00:22 UTC
AndStatus
@maiyannah @gargron On duplicated posts please read this discussion: https://github.com/andstatus/andstatus/issues/83
All Chirp! content and data are available under the 