Just thinking out loud...
Step 1 to safe-keep important tiddlers: add a little bit of custom code to
$/core/ui/ImportListing
(Well, I am pondering over what kind of trouble I might get myself into...)
If a tiddler being imported already exists and the already existing one has
a certain tag,
Tthis is one of those reasonable sounding features that has a surprising
degree of inwardness when one looks into it. Implementing true read-only
tiddlers would have a substantial impact on the architecture of TiddlyWiki:
* At the moment, write operations cannot fail, and so there is no error
Just to re-iterate, there are several ways an important tiddler can be
unintentionally fricasseed.
The most likely from a brain-fart moment, examples off the top o' me
noggin':
- delete button
- drag and drop a crap version that overwrites the good version
- bad set-field (or other
On Talk.tiddlywiki.com I would mention Mario and Charlie here.
Mario I would like to support part of what Charlie seems to be concerned
with. I have a few wikis where I have delete inhibit on selected tiddlers,
typically the master tiddler that is a compound tiddler, meaning it has
many
What I have in mind is pretty simple, and it is about resolving issues that
completely break TiddlyWiki or break an application built upon TiddlyWiki
in a node.js farm of TiddlyWikis.
On Mon, Sep 6, 2021 at 3:57 PM Hans Wobbe wrote:
> Charlie:
>
> Perhaps some of the protection you are looking
Charlie:
Perhaps some of the protection you are looking for can be had via the
frequent saves of a tiddler file to Dropbox?
Unless things have changed since I last used it, that would provide a
rolling 30 day cache that could be used to recover losses.
Cheers,
Hans
On Monday, September 6,
Well, by obfuscation, I see that as a catch-all word to also mean
abstraction, encapsulation, and whatever other little design thingies so
that the end result doesn't look anything like TiddlyWiki any more.
So a user will have to work very hard to get into trouble.
Your Plan B is my Plan A,
Oh, don't pursue that for my sake. I've got something in mind already that
I want to try out.
On Monday, September 6, 2021 at 3:53:44 AM UTC-3 TW Tones wrote:
> Charlie,
>
> *My problem is about preventing tiddlers from being overwritten by an
> import or by a new tiddler getting created and
On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:
No worries. I'll train my thoughts on obfuscation, risk-mitigation
> design/strategies, and automated monitoring/repairing processes.
>
IMO obfuscation is wasting time, other than removing the buttons, that are
not
Charlie,
*My problem is about preventing tiddlers from being overwritten by an
import or by a new tiddler getting created and saved with a name of a
tiddler that already exists. That's not solved.*
But in my earlier reply, I think we can solve this issue by moving the
"readonly" tiddlers to
Well, "Tiddly Locking" isn't a solution to my problem in this thread.
My problem is about preventing tiddlers from being overwritten by an import
or by a new tiddler getting created and saved with a name of a tiddler that
already exists. That's not solved.
Tiddly Locking is great, is
Charlie,
Good to hear. Since you question was answered with "Tiddly locking" could
you point to that as a solution for future readers in this thread ?
Tones
On Monday, 6 September 2021 at 15:15:49 UTC+10 cj.v...@gmail.com wrote:
> G'day Tones,
>
> I've got editing and delete of important
G'day Tones,
I've got editing and delete of important tiddlers blocked via tiddler
locking. That's easy and good.
The only thing I have to handle, even if 99% unlikely, is certain tiddlers
getting overwritten by any tech-savvy (well, TiddlyWiki-savvy) individual.
Since that can't really be
Charlie,
A few ideas;
One way would be to stash a copy away, perhaps inside a JSON tiddler,
similar to Mohammad's trash plugin but just on editing. This kind of
solution can intercept User interface edit/delete however batch processes
can by pass this.
Some solutions like noteself to keep
Trying to achieve a robust architecture for a farm of node.js TiddlyWikis
that together form a distributed database, with end-user level (and
private) TiddlyWikis that have certain types of tiddlers that are
automagically shared (and the rest private), and system-level TiddlyWikis
that tie all
On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com wrote:
...
> Is there an easy way to protect such a tiddler?
>
No. In TW you can overwrite every core tiddler if you like. So there is no
way to write-protect a tiddler.
What do you want to achieve?
-m
--
You received this
16 matches
Mail list logo
