I'm not sure if this is important, but I'd like to mention a couple of
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
Hi,
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
On Thu, 17 Nov 2011, Poul wrote:
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
On Fri, 18 Nov 2011, tiddlygrp wrote:
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
Hi,
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 (
On Nov 18, 8:55 pm, tiddlygrp tiddly...@gmail.com wrote:
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,
Hi,
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?
As I wrote earlier: Obviously we also need to think about dropping
part
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.
Well, anything can be used as a uuid, the thing is, there needs to be
a protocol around communicating about tiddlers that tells you exactly
how it is defined,
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.
Well, anything can be used as a uuid, the thing is, there needs to be
a protocol around communicating about tiddlers that tells you exactly
how it is defined,
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.
Well, anything can be used as a uuid, the thing is, there needs to be
a protocol around communicating about tiddlers that tells you exactly
how it is defined,
On Wed, 16 Nov 2011, Tobias Beer wrote:
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
On Wed, 16 Nov 2011, PMario wrote:
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
On Wed, 16 Nov 2011, Poul wrote:
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.
Tobias Beer wrote:
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.
Well, anything can be used as a uuid, the thing is, there needs to be
a protocol around communicating about tiddlers that tells you exactly
On Thu, 17 Nov 2011, Miles Fidelman wrote:
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
On Thu, 17 Nov 2011, chris.d...@gmail.com wrote:
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.
On Nov 17, 9:15 am, Tobias Beer beertob...@googlemail.com wrote:
tidcom:{
version:http://tidcom.org/v1;,
format:json,
standard:http://tidcom.org/tiddler/v1;,
extensions:{
Tobias,
This may be interesting: http://substance.io/michael/data-js - Section
4.1 Usage.
On 17 Nov., 14:07, chris.d...@gmail.com wrote:
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.
Initially, I actually designed giewiki to be delivered as XML + XSLT,
On Tue, 15 Nov 2011, tiddlygrp wrote:
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.
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.
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
On Wed, 16 Nov 2011, PMario wrote:
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
I would argue that also a standard TiddlyWiki is dished out via some
server, hence serving tiddlers in a predefined way.
In other words, while of course one would expect some client for
editing tiddlers, it always is a server that delivers these uuid's,
since they are stored in tiddlers and thus
I would argue that also a standard TiddlyWiki is dished out via some
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
I entirely agree with cdent here (surprise!), and his explanations don't
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
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. 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
If you don't see a traditional TiddlyWiki that is simply served as is,
but cooked or computed on the fly as does TiddlyWeb, then you should
get the idea, even though my understanding and use of terminology with
respect to actual webservice implementations might be rather poor.
tb
--
You
If you see a traditional TiddlyWiki arriving at any one browser not
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
Why would you ever do this?
A simple usecase.
tiddlerName | UUID
fruits |
apple |
banana |
is tagged
is tagged
list filter [tag[]] will create a list:
*
*
with the right list macro and a lookup table it will be:
* Apfel
* Banane
Since I only
I'd definitely agree that it should be a field, but without semantics
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 -
Hi,
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
@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
Hi,
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
Hi Chris,
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
I'm very interested in the work that's going on around federation, and
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
On Mon, 14 Nov 2011, tiddlygrp wrote:
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
I suppose whether or not UUID's make sense as an attribute of a
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
I agree that if a client app - TiddlyWiki or other - assigns a uuid to
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
On 14 Nov., 17:09, chris.d...@gmail.com wrote:
On Mon, 14 Nov 2011, tiddlygrp wrote:
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
On Mon, 14 Nov 2011, Tobias Beer wrote:
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
On Mon, 14 Nov 2011, tiddlygrp wrote:
@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
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?
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/ -
Hi Måns,
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)
Actually, Måns, your post got me thinking...
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
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
On Nov 11, 9:44 am, Tobias Beer beertob...@googlemail.com wrote:
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
Hi,
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
46 matches
Mail list logo
