Journal Data Missing

[paul90]

I think some journal entries are missing data they should be holding.

1. Date for some forks
   • I can see the client does not add a date when forking to local storage - see https://github.com/fedwiki/wiki-client/blob/master/lib/pageHandler.coffee#L115 - need to check other local storage interaction.
   • I have seen some sites fail to add the date a fork was made ( @WardCunningham, this was on the site of Mike's you mentioned a couple of weeks ago). The code in this area does not appear to have changed since the node server was split off, so probably a path though the code that fails to add the date!?
2. When dragging (copy or move) an item between pages, on the same or different sites, the journal shows an 'add' but there is no information about where it was moved/copied from. Questions:
   • if the copy/move is from a forked page, should that also be recorded to propagate attribution?
   • do we need to add a quotation paragraph type (plug-in), so that if it is copies/moved it's citation moves with it?

[WardCunningham]

I have noticed these omission on occasion too. I believe they can all be traced to some question of semantics which I deferred. I once thought that forks to local storage deserved special treatment and should not be dated. I don't believe that now.

I once added the code to cite the 'site' of cross-site drags. It was buggy in some complicated way so I decided to discard it until pageHandler was refactored.

When we rely on the cc-by license for permission to mash up content then we should include the 'site' in the journal. I'd like to add a capability to mash up content from the public internet. In this case a type=quotation paragraph could be useful. Imagine dragging quotes from the BBC.

http://ward.fed.wiki.org/bbc-world-service.html

My head starts to hurt when I think of where in the edit flow this need for special attribution would be detected. It would be awesome if it just worked though.

[WardCunningham]

I have improved some code paths in pageHandler but there are many opportunities for simplification remaining. I have worked slowly here because many cases have order sensitivities due to the compounding of function. Let me mention a few.

• handles gets and puts
• handles origin (ajax) and local storage
• handles explicit and implicit forks
• handles successful and failed puts
• handles storage and dom journal updates

I would like to separate these functions into several layers where they can be inspected for correctness and more easily accommodate extension. These layers might be:

• observing and recording history in the journal
• applying storage policy such as fail-over
• performing storage operations to an abstract interface

The page data could move smoothly up and down this stack. However there is some situational awareness and some exception handing that must move up and down the stack too. I've yet to find the inspiration that would keep the one layer we already have from becoming three layers of equally brittle code. Accumulating experience can help. Auto-quoting the BBC is one more case to think about.

[WardCunningham]

I've tested the dating of forks in the following conditions identified by 1) page origin, 2) nature of fork, and, 3) destination of journal update. I found two cases where forks were undated. Pull #54 mentioned above fixes one.

• origin unowned local => undated (fixed)
• origin unowned dom => dated
• remote implicit server => undated
• remote implicit dom => dated
• remote explicit server => dated
• remote explicit dom => dated

The other case is more complex. When a remote page is implicitly forked (by editing) the edit action is annotated with fork:site which gets turned into a separate type:fork action by the server. Here we find the code for both ruby and node:

https://github.com/fedwiki/wiki-node-server/blob/master/lib/server.coffee#L451-L453
https://github.com/fedwiki/wiki-gem/blob/master/lib/wiki/server.rb#L235-L240

The ruby code dates back to the original project:

https://github.com/WardCunningham/Smallest-Federated-Wiki/blob/master/server/sinatra/server.rb#L232-L237

All of these server implementations share the problem that the server attempts to fetch the remote page. I will write another issue explaining why we should fix this and the date thing too.

[WardCunningham]

On further reflection, a better strategy might be to make ALL implicit forks go to local storage. If they were accidental, then they could be discarded with no harm to the origin server. If they were desired, then an explicit fork from local storage to the origin server will save the page in a single (additional) action. This approach has several practical benefits:

• avoids immediately overwriting of origin pages (mentioned already)
• sends the previously fetched page to the origin server (works better with firewalls)
• allows the client code to date the forks (where we started with this issue)
• discontinues use of server-side implicit forking (obsolete server logic can be deleted)
• avoids two rapid-fire ajax requests (probably why we bundled the fork to start with)

I can think of one disadvantage. There would be one additional action recorded: the second fork that moves the page to its ultimate destination.

[WardCunningham]

Page storage abstraction has been consider several months ago, including a survey of points where storage activity is initiated.

http://ward.fed.wiki.org/view/page-storage-abstraction