-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confirmation #3
Comments
@inmysocks - the OP has been severely updated from yesterday. 'nuther UI idea: In the publishers wiki, the tag stating the intended fetcher (e.g |
Hm, I'm reconsidering strategy - and adding along some important bits, including a system to partially clean up outdated twCards from circulating in the TWederation;
This speaks for separating the confirmation stuff from the tiddler itself. Confirmations lists Fetchers getting confirmation requests includes - "bundles along" - the confirmation request list - or - Fetcher twCards in publishers TW Now, the confirmation list isn't really in the twCard. It is a separate tiddler that perhaps shows up as a tab in the twCard or as a transclusion. This is so that different publishers only have the relevant list concerning the specific publisher himself and the fetcher. Fetched confirmations replace the status in the fetcher-specific confirmation list held by the publisher. And the information is presented perhaps as suggested in last post; coloring the tag accordingly :-) |
Problem
"Did the fetcher receive my messages? ...maybe something is wrong with my TW or settings? ...and there's a load of old messages I've (hopefully) sent, stacking up - can I delete them?"
Proposal
Confirmations - optional/voluntary on both publisher and fetcher side - that the message has been fetched. Thus the confirmation requesting publisher can fetch this confirmation (assuming the conditions are right).
Strategy
Concerned tiddlers have an optional field
fetchconfirmation : requested
. I'm uncertain at what point this is best added; e.g when tagging with an (intended) fetcher name or upon bundling.When un-bundling, this field value is, if permitted by fetcher, changed into
fetchconfirmation : <usernameOfPublisher>
. (or perhaps the whole field is replaced with e.g fieldfetchedfrom :...
).Possibly the confirmation is also added to the fetchers copy of the publishers twCard, building up an accumulated list of confirmations. (See more below)
(My original thought was to create a whole new "confirmation tiddler" for each confirmation but this seems overkill and would litter the TW. the confirmation is also meta-data IMO so it belongs to a tiddler.)
Mutual voluntary...ness...
Publisher side: Tiddlers that the publisher would like fetchconfirmation requests on have a
fetchconfirmation : unconfirmed
field. For starters this can be added manually but an idea is to have it automatically added either as the tiddler is tagged (or otherwise addressed) with a fetchers name, e.g *inmysocks or, perhaps, via some central list in the publishers tw where he can 'batch befield' tiddlers with this.Fetcher side; the //un-bundling mechanism// detects this field and, in the listing of "to-be-unbundled" tiddlers, displays checkboxes next to each tiddler that requests confirmation. By default it is checked, indicating that the field - on unbundling - will get value
usernameOfPublisher
. Manually unchecking the checkbox prevents adding this value.Obviously a field can be manually changed later anyway.
The reason it is better with
fetchconfirmation : usernameOfPublisher
than: usernameOfFetcher
or: confirmed
is because there may be multiple tiddlers with identical titles from different publishers. This way there is more chance that the publisher will get correct confirmation note.If overwriting is prevented - e.g by added timestamps in tiddler title - then I guess
fetch : confirmed
is more eloquent. (And perhaps changing it to befetch : <confirmation requested / confirmed>
) BUT... (se next paragraph)Checking confirmation status
To know if a tiddler has been fetched, the publisher would probably himself have to fetch the confirmed tiddler. This (ref to the BUT above) probably requires that the title has remained the same. At the same time, the original should probably not be overwritten (maybe the fetcher has made a content change, such as added his own notes to a fetched tiddler).
An idea might be to use the twCards; On the fetcher side, the confirmation is (in addition to the tiddlers
fetchconfirmation
field) added to publishers local twCard that the fetcher holds. The publisher thus imports his own twCard to see confirmations for tiddlers. Should probably be an accumulating shadow tiddler.When the publisher fetches "his own" twCard, this is during the fetching process changed so that the information therein is instead added to the fetchers twCard in the publishers TW. So the publisher peeks in his local copy of the fetchers twCard to get a summary of the confirmations.
In the publishers wiki, there might be a setting (particularly for personal communication) to have a concerned tiddler display perhaps a little yellow dot while unconfirmed and when confirmed, as detected in the twCard, it shows green instead.
The text was updated successfully, but these errors were encountered: