Hi Chris,

Some very interesting thoughts here!
 

> there's a plugin[1] that implements a concept known as 
>
remotebag[2] which probably fits in here somewhere
>

might not even be needed if TiddlyWiki itself does the cross referencing
when talking to a number of TiddlyWeb servers

one question is, at what point would a TiddlyWeb
go talk to remote bags if not through user interaction?

there could be some polling going on to cyclically pull updates
sounds a bit like messaging, although optimizing this process
might need some thinking about replicating / caching stuff,
e.g. only fetch tids where modified > last request.
so, you would essentially mirror the remotebag contents, read-only
perhaps not caching things older than X

Federation is something happens as a result of 
>
an aggregation of servers and clients that are aware of each others 
> existence. 
>
That awareness is the problem which needs to be solved/managed.
>

There are two ways to approach this...

   1. have TiddlyWeb do the *remotebag* talky-talky
   2. have TiddlyWiki talk to a number of TiddlyWeb instances
   and cross reference the tiddlers in some way,
   e.g. via fields that read like...
      - *reply-to*: http://unique.com#origin
      - *reply-to*: 
      http://unique.com/tweb/bags/{bag_name}/tiddlers/{tiddler_title}
   
A file:// based TW5 configured with awareness of multiple TiddlyWeb 
> servers[3] 
>
(or one TiddlyWeb server that holds knowledge of multiple TiddlyWeb servers)
>  
>
could self-configure to talk to those multiple servers and dynamically use 
> content from them. 
>
It doesn't strictly have to be file-based even.
>

Yes, I take it that there are db adaptors for TiddlyWeb.
So, storing tiddlers in bags and defining recipes does not require a purely 
file-based storage.
TiddlyWeb decides on how to pull the tiddlers and from where,
so all you need is to properly address the api, the rest is under the hood.

I've experimented with this latter idea a little bit with only one 
> server[4]. I think TW5 would need some adjustments to cleanly do this with 
> multiple servers but I can't see any huge technical barriers to it 
> happening. Content is relatively easy, plugin loading less so.
>

Right now, we're just talking content, imho.
But plugin loading should also work,
you just need to locally save that thing to your wiki and then reload.
Loading / updating plugins should be a conscious act.
However, talking to those remote servers might provide a mechanism
to indicate that there is an update for some plugin of yours... when in 
*authoring* mode.

I agree that once it becomes straightforward to take an existing TW5 
>
and make it talk to arbitrary places on the network 
>
some very interesting things will be possible.
>

I really think the syncer module(s) should allow multiple instances talking 
to distinctly configured stores... with appropriate conflict handling, i.e. 
store that content in some unique namespace where it doesn't conflict with 
the "locally owned" tiddlers, e.g.

$:/remote/origin-url/api-path

Locally owned meaning: some origin must be defined as the master for this 
TiddlyWiki, e.g. providing the tiddlers as-is, no system-namespacing.

The above would eventually hold a tiddler name at the very end. Some filter 
could extract all remote tiddlers that have the same name as a local one 
and appropriately show a conditional button in the toolbar which opens a 
popup containing a list of remote tiddlers ...when opened, a custom 
ViewTemplate shows this tiddler, but without all the $:/remote/foo... 
rather showing a clean Tiddler ui that hides the ugly title and clearly 
indicates that this tiddler came from someplace else, while pointing there.

Anyhow, ownership seems to be the key in what needs configuration within 
TiddlyWiki, i.e.

   - "Am I the owner of the content from a given remote server configuration
   ?"
      - *yes*: ok, I can fully CRUD — so long as the server allows me to
      - *no*: I can only read and duplicate into whatever is my own local 
      store
   - "Is this my master store?"
      - ok, so these are the tiddlers loaded without any namespace-prefixing
   
Best wishes, Tobias.

>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

Reply via email to