there's too much backlog, and it takes too long to load

[ault011]

1. It takes minutes before the backlog even prints.
2. It prints far too slowly. At least a minute.
3. Too much is printed. 100 lines should suffice. If people want to read more there should be a way for them to manually request it.

[ault011]

100 lines of backlog, or alternatively 24 hours, is quite sufficient.

[ohAitch]

Comets are currently at 200, so I'll leave it at that. We would need some mechanism to print full backlog however, otherwise the only way to access it is webtalk.

[ohAitch]

Also, the current solution is showing at most 200 period, even if you've just e.g. restarted your pier after a bunch has happened on talk. Though I guess that fits with 3.

[cgyarvin]

Can you reconcile this with the behavior Henry observed? Does it really
take this long to download a backlog of 200?

On Thu, Nov 5, 2015 at 2:39 PM, Anton Dyudin notifications@github.com
wrote:

Also, the current solution is showing at most 200 period, even if you've
just e.g. restarted your pier after a bunch has happened on talk. Though I
guess that fits with 3.

—
Reply to this email directly or view it on GitHub
#507 (comment).

[ohAitch]

What it would look like if I were to just fall through the "if you're a
sub," check, which is the closest I currently have to a solution to this
issue*

On Thursday, November 5, 2015, cgyarvin notifications@github.com wrote:

Can you reconcile this with the behavior Henry observed? Does it really
take this long to download a backlog of 200?

On Thu, Nov 5, 2015 at 2:39 PM, Anton Dyudin <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Also, the current solution is showing at most 200 period, even if you've
just e.g. restarted your pier after a bunch has happened on talk. Though
I
guess that fits with 3.

—
Reply to this email directly or view it on GitHub
#507 (comment).

—
Reply to this email directly or view it on GitHub
#507 (comment).

[cgyarvin]

You're saying: (1) now it downloads the full backlog; (2) let's make it
download 200, like a sub. Sure. Fine.

What I thought you were saying: it only downloads 200, I don't know why
it's so slow. I think if you reread what you wrote, you'll see how I could
think that...

On Thu, Nov 5, 2015 at 3:04 PM, Anton Dyudin notifications@github.com
wrote:

What it would look like if I were to just fall through the "if you're a
sub," check, which is the closest I currently have to a solution to this
issue*

On Thursday, November 5, 2015, cgyarvin notifications@github.com wrote:

Can you reconcile this with the behavior Henry observed? Does it really
take this long to download a backlog of 200?

On Thu, Nov 5, 2015 at 2:39 PM, Anton Dyudin <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Also, the current solution is showing at most 200 period, even if
you've
just e.g. restarted your pier after a bunch has happened on talk.
Though
I
guess that fits with 3.

—
Reply to this email directly or view it on GitHub
#507 (comment).

—
Reply to this email directly or view it on GitHub
#507 (comment).

—
Reply to this email directly or view it on GitHub
#507 (comment).

[ohAitch]

Yeah, better phrased as "would be to show"

[ohAitch]

Though I suppose there might be a way to just /subscribe/ to only the last 24 hours upon joining, instead of throwing away most of a talk-report. Not sure how that would mesh with sequence however

[cgyarvin]

Um, yes! Isn't this what solving this bug implies? Are we really downloading messages and throwing them away? That would be a true WTF...

Sent from my iPhone

On Nov 5, 2015, at 4:13 PM, Anton Dyudin notifications@github.com wrote:

Though I suppose there might be a way to just /subscribe/ to only the last 24 hours upon joining, instead of throwing away most of a talk-report. Not sure how that would mesh with sequence however

—
Reply to this email directly or view it on GitHub.

[chc4]

Webtalk uses /f/~station/start/end/ for chunk subscriptions: would that just be the %f case in ++ra-subscribe? If (clan her) = %pawn, default start to our.now - 24h?

Just trying to get a handle on how all this works behind the scenes, sorry!

[cgyarvin]

Yes, that's what I'd assume is the way to do it.

On Thu, Nov 5, 2015 at 4:56 PM, chc4 notifications@github.com wrote:

Webtalk uses /f/~station/start/end/ for chunk subscriptions: would that
just be the %f case in ++ra-subscribe? If (clan her) = %pawn, default start
to our.now - 24h?

—
Reply to this email directly or view it on GitHub
#507 (comment).

[ohAitch]

Nope, you said "hack in a thing that only accepts the last 200 messages", I
hacked in a thing that only accepted the last 200 messages. The start is
point (~(get by sequence) partner), which defaults to 0 but looks important
for re-subscriptions, and I consequently didn't want to mess with ^-^

On Thursday, November 5, 2015, cgyarvin notifications@github.com wrote:

Yes, that's what I'd assume is the way to do it.

On Thu, Nov 5, 2015 at 4:56 PM, chc4 <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Webtalk uses /f/~station/start/end/ for chunk subscriptions: would that
just be the %f case in ++ra-subscribe? If (clan her) = %pawn, default
start
to our.now - 24h?

—
Reply to this email directly or view it on GitHub
#507 (comment).

—
Reply to this email directly or view it on GitHub
#507 (comment).

[ohAitch]

@chc4, it now does that for all ships, where "now" is whenever #529 gets pushed. There should probably be some way to override that (;join /urbit-meta %all?), but load times have been declared the primary priority.