Tiddler-Based-Communication-Protocol
Tobias Beer
"I rather think what is missing is a defined protocol in terms
of syntax and semantics for tiddlers (i.e. exchange of tiddlers
between tw and server and different tw's)."
I do agree... when I was referring to serverside here [1], I did not
necessarily mean persistance. In fact - and I believe I somewhat
communicated that - what I find missing is the communication bit for
exchanging tiddlers... as you say.
If that indeed requires an initial protocol definition, then that's
the way to go. However, there sure needs to then be some kind of
serverside component that deals with all the required messaging in
order to - clientside - not only read and locally merge stuff in
whichever browser supports the frontend ...tiddlywiki-style. Of
course, at some point we'd also need a persistence layer... of which
certainly a few are ready to go.
So, yes... a well defined, standardized communication pattern
regarding tiddlers and their attributes may well be the thing in
need... only to then to be able actually implement anything in terms
of communication and eventually persistence components at some server
or another.
So then, maybe it's time to remove all thinking in terms of HTML, DOM
and JS for a moment from the picture and to concentrate on what things
really are those in need of being exchanged when talking about cross-
site-tiddler-communication.
Probably rather quickly we end up with a lot of what TiddlyWeb already
has implementations for, like roles, recepes, bags atop of the atomic
thing at the heart of it all... called a tiddler... and a
serialization that wraps the stuff and sends it across the web.
If these data are then communicated via some bloated XML or a perhaps
way more streamlined JSON pattern... that would not even have to be
part of the standard, but just different means to serialize all the
bits and pieces required for communication ...via some library
implemented in whatever serverside environment is to ones liking.
The protocol / exchange formats should be simple and clear, just like
the concept of a tiddler.
Could some TiddlyWeb Guru please share some thoughts?
Cheers, Tobias.
[1] http://groups.google.com/group/tiddlywiki/msg/2563bde3cc276ced
chris...@gmail.com
> Probably rather quickly we end up with a lot of what TiddlyWeb already
> has implementations for, like roles, recepes, bags atop of the atomic
> thing at the heart of it all... called a tiddler... and a
> serialization that wraps the stuff and sends it across the web.
>
> If these data are then communicated via some bloated XML or a perhaps
> way more streamlined JSON pattern... that would not even have to be
> part of the standard, but just different means to serialize all the
> bits and pieces required for communication ...via some library
> implemented in whatever serverside environment is to ones liking.
>
> The protocol / exchange formats should be simple and clear, just like
> the concept of a tiddler.
agree with what you've said.
TiddlyWeb already provides an architecture for moving tiddlers around
and it is pretty straightforward because it uses HTTP. And tiddlers in
TiddlyWeb are pretty easy to identify because the URI of the tiddler
_is_ the tiddler. This is all standard and entirely intentional
aspects of TiddlyWeb being a true web application (i.e. psuedo-
RESTful).
The serialization model in TiddlyWeb makes it possible to send and
receive tiddlers however you like and persist them in a way that is
independent of how they are sent. Again, standard and entirely
intentional aspects of being a good web app.
I think the issues that "tiddlygrp" and a few others have pointed out
are:
1. There's no standard format.
2. Tiddlers don't have UUIDS, thus lending themselves to free-floating
in a global distributed network.
On 2, that's a simple matter of programming. We can make it so
tiddlers have uuids, but then you need to decided if/when those uuids
change. Do you get a new uuid per revision? Does the uuid stay the
same or change if the tiddler is renamed? Or do you keep a history, as
in proper version control and enable some git like handling?
On 1, I personally think tiddlers are both simple enough and have
establish enough of a precedent that we can go with what's already
being done along with some light improvements. A tiddler is a lightly
nested dictionary:
* title: string
* modifier: string
* creator: string
* modified: date§
* created: date§
* text: string (binaries encoded as needed)
* type: string (content-type of text)
* revision: an arbitrary identifier for this revision
* tags: list of strings
* fields: dictionary of arbitrary string:string pairs
§ how to represent dates would need to be resolved
The shortcomings in the above is that this tiddler, internal to
itself, does not disambiguate itself from another tiddler with the
same title. In TiddlyWeb this is handled by the bag concept, but that
is presumably not a universal concept in the tiddlyverse. Thus some
kind of uuid, or uri would be desired as well.
OR it's entirely reasonable just to say "the inter-server transport is
Atom", because that would work too. Atom is capable of representing
tiddler just fine (with some tweaks for arbitrary fields). Or perhaps
JSON activity streams.
Note that most of this "syntax and semantics for tiddlers" was driven
by the model established in the TiddlyWiki AdaptorMechanisn, which
adapts server content (of many types) to TiddlyWiki Tiddler objects.
TiddlyWeb's understanding and modeling of a Tiddler object is quite
similar but a bit different (to deal with bags and recipes and real
revisions). The difference, though is easily handled at the interface
between TiddlyWeb's core and the serializations that it uses for
transport.
Very happy to answer more specific questions, but without some
direction I'm not sure what else to say.
tiddlygrp
Chris put some ideas forward for the tiddler definition. I like it,
because it is a concrete idea. Some additional thoughts:
tiddler has a type field (content type) and maybe also needs a field
for the encoding.
There is probably need for a field stating the spec revision to which
this tiddler conforms (for future upgrades of the tiddler
communication protocol)
Currently tw has some fields beginning with server. Do we need them?
I thing the most important are the definition of uuid fields and their
semantics and working together with tw, including the ability to track
changes and the history of where the tiddler came from. I think this
is non trivial.
Ward has done some work on this in his federated wiki project, see:
https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Federation-Details
https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON
https://github.com/WardCunningham/Smallest-Federated-Wiki
Basically his "pages" are equivalent to a tiddler.
chris...@gmail.com
> I thing the most important are the definition of uuid fields and their
> semantics and working together with tw, including the ability to track
> changes and the history of where the tiddler came from. I think this
> is non trivial.
Can you give a few more details on what the communication protocol
would be accomplishing? I acknowledge that it would be cool to do,
in the abstract, but knowing some more concrete reasons for having
it will help to understand the structuring that we need to do.
I ask because earlier this year I was getting quite keen on
federation in general, and federated social web protocols, but over
time I've come to wonder about the extent to which they are really
necessary above straight up HTTP and hypertextual links. In the FSW
world, federation has come to mean distributing copies of stuff all
over the place. I think this is entirely regressive and
counter-productive on an open and public web. We don't want copies
of content, we want more links (with links that actually work), and
more servers.
Ward's information makes it pretty clear that part of the goal in
his stuff is a collaborative workflow. Is this the sort of things
you are thinking about?
In that context, how important is tracking changes and history
compared to the content itself. I've been working on collaborative
content systems for a long time now and one of my observations is
that strict content tracking is far more important in code than it
is in narrative. And not only that, because of the structure of code,
tracking the changes is far _easier_.
Given that I keep finding myself coming back to a situation where if
the content is fairly unstructured human communication what we need
is just accessibility.
In a tiddler context that means URIs for individual tiddlers with
good capacity to link.
Can you provide a use case or user story that fleshes out the need
for what you describe above? I'm not saying it doesn't exist, I'm
sure it does, I would just like to understand it more clearly.
--
Chris Dent http://burningchrome.com/
[...]
tiddlygrp
the example of Ward's federated wiki was chosen because he has already
build a simple json representation of pages (something like a tiddler)
with uuid and semantics to track changes. This could be easily
adapted for tw.
In my view uuid's are something for the computer to track. They
should be used for versioning and disambiguation etc. For the user
the tiddler names are more important. So we need to define their
relation.
some replies follow inline:
On Nov 12, 3:00 pm, chris.d...@gmail.com wrote:
> On Fri, 11 Nov 2011, tiddlygrp wrote:
> > I thing the most important are the definition of uuid fields and their
> > semantics and working together with tw, including the ability to track
> > changes and the history of where the tiddler came from. I think this
> > is non trivial.
>
> Can you give a few more details on what the communication protocol
> would be accomplishing? I acknowledge that it would be cool to do,
> in the abstract, but knowing some more concrete reasons for having
> it will help to understand the structuring that we need to do.
>
> I ask because earlier this year I was getting quite keen on
> federation in general, and federated social web protocols, but over
> time I've come to wonder about the extent to which they are really
> necessary above straight up HTTP and hypertextual links. In the FSW
> world, federation has come to mean distributing copies of stuff all
> over the place. I think this is entirely regressive and
> counter-productive on an open and public web. We don't want copies
> of content, we want more links (with links that actually work), and
> more servers.
think in some way history should be preserved for that. I am not
advocating replacing links, but a mixing up tiddler content from
different hosts is very powerful i think.
I also think it is important to view the history of a tiddler: what
was written here 2 years ago?
>
> Ward's information makes it pretty clear that part of the goal in
> his stuff is a collaborative workflow. Is this the sort of things
> you are thinking about?
>
> In that context, how important is tracking changes and history
> compared to the content itself. I've been working on collaborative
> content systems for a long time now and one of my observations is
> that strict content tracking is far more important in code than it
> is in narrative. And not only that, because of the structure of code,
> tracking the changes is far _easier_.
>
> Given that I keep finding myself coming back to a situation where if
> the content is fairly unstructured human communication what we need
> is just accessibility.
>
> In a tiddler context that means URIs for individual tiddlers with
> good capacity to link.
version could map to a uri.
I think it should not be required for a server or tw to track al
history. But i think it is prudent and quite easy (at the onset) to
allow for a tiddler definition which allows this history and merging/
fork tracking. A server just can ignore it. But you can also use it
when you want.
> Can you provide a use case or user story that fleshes out the need
> for what you describe above? I'm not saying it doesn't exist, I'm
> sure it does, I would just like to understand it more clearly.
>
tiddlywikki.com page, take it to my tw and change it. Jeremy wants to
take back some of my changes into the original tiddlywiki.com page.
Without a tiddler protocol supporting this, it means using something
like diff and patch which is for experts only.
Another story: I predict in 2011 that in 2012 there are more tw
users. In 2012 i update the tiddler to reflect new data. A reader
can then look up in tiddler history what I precisely said in 2011.
Another one: I use tw for todo lists. When a job is done it gets
marked. Once every month i clean the list of done jobs. But what did
i do a year ago? just look up the history. And now my friend likes
the system. He just forks the tiddler to his own tw, keeping a
history reference to my tiddler. If i improve the system, he gets
(actually he queries my tw for an update) a notification, because his
tw is still tracking my tiddler because it keeps "federated server
history".
Hope that makes my thoughts more clear.
Jeremy Ruston
I'm also drawn to the value of robust history tracking for tiddlers,
and agree that that is one of the key roles for servers in the
TiddlyVerse.
I've found myself less keen on making UUIDs be a part of the core
definition of a tiddler. I can see that there are some scenarios that
need UUIDs to work, and so I'm interested in ensuring that the core
definition of a tiddler allows for the use of UUIDs (the simplest way
being to choose to use UUIDs in the title field, and use a different
field for the human readable title). I don't see a role for UUIDs in
the TiddlyWiki core, rather I see their usage being driven by server
side (or federation) concerns.
Adding UUIDs to the core tiddler model would make tiddlers more
specific to a particular class of servers and/or federation systems.
Some of these systems might well want slightly different semantics for
UUIDs. If the tiddler concept is to be universal then I think it needs
to be surgically minimal: it is primarily about cutting up information
into little chunks, and the details of particular persistence or
federation approaches using UUIDs shouldn't intrude on the core model.
We want the idea of a tiddler to be as simple as possible so that as
many people as possible can agree on it.
Best wishes
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
chris...@gmail.com
> Another one: I use tw for todo lists. When a job is done it gets
> marked. Once every month i clean the list of done jobs. But what did
> i do a year ago? just look up the history. And now my friend likes
> the system. He just forks the tiddler to his own tw, keeping a
> history reference to my tiddler. If i improve the system, he gets
> (actually he queries my tw for an update) a notification, because his
> tw is still tracking my tiddler because it keeps "federated server
> history".
>
> Hope that makes my thoughts more clear.
It does, somewhat, yes, but what I'm hearing is a need for more
robust revision handling for tiddlers, not a need for a tiddler
communication or federation protocol. I'm fairly certain that most
of the information you're after can be communicated (at least
initially) via an Atom feed between related servers.
Full featured history that survives renames and tracks forks
requires persistent (and thus meaningless) identifiers. This is
pretty much a fact, so can be taken as a given I suppose. It's
something that's always been in the back of my mind for implementing
with a TiddlyWeb store but I've always put off because it was a
layer of complexity that I wanted to put off until either I was
smarter or somebody else smarter would do it themselves.
But what then is the actual meaning, semantics or process of
"federation" and the associated use cases which require a tiddler
communication protocol (in excess of HTTP/Atom/stuff what already
exists)? That's what I'm really after.
tiddlygrp
@Jeremy: For me a tiddler uuid has nothing directly to do with a
tiddler. At creation time put a uuid in a field in the tiddler is the
absolute minimum I think tw should do. A lot other stuff can be done
server side. The advantage of creating a uuid at tiddler creation
time is that then it is "uniquely" marked. Then the tiddler might
move to a server (or not). My thought is that by putting the uuid in
tw, all servers should support this standard. If each server builds
up its own uuid semantics, than its hard to get federation and sharing
of tiddlers peer to peer without a server.
@Chris What I mean by a tiddler communication protocol is more a set
of conventions than a tech specification like http or tcp/ip. In the
protocol we need: which fields are part of a tiddler, which fields
are optional, what is the meaning of the fields (e.g. changes the uuid
with each edit? Or is there a version identifier?). In you first
post from nov. 11 you make a proposal for such a protocol as I mean
it. I suggest to additionally look at Ward's pages definition in
JSON, because it is very similar to a tiddler and already solves in
some way versioning, uuid's and tracking servers. How you then
actually send the tiddlers? Probably just http/atom as you stated.
And probably the uri/url's to get a tiddler will be server dependent.
That is not a problem. The problem to be solved it what do you get
back when you call GET /some.tiddler.json? Which fields are in the
tiddler and what do they mean?
Poul
tiddler depends on how you define it's identity. Which has 3 aspects
that I can think of:
1: Who wrote it ?
2: Where does it physically or logically reside ? You should be able
to edit it whether offline or online - ideally the merge should happen
automatically.
3: What's the history ?
Each of these may have simple answers in one use case, but complex
answers in another:
1: A tiddler may have been modified by several people.
2: The need for it to reside on a server and/or on a pocket device at
various points in time is perfectly valid.
3: I don't think the title is a sufficiently robust handle in all
cases, obviously not if you require the ability to rename it and still
preserve history.
Basic TiddlyWiki of course relies on the combination of a title and a
physical location for identity. Which is a healthy idea from the point
of view of the user working with a single, classic kind of document,
but it does present some problems as soon as the context changes:
* collaborative editing.
* federating content.
* simply copying it to a different location and forgetting where the
most recent version is...
One of the desirable aspects of TW is that it breaks the document into
more manageable pieces, that ought to make the process of merging
changes more automatic. Adding the UUID goes some way towards reducing
this problem, but it doesn't solve it completely. At some point you
are still going to be faced with the problem of branching and have to
decide how you want to deal with it.
Giewiki uses UUID's and version numbers to define identity and
history. It allows you to take a page offline, edit it as a classic
TiddlyWiki and merge your changes back as long as there is no
conflict. Conflict is detected based on tiddler version numbers, but
it currently does not offer any help in resolving them, except by
making it easy to compare the text of any two versions (without
presenting them as separate tiddlers like I believe TiddlySpace still
does). It naturally still retains the human-friendly requirement that
the titles of the tiddlers be unique within a document. The versioning
feature also allows you to specify that a version other than the most
recent is the current one (i.e. served by default). I do not reserve a
handy syntax for including a version number in a URI -that would be
via the query string. Most recently, I've built an auto-save feature
on top of this, and added the ability to customize which fields should
be listed in the version history.
A more ambitious plan to support the same editing experience whether
online or offline (using the GAE SDK server) still sits somewhat low
on my to-do list together with the idea of putting a custom Python
interpreter into IOS - dunno if that would be allowed if restricted to
just run your server.
;-) Poul
http://code.google.com/p/giewiki/ || http://giewiki.appspot.com/
Poul
a tiddler it has created, that uuid should be used also by any server
onto which is is put. That's what uuids are for. And no, the uuid
should never change unless the user decides to copy the tiddler to a
different URL on the same server, in which case it probably should.
But a full-featured server should also allow a mechanism by which the
same tiddler appears on several pages as in unix-style soft links -
but probably not allow it to be edited through either without
explicitly breaking the link.
:-) Poul
Tobias Beer
Hi Chris,
I would suppose there is a reason for most all database(-like) systems
to equip "records" (a tiddler being a somewhat generic record) with a
persistent id.
Tiddlywiki kind of fails in that regard and that is a bummer for quite
many things, not only those that go beyond the single-file-boundary.
Of course, the title could be (ab)used for the purpose of a uuid, but
then... where is the title or human-readable-name-for-the-thing?
For example, today a "permalink" refers to some content behind a uri.
But what if what I really need is a permanent link to the resource I
was given the moment I requested the permalink? Sure, maybe all that
is required is some well defined version handling which would point
from an old location to a new one (as would be the case for renaming),
perhaps adding yet another version number and some "deprecated"
identifier to the no longer valid resource... until otherwise a new
reanimated version is saved with new "content".
tb
chris...@gmail.com
> I would suppose there is a reason for most all database(-like) systems
> to equip "records" (a tiddler being a somewhat generic record) with a
> persistent id.
I'm hundred percent in favor of tiddlers having a persistent id. When
putting TiddlyWeb together I wanted to tiddlers to not only have a
unique id on the server, I wanted them to be unique across the
universe of TiddlyWeb servers _and_ for there to be, in addition to
/bags and /recipes -based tiddlers URIs, another /tiddler/{id} route.
That id would have been a uuid and would have been a first class
attribute of the tiddler.
This idea was rejected.
So given that there is at least some people who support the idea of
ids, and "tiddlygrp" says that atom might work as transport, or a
variety of other things, then the remaining open issue is tiddler
attribute handling?
chris...@gmail.com
> @Jeremy: For me a tiddler uuid has nothing directly to do with a
> tiddler. At creation time put a uuid in a field in the tiddler is the
> absolute minimum I think tw should do. A lot other stuff can be done
> server side. The advantage of creating a uuid at tiddler creation
> time is that then it is "uniquely" marked. Then the tiddler might
> move to a server (or not). My thought is that by putting the uuid in
> tw, all servers should support this standard. If each server builds
> up its own uuid semantics, than its hard to get federation and sharing
> of tiddlers peer to peer without a server.
Yes, agree with all this. If any tiddlers are gonna have uuids it is
far better if _all_ tiddlers have them.
> And probably the uri/url's to get a tiddler will be server dependent.
> That is not a problem. The problem to be solved it what do you get
> back when you call GET /some.tiddler.json? Which fields are in the
> tiddler and what do they mean?
Okay that makes more sense. I'm not sure how or who to decide the
syntax and semantics.
Måns
wonder why the creatorfield never made it into the core?
http://trac.tiddlywiki.org/ticket/471
http://www.tiddlytools.com/#CoreTweaks "471 'creator' field for new
tiddlers"
I'm using it on TS: http://d-minus.tiddlyspace.com/ - and being able
to distinguish between an original author and who made the last edit/
modification seems very essential... (imho)
Cheers Måns Mårtensson
Tobias Beer
I believe you are quite on-topic. While a unified model for tiddler-
versioning would somewhat implicitly cover your issue, some
information on tiddler "origin" [or a certain number records on
previous location(s) / owners / timestamps] might be valuable at any
moment, so that one (server) is not required to try and trace back all
of a theoretically infinite number of potentially long lost resources.
tb
On 14 Nov., 23:13, Måns <humam...@gmail.com> wrote:
> Don't know if this is related at all - sorry if I'm offtopic however I
> wonder why the creatorfield never made it into the core?
>
> tiddlers"
>
> I'm using it on TS:http://d-minus.tiddlyspace.com/- and being able
Tobias Beer
I would say one good tenet for such a universal tiddler convention /
communication protocol would have to be that the model is adaptive or
"optionally extensible", whatever you want to call it.
What this means is that, while certain information would probably
define a basic set of what a tiddler is, there should be universally
defined extensions to this basic reference frame, e.g.
- uuids
- versioning
- forking / branching
- etc...
In contrast to most W3C specs ...which one usually expects "modern
browsers" to adapt in full... these should not be conventions that are
required for all tiddler "stores" or servers delivering tiddlers under
a given resource location.
Instead, there would be a basic store, in other words a static,
traditional TiddlyWiki which does not (quite) cater for the above
mentioned extensions. And there would be implementations of such a
unified tiddler protocol which qualify a server to do any or all of
these yet-to-be-identified-standard-extensions, either individually or
in full.
There should be naming conventions and conventions around how servers
meeting one set of these universal tiddler conventions talk to those
that implement a different set of these extensions... in terms of
"graceful degradation".
In other words, there should be universally agreed upon ways for how a
store that knows how to do versioning treats another store which
doesn't. This of course implies that people are actually aware of the
implications of such a scenario... in detail ...and that standard
methods of dealing with have been specified upfront and thus
implemented.
...so, to answer Chris' question... all the use cases for such a
convention / protocol stem from answers to questions about how
different implementations communicate around the thing that a tiddler
represents... with respect to a basic standard and then a number of
extensions each server "joining the conversation" along with the
resources they're dishing out bring to the table.
tb
tiddlygrp
Thanks Poul for your reply. As you said different use cases for
uuid's and identity would lead to different designs. I think we
nonetheless should standardize on something and say tiddler standard
version 1 somewhere in a tiddler field. Then we can upgrade later on
always.
@Tobias Your last post makes it as if it is a heavy burden to do the
uuid stuff which would be better done on a server. I don't think so.
It can (should!!) be done client side. And you propose a quite heavy
process with naming conventions and standards. I would rather define
a minimum and leave extensions open.
Client side examples which would benefit from a minimal uuid standard
are: there where (are) some tw's who exchange tiddlers through rss
with no server explicitely involved. The same goes for upgrading a
tw. How does tw know if a plugin has changed? Some brittle
convention. If there was a machine readable date field and uuid a tw
could "know" that a plugin was newer. I think in the tw universe it
is important to have the basic uuid capabilities in the client (tw).
@Chris and others
I mentioned Ward's federated wiki quite some times because he has a
concrete specification:
https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON
{
"title": "Welcome Visitors",
"synopsys": "The first federated wiki page written and often first
page viewed.",
"story": [
{
"id": "7b56f22a4b9ee974",
"type": "paragraph",
"text": "Welcome to the federated wiki. This page was
first drafted
Sunday, June 26th, 2011, at indie-web-camp. You
are welcome
to copy this page to any server you own and
revise its welcoming
message as you see fit. You can assume this has
happened many
times already."
},
{
"id": "8d8a6cf94b72e848",
"type": "image",
"width": "300px",
"height": "200px",
"caption": "Ward's Lighted Electric Bike at [http://
www.shift2bikes.org
/cal/viewpp2011.php#24-2144 Pedalpalooza]",
"url": "/lit-and-loud.jpg"
}
],
"trail": [
"http://fw.indiewebcamp",
"http://c2.com/~ward/fw"
],
"journal": [
{"type": "edit",
"id": "15411293042b2735",
"text": "the paragraph now says this"}
]
}
This looks somewhat similar to the tiddlyweb JSON for a tiddler. The
main difference is the use of the id's (uuid's) and the journal. the
journal is what helps do track changes and I would propose to add it
additionally to uuid's. But I would leave using the journal
optional. That would mean there is a standard way to track history
and merges, but a client or server is not obliged to use it.
A creator/editor field would be nice also. However without
authentication/cryptographic signing it probably will be forged
sometime and it will be more of a convention than a reliable
authorship field.
Now also cryptographic signing could be nice for tiddlers and I could
think of a lot of additional possibilities. Therefore the tiddler
field protocol should be extensible with optional fields which can be
ignored at will through a client or server.
The main problem is as Chris stated:
>syntax and semantics.
Jeremy Ruston
> tiddler. At creation time put a uuid in a field in the tiddler is the
> absolute minimum I think tw should do. A lot other stuff can be done
> server side. The advantage of creating a uuid at tiddler creation
> time is that then it is "uniquely" marked. Then the tiddler might
> move to a server (or not).
I like the way that people explore using TiddlyWiki with different,
pre-existing serversides, such as the current experimentation with
CouchDB, and Zooko's experiments with Taho-LAFS.
My concern is that different serversides may have somewhat different
semantics for their UUIDs, and it would be bad for TiddlyWiki to get
in the way of experimenters by imposing a slightly incompatible way of
using UUIDs.
I know it's not quite the same thing, but a related thing that I would
like to see standardised is the field that identifies the global URI
for the canonical copy of the content of a tiddler. It seems
reasonable for future TiddlyWiki to directly support clean, RESTesque
serversides like TiddlyWeb by using HTTP verbs on that URI.
> My thought is that by putting the uuid in
> tw, all servers should support this standard. If each server builds
> up its own uuid semantics, than its hard to get federation and sharing
> of tiddlers peer to peer without a server.
I'm not sure that fixing an implementation within TiddlyWiki is the
best way to find the optimum federation architecture. The core of the
tiddler concept is pretty well established now, as Chris says, there's
more than one implementation that we can use as a reference. Let's
record what we've got as the core tiddler standard, and make sure we
leave space for the experiments on federation and sharing.
Part of my resistance is that I'm concerned that the consequences of
enforcing UUID semantics on the client seem complicated. They seem
straightforward enough when thinking in terms of how the
synchronisation works, but I'm less confident when it comes to the
user interface; on the face of it, UUIDs would allow multiple tiddlers
with the same title field to exist. How would it choose the right one
for navigating links? How would users access the others? I'm
disinclined to start grappling with all of that when it's not strictly
a prerequisite for exploring the actual underlying federation and
sharing mechanisms that so many of us are interested in.
Best wishes
Jeremy
tiddlygrp
some reply to Jeremy inline:
On Nov 15, 7:16 pm, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> I like the way that people explore using TiddlyWiki with different,
> pre-existing serversides, such as the current experimentation with
> CouchDB, and Zooko's experiments with Taho-LAFS.
>
> My concern is that different serversides may have somewhat different
> semantics for their UUIDs, and it would be bad for TiddlyWiki to get
> in the way of experimenters by imposing a slightly incompatible way of
> using UUIDs.
for tw, I imagine it would be a long random looking string. The exact
format of this string is not so important, as long it is not equal to
some other. Obviously different server sides will have different
uuid's, and they can keep it in an optional sever field in the tiddler
if required. So I think this server uuid can be different from the tw
uuid, but it would be nicer (and really preferable) if they were the
same.
>
> I know it's not quite the same thing, but a related thing that I would
> like to see standardised is the field that identifies the global URI
> for the canonical copy of the content of a tiddler. It seems
> reasonable for future TiddlyWiki to directly support clean, RESTesque
> serversides like TiddlyWeb by using HTTP verbs on that URI.
>
server sides, I think that would be a grave limitation. Think of
other server access methods (protocols) like WSDL, XML-RPC, http with
cgi and RSS. These are not RESTy, but interesting for tw
> > My thought is that by putting the uuid in
> > tw, all servers should support this standard. If each server builds
> > up its own uuid semantics, than its hard to get federation and sharing
> > of tiddlers peer to peer without a server.
>
> I'm not sure that fixing an implementation within TiddlyWiki is the
> best way to find the optimum federation architecture. The core of the
> tiddler concept is pretty well established now, as Chris says, there's
> more than one implementation that we can use as a reference. Let's
> record what we've got as the core tiddler standard, and make sure we
> leave space for the experiments on federation and sharing.
fields, then sharing and federation is hard. As long as the format of
the uuid is basically a long string, the format of this uuid is of
minor importance. In my view federation really starts at the
standalone tw. You then might put tiddlers on one server. Then you
might change the tiddler and put it on a different server. And then
you might email a tw to a friend. This is some form of federation,
where a server based uuid not really helps, if you want to track the
identity of the tiddlers.
>
> Part of my resistance is that I'm concerned that the consequences of
> enforcing UUID semantics on the client seem complicated. They seem
> straightforward enough when thinking in terms of how the
> synchronisation works, but I'm less confident when it comes to the
> user interface; on the face of it, UUIDs would allow multiple tiddlers
> with the same title field to exist. How would it choose the right one
> for navigating links? How would users access the others? I'm
> disinclined to start grappling with all of that when it's not strictly
> a prerequisite for exploring the actual underlying federation and
> sharing mechanisms that so many of us are interested in.
>
allow for tiddlers with different titles to exist, as it is forbidden
in tw now. It would be just an extra field. In fact just introducing
a uuid field needs no user interface. And the problem of different
tiddlers with the same name doesn't change if they have different
uuid's. However uuid's could help to distinguish if there were a user
interface. Have a look at Ward's wiki. As a user you never see the
uuid, it is just used by the client and server to track changes and
different pages.
The uuid is important to establish a standard a server or another
client can count on.
chris...@gmail.com
> For the client tw adding a uuid doesn't matter directly. It wouldn't
> allow for tiddlers with different titles to exist, as it is forbidden
> in tw now. It would be just an extra field. In fact just introducing
> a uuid field needs no user interface.
Yes.
> The uuid is important to establish a standard a server or another
> client can count on.
Yes, something that has been bewildering me in the back and forth
about this is the discussion about "semantics of uuids". If we're
talking about uuids in the RFC 4122 sense or in the sense of
universally unique identifiers then the exact point of having such
things is because they _don't_ have semantics.
An identifier which is persistent and unique may not have semantics.
So question really becomes one of representational syntax, and
tiddlers already provide us with the fields attribute and if we want
deep coverage we have to use uuid4 (as it can be done without access
to the hosting system) and since we are using fields the stored
information must be a string, of hex digits.
In Python that's:
>>> import uuid
>>> str(uuid.uuid4())
'0d9b98c0-5f73-45eb-ac4a-386d445905e3'
The goal of an identifier is not to provide meaning or activity, it
is simply to allow something to be identified in a process. In a
universe of tiddlers, the tiddler title can _never_ be the id
becuase it will never be unique. The host of the tiddler plus the
title can never provide an id either, because we want tiddlers to be
able to move. So you have to make the tiddler have a unique id,
without meaning.
And, if you want that id to actually work as an identifier througout
the entire lifecycle of the tiddler where it may go or do, it _has_
to be created when the tiddler is born.
Similarly, in order for the id to remain "safe" it must _never_
encode information about the tiddler in itself. No hash of the title
and host or anything like that. Doing so means that the identifier
has gained semantics and when it does, it isn't a _universal_
identifier any more, and in order for federation (migratory
tiddlers) to work they have to have identifiers that are universal.
PMario
tiddler title. All TW core functions will work quite well.
The only problem will be, the users.
a)
If you need to link a tiddler in text, you'll have to create a
[[prettyLink|0d9b98c0-5f73-45eb-ac4a-386d445905e3]] to make a tiddler
accessible and also "human readable".
b)
<<list filter [tag[0d9b98c0-5f73-45eb-ac4a-386d445905e3]]>> will work
perfectly well. But IMO "no" user will want to type it. It simply is
error prone.
c)
Human users want to have "pretty links", which makes stuff
complicated.
If you don't want to use the tiddler.title as an UUID, you'll need to
rewrite most of the core functions. But all this stuff has to be
programmed. Since the underlaying system doesn't force you to do it,
nobody will do it. It's as simple as that.
UUIDs can't be optional. If they are optional, you'll need all core
functions twice, or/and the internal handling is more complicated.
eg:
<<list filter [tag[myTitle]]>>
<<list filter [tag[U-U-I-D]]>>
Since the links that are created by the list macro, need a different
internal handling, the core will be even more bloated. ....
Point a) and b) could be solved by an advanced editor, that does the
translation for the user. But it has to be programmed. ...
Just wanted to throw some thoughts to this topic ;)
have fun!
mario
chris...@gmail.com
> As Jeremy said the easiest way to use UUIDs would be, to use it as a
> tiddler title. All TW core functions will work quite well.
No, not at all. It is not the easiest, and it would break everything.
Because the uuid isn't there for
> [[prettyLink|0d9b98c0-5f73-45eb-ac4a-386d445905e3]] to make a tiddler
this
> <<list filter [tag[0d9b98c0-5f73-45eb-ac4a-386d445905e3]]>> will work
or this
It's there for identification. That's all. It's not a name nor an
address nor a label.
> If you don't want to use the tiddler.title as an UUID, you'll need to
> rewrite most of the core functions. But all this stuff has to be
> programmed. Since the underlaying system doesn't force you to do it,
> nobody will do it. It's as simple as that.
No, if the uuid a field, _nothing_ needs to change in tiddlywiki.
Nothing at all.
> <<list filter [tag[U-U-I-D]]>>
Why would you ever do this?
Tobias Beer
server, hence serving tiddlers in a predefined way.
In other words, while of course one would expect there to be some
client for editing tiddlers, it always is a server that delivers these
uuid's, since they are stored in tiddlers and thus delivered in
whatever serialization or representation is being used.
Consider this scenario: You are supposed to aggregate tiddlers from
different sources by calling some webservice with a given set of
parameters, e.g. qualified sources of tiddlers, parameter that asks
for a specific function to be performed, and some output format the
webservice is to use to dish out whatever he had aggregated / computed
on the grounds of those source tiddlers.
Now begins the fun... on which tiddler standard is this WebService to
deal with the tiddlers in these sources? Can it actually perform his
function or does it require UUIDs, versioning, branching capabilities
to perform his job or include any source tiddler for that purpose?
The same goes for the output... if you have no means to specify the
kind of output you desire, and this output might well be (a bag of)
tiddlers or some serialzation thereof... what are you going to
implement?
This is why a communication protocol is actually required, so that web
based services know what to do with the tiddlers they get in or how to
push things back once they're done doing their thing... assuming that
at least one side of the function, input or output, indeed involves a
requirement for a tiddler based standard to rely on.
tb
FND
leave much else for me to say.
> I would argue that also a standard TiddlyWiki is dished out via some
> server, hence serving tiddlers in a predefined way.
I don't understand the meaning of this. Are you simply saying there has
to be a common format for tiddlers - we already have that, though it's
extensible of course (I doubt anyone thinks that's a bad thing).
> In other words, while of course one would expect there to be some
> client for editing tiddlers, it always is a server that delivers these
> uuid's, since they are stored in tiddlers and thus delivered in
> whatever serialization or representation is being used.
This primacy of servers seems like the wrong approach. The point of
UUIDs is that anyone can generate them. There doesn't even have to be a
server involved (think exchanging tiddlers via e-mail, thumb drives or
numbers stations).
> Consider this scenario: [...]
Unfortunately, I can't make too much sense of this either right now.
-- F.
Tobias Beer
> Why would you ever do this?
upon titles. Perhaps it would be based on both at the same time if, as
jeremy suggested, titles were being abused for the purpose, but then
again, why would it be called a title, if in fact it were a uuid or,
if the title were used as a uuid, where to find a human readable title
for the thing?
So therefore, as Mario rightfully so points out... if uuids were just
another field, then there would be no core support to make use of them
in any of the standard makros or functions.
tb
Tobias Beer
only as something that is simply served as is, but rather "cooked" or
computed on the fly as in the case of TiddlyWeb, then you should get
the idea ...regardless of whether my understanding or use of
terminology with respect to realworld webservice implementations might
be rather poor.
tb
PMario
tiddlerName | UUID
fruits | AAAA
apple | BBBB
banana | CCCC
BBBB is tagged AAAA
CCCC is tagged AAAA
<<list filter [tag[AAAA]]>> will create a list:
* BBBB
* CCCC
with the right list macro and a lookup table it will be:
* Apfel
* Banane
Since I only use UUIDs the tiddlerName is not important anymore. It
can be created using a lookup table that does translations if needed.
Also changing the tiddlerName doesn't break any "prettyLinks" nor does
it break tag lists, nor does it break a tiddlers address.
So, in my thinking UUIDs could be used for everything. The
tiddler.title's are "hollow words".
-m
Poul
attached to it, I'm not sure that it would even make sense to agree on
what the name should be. Giewiki, for example, uses 'id' for what has
a UUID format, but without any guarantee that the associated content
is the same - indeed, you also have to specify a version number, and
even then, a server might allow a tiddler to be changed without
incrementing the version number.
But if anyone can think of an assertion that can safely be made if you
can identify a specific field as being a UUID, please tell me.
:-) Poul
Tobias Beer
> can identify a specific field as being a UUID, please tell me.
a protocol around communicating about tiddlers that tells you exactly
how it is defined, for example in the case of giewieki.
This protocol that I am talking about is not some serialization format
for tiddlers. Instead, it gives instructions on how to access any
resource that provides them by telling you what you can expect from
the resource once you do access it.
Let me try and to propose a draft that makes my line of thinking more
clear:
tidcom:{
version:"http://tidcom.org/v1",
format:"json",
standard:"http://tidcom.org/tiddler/v1",
extensions:{
creator:{
lookat:'field',
params:{
field:'creator'
}
},
},
uuid:{
lookat:'field',
params:{
field:'uuid'
}
}
versioning:{
method:'v1/versioning/ver1',
params:{
foo:'bar',
baz:'mumble'
}
}
branching:{
method:'v1/branching/bra1',
params:{
frotz:'gronk',
hello:'world'
}
}
}
So, the protocol defines the semantics used at some tiddler store -
semantics the variants of which are well defined in some "universally"
agreed upon, evolving standard protocol - that tells you, for example,
how versioning is being implemented. So, when you are referencing to a
source of tiddlers you would communicate this protocol and the
receiving end would have a precise clue of what exactly you're talking
about, because...
http://tidcom.org/v1
...would be the place that tells you exactly that.
There certainly are ways to streamline the suggestion above, for
example, a tiddler standard v0 could refer to the first tiddler
definition that didn't even have fields, v1 could include fields, v2
could include a uuid and creator field, etc... so that you wouldn't
have to specify these things under "extensions". Same goes for
versioning... if a given standard vX entailed a standard versioning
and branching definition, then there would be no need to specify these
things in the protocol, unless you had to specify, say, some required
parameters that are required to define your exact versioning pattern.
Makes sense?
tb
chris...@gmail.com
>>> <<list filter [tag[U-U-I-D]]>>
>> Why would you ever do this?
>
> Because with uuids disambiguation would be based upon them and not
> upon titles.
Why? Adding a uuid _can_be_ for disambiguation within a tiddlywiki,
but it doesn't _have_to_be. In the use case we are considering
(federation, inter-wiki communication, etc) there's no requirement
that tiddlywiki's behavior change internal to itself. The uuid is for
asking "is this tiddler the same as that tiddler". Where/when that
question is asked is within our control, and need only happen at the
wiki bounary.
> So therefore, as Mario rightfully so points out... if uuids were just
> another field, then there would be no core support to make use of them
> in any of the standard makros or functions.
Yes, that would be intentional, to make the surface are of the change
contained and least impactful.
chris...@gmail.com
> So, in my thinking UUIDs could be used for everything. The
> tiddler.title's are "hollow words".
This would change everything about TiddlyWiki. The core code, hundreds
of plugins.
We don't want that do we?
Thus: uuid as a field. Low impact change.
chris...@gmail.com
> But if anyone can think of an assertion that can safely be made if you
> can identify a specific field as being a UUID, please tell me.
assert this.tiddler == that.tiddler
That's the _only_ assertion you can make with a real id. But that's
the one we want.
From that assertion you can't make many conclusions other than at some
point these two tiddlers came from the same place. Only once you know
they came from the same place can you then investigate (using
associated data) if the tiddlers are different revisions, have
different content, have traveled along different branches, etc.
Miles Fidelman
>> But if anyone can think of an assertion that can safely be made if you
>> can identify a specific field as being a UUID, please tell me.
> a protocol around communicating about tiddlers that tells you exactly
> how it is defined, for example in the case of giewieki.
>
> This protocol that I am talking about is not some serialization format
> for tiddlers. Instead, it gives instructions on how to access any
> resource that provides them by telling you what you can expect from
> the resource once you do access it.
>
I've been watching this discussion, and it sure doesn't sound like a
discussion about communications protocols (speaking as someone in that
business).
I've been remiss in not jumping in earlier to point out that at least
one obvious approach to a "tiddler-based communication protocol" is
simply to
- define an XML representation of a tiddler
- start from the Atom schema
- move Tiddlers around using Atom feeds (post using Atom Publishing
Protocol, read as Atom feeds, search w/ OpenSearch)
- done
Miles Fidelman, Principal
Protocol Technology Group, LLC
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
chris...@gmail.com
> I've been remiss in not jumping in earlier to point out that at least one
> obvious approach to a "tiddler-based communication protocol" is simply to
> - define an XML representation of a tiddler
> - start from the Atom schema
> - move Tiddlers around using Atom feeds (post using Atom Publishing Protocol,
> read as Atom feeds, search w/ OpenSearch)
> - done
Something like this has already been asserted elsewhere in the thread,
and at least some portion of the participants has agreed to it in
principle. Which is why things then moved on to the question of how to
accurately identify tiddlers.
The sticking point on _that_ aspect of the discussion is when and
where to assign an identifier and what doing so means.
It's remarkable how familiar so much of this conversation is if you've
been through it before in other contexts.
You get people (I guess I'm probably one of these) who think that as
long as you can generate a good identifier all the rest kind of falls
out from being good about the web and existing protocols.
You get people who "believe" in XML and probably once thought XSLT was
going make everything okay and if we can get tiddlers to fit in that
world, all the rest kind of falls out.
You get people who lose focus from the original concept and start
talking about all the things that will be possible _locally_ if the
global functionality is achieved, distracting discussion from
actually achieving the local functionality.
Sun.
Nothing. New.
chris...@gmail.com
> You get people who lose focus from the original concept and start
> talking about all the things that will be possible _locally_ if the
> global functionality is achieved, distracting discussion from
> actually achieving the local functionality.
s/local/global/
That's almost a pun.
PMario
> tidcom:{
> version:"http://tidcom.org/v1",
> format:"json",
> standard:"http://tidcom.org/tiddler/v1",
> extensions:{
This may be interesting: http://substance.io/michael/data-js - Section
4.1 Usage.
-m
Poul
> You get people who "believe" in XML and probably once thought XSLT was
> going make everything okay and if we can get tiddlers to fit in that
> world, all the rest kind of falls out.
but I eventually went back to classic HTML mostly because of the flaws
in IE's implementation. You can still get the XML version with a URL
query string, though.
My point about UUID's was that strictly speaking, you really need to
know what it is that the uuid identifies, and that's a semantic issue.
I could imagine that a collection of tiddlers had the same value for a
named uuid, because either:
* they were different versions of the same tiddler.
* they originated from the same server or page.
* they were authored by the same person.
* or ... or ...
Not to deconstruct too much, my point remains that we should try agree
on two things:
1) What the tiddler-identifying id is named (simple).
2) What it means to have identified a tiddler. Not so simple. IMHO.
If, say, you receive a document that contains 42 more or less
different tiddlers having 17 different uuids, what can be deduced
about their relationships..?
A plausible interpretation would be 17 tiddlers, some of which have
several versions. You may of course choose not to accept such a
document. Or try to figure out which is the current version - but
don't assume that it's the one with the latest timestamp.
/Poul
tiddlygrp
I'm with Chris and Poul here. Keep it simple and just start.
Add a uuid field to core tw which is initialized at tiddler creation
time.
Also add a core field saying something like tiddler-schema version 1.
And standardize the date field to some format (or add an internal date
field in some format).
The important thing of these is that they have standard names, such
that other people are not using these fields. Then tw can keep on
working as before with just some extra fields.
Additionally I propose to add an optional journal or history field
analogous to Ward's federated wiki (
https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON
). This field can be ignored by tw (or not) and used to record
history (like add content, delete, merge, ...). Use of this field is
optional and probably would require some server assistance. The main
thing again is that the field name is reserved.
I also think that later on some field would be required to take a
cryptographic hash of tiddler contents, but let's start first and
evolve.
By just adding these fields nothing substantial has to change in the
core. Nothing needs to change in the ui! and the use of tw.
But these changes are building blocks for tiddler identification,
server side integration and federation. Let's see how they are used.
Keep it simple. Keep tw extensible.
@Poul About your example of 42 tiddlers with 17 different uuids. I
think a journal field can help in that case, but I would rather not at
this moment standardize. Let's try it first and evolve. With e.g.
tiddler-schema 2 it could be standardized.
chris...@gmail.com
> My point about UUID's was that strictly speaking, you really need to
> know what it is that the uuid identifies, and that's a semantic issue.
Ah, okay, somewhere along the line I thought we had already gotten
past that. I think in relation to the need for revision identifiers
to be separate from identifiers for the tiddler which "has" those
revisions.
> I could imagine that a collection of tiddlers had the same value for a
> named uuid, because either:
>
> * they were different versions of the same tiddler.
This is what I was thinking. And those different versions may exist
anywhere (in a tiddlywiki file, on a server, on some other server).
In aggregate they are "the tiddler". How the resolution of all those
revisions is handled is a _different_ issue from identifying that they
are in fact the same tiddler.
> on two things:
> 1) What the tiddler-identifying id is named (simple).
> 2) What it means to have identified a tiddler. Not so simple. IMHO.
Yes.
> If, say, you receive a document that contains 42 more or less
> different tiddlers having 17 different uuids, what can be deduced
> about their relationships..?
> A plausible interpretation would be 17 tiddlers, some of which have
> several versions. You may of course choose not to accept such a
> document. Or try to figure out which is the current version - but
> don't assume that it's the one with the latest timestamp.
This is aligned with my thinking.
chris...@gmail.com
> Additionally I propose to add an optional journal or history field
> analogous to Ward's federated wiki (
> https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON
> ).
If you put the journal in the tiddler, then when trying to reconcile
a lot of forks you need to merge up the journal.
That's non-trivial. And what does it get?
> By just adding these fields nothing substantial has to change in the
> core. Nothing needs to change in the ui! and the use of tw.
>
> But these changes are building blocks for tiddler identification,
> server side integration and federation. Let's see how they are used.
>
> Keep it simple. Keep tw extensible.
+1
I had a think on how to bootstrap and also enforce uuids yesterday,
which led me to an important conclusion:
Assuming the tiddlywiki core did not get a uuid field extension, or
an old tiddlywiki interacted with a server:
* when the server first saw the tiddler
if tiddler is new in this context (not persisted on this server):
if a uuid field is included:
persist that field with the tiddler
else:
add a uuid field
if tidler is not new in this context:
if a uuid field is included:
replace it with the uuid of the stored tiddler
The idea behind this pseudo-code is that it would insure that
the server has authority about uuids: You can't give it false uuids.
However the only way this works is if the server can determine,
accurately, if the tiddler is new in a certain context, and in order
for it to determine that it must use something other than the uuid
as the identifier for the tiddler (in the tiddlyweb context this
would be bag.name and tiddler.title). But then you have clobbered
the capability for uuid's to transcend renames and similar actions.
So, if you want real ids they gotta happen at the birthplace.
(We mostly know that, but just reinforcing the point.)
tiddlygrp
short reply on Chris's message inline
On Nov 18, 2:21 pm, chris.d...@gmail.com wrote:
> On Fri, 18 Nov 2011, tiddlygrp wrote:
> > Additionally I propose to add an optional journal or history field
> > analogous to Ward's federated wiki (
>
> If you put the journal in the tiddler, then when trying to reconcile
> a lot of forks you need to merge up the journal.
use optional. Then we can start experimenting with tiddler history.
I think the history should be kept in the tiddler primarily. Because
the tiddlers can be forked etc., it will be like a DVCS. This needs
development of a good ui to actually use the history and development
of the code. This is non trivial and I would not burden all uses of
tw with it. Maybe this can be best done with a plugin and/or
serverside. But the important thing is there is a standard field for
it. Obviously we also need to think about dropping part of the history
(maybe through server persistence), otherwise tiddlers can get too
large.
>
> That's non-trivial. And what does it get?
>
building of documentation. We can have distributed todo lists.
Imagine one of MonkeyPirateTiddlyWiki, mGSD,D-Cubed, TeamTasks,
TiddlyPackingList, tbGTD used by a team, online and offline and
optionally distributed by email.
Imagine mix-match-patch writing of stories.
PMario
> > That's non-trivial. And what does it get?
>
> It get's us distributed authoring of tiddlers, e.g. distributed
> building of documentation. We can have distributed todo lists.
> Imagine one of MonkeyPirateTiddlyWiki, mGSD,D-Cubed, TeamTasks,
> TiddlyPackingList, tbGTD used by a team, online and offline and
> optionally distributed by email.
> Imagine mix-match-patch writing of stories.
eg: You have a tiddler with 100 byte content and 1 MByte journal. How
can you get rid of the journal?
-m
tiddlygrp
On Nov 18, 4:07 pm, PMario <pmari...@gmail.com> wrote:
>
> How long would you want to take the journal with a tiddler?
>
> eg: You have a tiddler with 100 byte content and 1 MByte journal. How
> can you get rid of the journal?
(maybe through server persistence), otherwise tiddlers can get too
large."
and include in the journal field in the tiddler a reference (link) to
the server stored history. And if you don't want the history, just
drop it (we would need a ui for as I also wrote above).
But really I just want to keep open the possibilities by reserving the
field. Much needs to be worked out before it could actually be used.
And I also think much could be learned from the experience people have
using Ward's federated wiki in the future.
Yakov
use-cases.
1. While using IncludePlugin, one can have two tiddlers with the same
name in different documents (say, "Notes"), and also can desire to use
both (for instance, include "Notes" from a document about web-
technologies into the "Notes" regarding TiddlyWiki). In this case it's
enough to distinguish tiddlers by their *source*. Here are some
though.
It is desirable to have a "syntax" (formatters and macro definitions)
such that each link or transclusion macro can have a target outside
the document (smth like [[...|Notes]]@webTech like in TiddlySpace, or
[[...|Notes@webTech]]) and a "destination table"
|webTech|./web-technologies-learning.html|
|...|...|
which allows, besides other things, to *move* or rename a webTech
destination or even *change it to another document*. In this aspect,
it is about aggregation of tiddlers, not exactly their distinguishing.
Problems with distinguishing will occur if one would like to make a
non-distributed TiddlyWiki document i.e. import the external "Notes"
tiddler into the document.
2. Second use-case, or rather prospective is semantical versioning of
tiddlers. There's still no for managing system for multilangual
tiddlers or author's/public versioning of content. While this can be
done (rather awkwardly) using different tiddlers for each "version",
it creates many eclectic constraints and other problems, it seems that
the only proper way to implement such things is to have multiple text
areas in each tiddler.
It may be useful to keep this second one in mind for the protocal
design.