Tank: twikifier disabled

[chris...@gmail.com]

tl;dr: twikifier, the tiddlywiki clasic syntax renderer on Tank, has
been turned off.

Longer, read if you're curious:

The usage patterns on my Tank service[1] basically come in two styles:

* people using the markdown wiki functionality[2]
* people experimenting with the tiddlywiki 5 composition[3]

That's not all it can do[4], but that is where most of the use
happens.

When originally put together I borrowed the twikifier functionality
from TiddlySpace to make it possible for text formatted in tiddlywiki
classic syntax to be rendered to HTML on the server.

I've turned that off today because:

* It's not getting used very much. Less than 5% of the tiddlers, most
of them mine, are tiddlywiki classic text, and those are rarely
viewed outside of TiddlyWiki. When viewed in tiddlywiki, it does the
rendering, so twikifier is not needed.
* twikifier uses up quite a lot of memory and may have a memory leak
and whereas the tiddlyspace.com server has 32GB of RAM, my server
only has 768MB, so needs all the space it can get.

If this causes an issue for you please let me know and we can do
something about it.

[1] https://tank.peermore.com/
[2] https://tank.peermore.com/tanks/docs/Using%20Wikis
[3] https://tank.peermore.com/tanks/docs/TiddlyWiki%20Five
[4] https://tank.peermore.com/tanks/docs/Features

--
Chris Dent http://burningchrome.com/
[...]

[Eric Drechsel]

Hi Chris, 

Might it be it possible to for a Tank user to upload their own TiddlyWiki 2 composable app containing custom plugins and whatever plugins are needed for async tiddler loading?

I ask because I have a crazy plan to

 - pick up maintenance of Simon Baird's mGSD

 - use it (and provide it as a composable app to other users)

 - while developing a "spiritual successor" to mGSD which is can concurrently operate on the same store.

Currently I'm using TiddlySpace but would like switch to Tank because you're supporting it and because I like the tank abstraction over bags and recipes better than the space one.

I'm also open to running my own Tank with twikifier if the async thing doesn't work with mGSD for some reason.

Best,

Eric

http://eric.pdxhub.org/

[chris...@gmail.com]

On Fri, 10 Apr 2015, Eric Drechsel wrote:

> Might it be it possible to for a Tank user to upload their own TiddlyWiki 2
> composable app containing custom plugins and whatever plugins are needed
> for async tiddler loading?

Yes, I think you've got pretty much two options there:

* Create a bag with your own bundle of tiddlers that are the empty
tiddlywiki you want, the plugins and whatever you are doing to magic
them together, and use that bag as the basis for building a comp (by having
an "app" tiddler).

* Use the existing tiddlywiki bag[1] combined with another bag
containing the additional plugins.

In either case having a looking at the bootstrap.js in the tiddlers
linked below ought to push you in the right direction. Also keep in
mind that under the covers all a comp is a recipe containing a tiddler
named 'app'. At the UI level a comp is one "comp-able" bag plus a bag
you add, but under the hood it can be as many bags as required.

And the async part ought to sort of just fall in place as part of your
explorations.

> I ask because I have a crazy plan to
>

> - pick up maintenance <https://github.com/edrex/mGSD> of Simon Baird's mGSD

> - use it (and provide it as a composable app to other users)
> - while developing a "spiritual successor" to mGSD which is can
> concurrently operate on the same store.

It's very cool that you're taking this on. mgsd has always been one of
those tiddlywiki-wow things.

> Currently I'm using TiddlySpace <http://mgsd-initial.tiddlyspace.com/> but

> would like switch to Tank because you're supporting it and because I like
> the tank abstraction over bags and recipes better than the space one.

I think the public private thing was a useful metaphor but it never
quite came together right.

> I'm also open to running my own Tank with twikifier if the async thing
> doesn't work with mGSD for some reason.

My installation will be staying around: it's become a very useful tool
for me. However if you want to run your own I did start this:

https://github.com/cdent/tankdock

That's a bit out of date now (for tank and for docker) but probaby not
too far.

And there's also this which is somewhat related:

https://github.com/cdent/twebwiki-openshift


[1] This contains a modified TWC that effectively bootstraps a
tiddlywiki into bootstrapping itself again after loading all its
tiddlers. First loads app, then bootstrap.js, then other tiddlers,
evaluates plugins, "restarts" the tiddlywiki.

https://tank.peermore.com/bags/tiddlywiki/tiddlers

[Eric Drechsel]

On Sat, Apr 11, 2015 at 2:45 AM <chris...@gmail.com> wrote:

On Fri, 10 Apr 2015, Eric Drechsel wrote:

> Might it be it possible to for a Tank user to upload their own TiddlyWiki 2
> composable app containing custom plugins and whatever plugins are needed
> for async tiddler loading?

Yes, I think you've got pretty much two options there:

* Create a bag with your own bundle of tiddlers that are the empty
   tiddlywiki you want, the plugins and whatever you are doing to magic
   them together, and use that bag as the basis for building a comp (by having
   an "app" tiddler). 

* Use the existing tiddlywiki bag[1] combined with another bag
   containing the additional plugins.

In either case having a looking at the bootstrap.js in the tiddlers
linked below ought to push you in the right direction. Also keep in
mind that under the covers all a comp is a recipe containing a tiddler
named 'app'. At the UI level a comp is one "comp-able" bag plus a bag
you add, but under the hood it can be as many bags as required.

Ok, I have a lot of exploration to do before I can respond with actual results.

I had thought to inline all the plugins in the main app resource (not realizing that bootstrap could do this second instantiation). I might still do that as a first pass, and just load the user data tiddlers async (without the second instantiation).

From reading the Tank docs (great job on them by the way!) it sounds like the second option (tiddlyspace + mgsd + personal tank) would currently require consumers to manually manipulate edit their composition recipe. That would be fine for the moment and I'm sure we could come up with a UI for it later.

It's pretty straightforward to copy the needed tiddlywiki resources to the mgsd tank, which would allow composition throught the UI to work for now.

 

And the async part ought to sort of just fall in place as part of your
explorations.

 

Sounds like the beginning sequence of every 8 bit RPG.

 

> I ask because I have a crazy plan to
>
> - pick up maintenance <https://github.com/edrex/mGSD> of Simon Baird's mGSD
> - use it (and provide it as a composable app to other users)
> - while developing a "spiritual successor" to mGSD which is can
> concurrently operate on the same store.

It's very cool that you're taking this on. mgsd has always been one of
those tiddlywiki-wow things.

> Currently I'm using TiddlySpace <http://mgsd-initial.tiddlyspace.com/> but
> would like switch to Tank because you're supporting it and because I like
> the tank abstraction over bags and recipes better than the space one.

I think the public private thing was a useful metaphor but it never
quite came together right.

You mean public/private as a tiddler - rather than container - property, since spaces let allow marking a tiddler as public without having to conceptually move it to a new container (even though under the covers, it is being moved to the _public bag)? It seems like a lot of juggling to hide the underlying bags/recipes model from users. The "Clone" feature in tank seems like an effort to address this need by simply making it easy for users to move things around.

 

> I'm also open to running my own Tank with twikifier if the async thing
> doesn't work with mGSD for some reason.

My installation will be staying around: it's become a very useful tool
for me.

Great, I really appreciate your providing/supporting this infrastructure, as it makes getting started a lot easier than if I had to configure my own instance.

 

However if you want to run your own I did start this:

 

    https://github.com/cdent/tankdock 

That's a bit out of date now (for tank and for docker) but probaby not
too far. 

And there's also this which is somewhat related:

    https://github.com/cdent/twebwiki-openshift

 

Thanks! The detailed deployment steps in the Dockerfile/Openshift action hook thingie are super helpful. I'd probably run Tank in a plain cgroup via a systemd unit.

[1] This contains a modified TWC that effectively bootstraps a
tiddlywiki into bootstrapping itself again after loading all its
tiddlers. First loads app, then bootstrap.js, then other tiddlers,
evaluates plugins, "restarts" the tiddlywiki.

I noticed the flash. I think this a 

[chris...@gmail.com]

On Sun, 12 Apr 2015, Eric Drechsel wrote:

> From reading the Tank docs (great job on them by the way!) it sounds like
> the second option (tiddlyspace + mgsd + personal tank) would currently
> require consumers to manually manipulate edit their composition recipe.
> That would be fine for the moment and I'm sure we could come up with a UI
> for it later.

Thanks, the only reason the docs are any good was because I was laid
out with pneumonia for the several weeks that Tank was being built.
Time...

"UI for it later" is a common theme in anything related to
TiddlyWeb. It's become a bit of a bad habit but is also completely
understandable given the people involved.

>> And the async part ought to sort of just fall in place as part of your
>> explorations.
>
> Sounds like the beginning sequence of every 8 bit RPG.

You are likely to be eaten by a grue.

>> I think the public private thing was a useful metaphor but it never
>> quite came together right.
>
> You mean public/private as a tiddler - rather than container - property,
> since spaces let allow marking a tiddler as public without having to
> conceptually move it to a new container (even though under the covers, it
> is being moved to the _public bag)? It seems like a lot of juggling to hide
> the underlying bags/recipes model from users. The "Clone" feature in tank
> seems like an effort to address this need by simply making it easy for
> users to move things around.

I was thinking more of the <space>_private <space>_public recipes
and how different people saw different representations of a space
depending on their access. It made thinking about how stuff was
going to work a bit hard.

> Thanks! The detailed deployment steps in the Dockerfile/Openshift action
> hook thingie are super helpful. I'd probably run Tank in a plain cgroup via
> a systemd unit.

Yeah, I was looking at those the other day and thought several
things at once:

* systemd has eaten another thing!
* cool!
* I'll come back to this

> [1] This contains a modified TWC that effectively bootstraps a
>> tiddlywiki into bootstrapping itself again after loading all its
>> tiddlers. First loads app, then bootstrap.js, then other tiddlers,
>> evaluates plugins, "restarts" the tiddlywiki.
>
> I noticed the flash. I think this a

Looks like you didn't finish this thought?

[FND]

>> I noticed the flash. I think this a
>
> Looks like you didn't finish this thought?

That's when the grue showed up.