On Tue, 6 Nov 2012, twgrp wrote:
Glad I passed by and saw this! Great you're asking Chris!
Thanks for joining in. Once there are a few more response I'll make a summary page. Comments within...
1) I suggest a commenting feature where *non-registered* visitors can comment on tiddlers/spaces. Why? And isn't this more of a plugin issue? Well, it may be a plugin issue, but it is the single most powerful thing I can think of to attract people to TS-sites. The current "social features" in TS assume you're designing your spaces for fellow tiddlyspacemen, but at least my spaces are targeted at, well, regular folks. Adding a TW/TS built commenting feature would allow the spontaneous visitor to interact in a whole new way and it would make TS a lot more powerful.
There continue to be issues with how best to manage the potential for spam. Those issues have stalled us out from doing anything other than the (relatively spam proof) "reply to this tiddler" mechanism. It probably makes sense to try a different approach: Rather than assuming spam will happen or be hard to manage, just see what happens and deal with issues when they come up. There are some security concerns of course. We don't want a random visitor to be able to make a systemConfig tagged tiddler. But these can probably be overcome with what are called validators (server-side filters that ensure that content doesn't have BadStuff™). My preference would be for some kind of per-space bag that is writable by anyone (create only). Such a thing could be used by other applications than just TiddlyWiki. For the TiddlyWiki use case a plugin would need to be created that allows things to be created in that bag.
Ok, that said, here are some perhaps more conventional opinions: 2) I wish there was a general focus on "mixing, merging, copying, slicing and dicing" between spaces:
This is, of course, the entire purpose of the "space" concept but the tools are not (yet) elegant.
a) Currently we can include a space into the current one. I wish we could "push" spaces
I'm not sure what you mean by "push". Do you mean while looking at space X you can cause space Y to include it (rather than needing to go to space Y and add X)?
b) ...and that we could include individual tiddlers. Especially with your tiddler centered focus (which I also find exciting!) I think it would be great if we could simply include a single tiddler, or at least its contents. Maybe something like <<tiddler tiddlername@space>> ? It is possible, today, to use iframes and the ".txt" and ".html" formats but... ugly.
There is support for interspace tiddler transclusion in three different ways: * Within TiddlyWikis using a plugin from the following space: http://following.tiddlyspace.com/TiddlySpaceIntraSpaceInclusion * In the html representation when using the tiddlywikitext format * In the html representation when using the Markdown format (the syntax there is different, based on examples in other markdown services: {{tiddler title}}@space
c) and finally also *pushing *individual tiddlers. Once again, maybe it's "a plugin thing" but imagine visiting a space and seeing some interesting tiddler only to "push" it into some space of yours via some command right there. Maybe a default toolbar command for this could be possible as long as all spaces involved are on TS. I'm uncertain if such a pushed tiddler means it actually refers back to the original tiddler or if it is a local copy.
You might have a look at http://flicktiddler.tiddlyspace.com to if that's the kind of thing you mean. There are rather weird browser hurdles to overcome to copy around content when the target space is the one that is not currently being viewed. The usual solutions involve iframes (this is how the @reply functionality works).
With my naive non-programming eyes, all of the above seems to be about interconnecting subsets of spaces and I'm hoping for some general solution.
The space concept in TiddlySpace makes some of this stuff harder than it would be in a generic TiddlyWeb setup. TiddlySpace gives you the benefit of easier handling of the basics, but then makes the more complex stuff (like dynamic recipes with filters, which is what would be necessary for a general solution for interconnecting subsets of spaces) harder. A main challenge is coming up with a feasible UI.
Some of what you guys are discussing in this thread, such as integrated searches and publishing individual tiddlers sounds related. With the tiddler centered perspective you advocate, Chris, I think these ideas are already up on the table, no?
The main idea with the tiddler centered perspective is that the tiddler be the primary point of access and entry and "apps" like TiddlyWiki become one (of several) tools for manipulating tiddler collections (including presenting them as a "story").
3) I tried, and noted others trying, to use mGSD on TS but it doesn't work. I wish it did.
I seem to be able to get it to work. Here's what I did: * Got an empty mgsd.html * Created a new space (@mgsdt1) * Used the import backstage to import all the mgsd.html tiddlers * Used the /_space app to remove the system-* includes * Reloaded the tiddlywiki This resulted in an apparently working mgsd, with the caveat that saving needed to be triggered by clicking save changes. Automatic saving was not on. I then tried to make it so it was possible to create a new space that used @mgsdt1 as a source space for turning the new space (@mgsd2) into an mgsd space. I had to remove the system-* includes in that one too. However it did not work because settings tiddlers like MgtdSettings come from the @mgsd1 and when the @mgsd2 space want to update those settings things go a bit wrong with permissions problems: An existing tiddler is always saved back to its original location, unless plugin code gets in the way to do a clone of some kind. So, in order to get mgsd to work on tiddlyspace in an effective way (one that doesn't require duplicating the plugin code all over the place) a newly minted space that includes the mgsd stuff would need a plugin to duplicate the various config and data starting point tiddlers into the current space. I suspect that someone (Simon?) could quite quickly cook up that plugin. I, not knowing the guts of mgsd, don't really know which parts would need adjustment. However, I don't think there are large technical roadblocks to making it happen. I suspect that recent changes in the tiddlywiki core (related to saving and merging defaultCustomFields) have improved the situation here. It was probably a good deal worse a few months ago. Hope this provides some insights. -- Chris Dent http://burningchrome.com/ [...] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to tiddlywiki@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
