Render after wiki-page loaded

[opn]

At the moment the activity plugin is often rendered before a roster on the same wiki-page has had to load. This makes the use of roster based curated activity very awkward to implement for anyone but an experienced user (instructions to reload the page etc).

As this is one of the most powerful and useful use of rosters and fedwiki navigation in general it would be great to figure out how to render the result o the activity plugin after everything else has loaded?

Documenting how to do this would also be useful to other plugin authors faced with similar issues.

[WardCunningham]

I'm against piece-meal solutions to what is a general problem. Let's look to Observables for broad solutions.

[opn]

That would be fantastic if such a thing was to be built in generally. I'm wondering what that would mean with regard to generally authoring of wiki-plugins? Would that mean that the plugin-author would not have to worry about the oder of loading of aspects of wiki? Which "thing"?

[opn]

Syntactically I think we should be able to directly refer to a ROSTER in the activity-plugin. At the moment we have:

ROSTER all
ROSTER category

however what we often want to do is refer to a roster on an authors site (as we do within roster-items themselves), with a syntax like this:

ROSTER ward.bay.wiki.org/welcome-visitors

Placing that directly inside the roster-item would allow us to craft these views without also making a copy of a roster.

[WardCunningham]

The early web was simple: you fetched a page and then read it. The user was in control.

Federated wiki follows that model mostly. Pages hold still while you are looking at them. There are a few exceptions. As new sites join the neighborhood twins will show up and Recent Changes grows. This "action at a distance" is the first step down a slippery-slope of doing for the user what you know the user would want done. This has gone on too far. The "algorithm" is now recognized as the work of bad people. Let's not go too far down this path.

I do feel that refreshing a page should reconstruct the lineup just as it would appear had it been opened one page at a time. We have anticipated this problem with the two-phase rendering: emit and bind. Unfortunately we haven't applied this well and it may not be enough. I suspect if all emits were completed before any new page binds were run, and if plugins offered promises when they emit and plugins could sequence their binding by resolving those promises, then we would have it.

General transclusion is a much more dangerous. I do recall that we had circularity checks in the Roster code and that this was hard to get right.

[opn]

I cannot disagree with what you say above. However nor can I see the relevance to the issue raised which does nothing to alter the current minimal fedwiki site-site coupling or address transclusion. All it does is enable an author to do what the current ROSTER syntax enables. If we allow the addressing to remote REFERENCE pages in the roster - then enabling remote/specific calls to rosters does the same, and actually encourages good behaviour (it's more "socially encapsulated" to refer to a remote roster than a remote page of references)