On Sep 8, 10:43 am, Tobias Beer <[email protected]> wrote: > Hi everyone, especially those actively working with and developing > TiddlySpace,
Since you asked in another thread, I'm going to try to give some responses to your comments. I should state up front, though, that there's a fair few of us working on TiddlySpace and that means there are probably conflicting views on how this stuff should work. This is, in the end, a good thing as it means there's plenty of debate about how things ought to be done which ought to lead to good solutions. However it can also mean that things seem to meander. Also, as the author of TiddlyWeb, the primary server-side component for TiddlySpace, I see one of my roles as not letting the needs of TiddlySpace break the more diverse context in which TiddlyWeb operates. Because of that, a lot of the solutions that we try to make for TiddlySpace are done in ways that take advantage of the existing users, recipes, bags, policies, filters and tiddlers entities that TiddlyWeb already supports. So, for example, while TiddlySpace has the concept of space, TiddlyWeb does not. For TiddlyWeb a space is really just two recipes with related names. Given those disclaimers... > [Since this is a somewhat user centric view and since I think > TiddlySpace deserves more attention in the TW community I preferred > discussing it here rather than in the TiddlyWeb group.] Seems like a good idea. However I warn you there are some fairly technical details ahead. > Having played with TiddlySpace I have come to realize that inclusion > is THE most essential part of it. Although this or parts of what > follows may have been discussed already, here's how I would improve > inclusion in the future: I agree. Inclusion provides a lot of interesting possibilities and for now it is the thing that distinguishes TiddlySpace. As following matures, I suspect that and the public/private model will likely also be important. First off it might be important to state that TiddlySpace's inclusion model is a dumbed down version of what's called the recipe cascade in TiddlyWeb. In TiddlyWeb a recipe is a list of bags paired with optional filter strings. There can be any number of bags and the filters are a powerful and extensible query language that let's you say which tiddlers in the currently being processed bag will be included in the recipe cascade. The output of the recipe cascade is the list of uniquely named tiddlers found in the processing. If there are duplicates, the most recently found tiddler is the one that wins. In TiddlySpace inclusion adds the public bags found in the included space's recipe to the current space's two recipes. Without filters, for now. This means, as you've found, that all the public tiddlers in the included space (including the ones it includes from other spaces) get included in the current space. > 1) First of all, inclusion makes one thing of desperate need: space- > TAGS. Tags should no longer pertain only to tiddlers but be attached > to spaces as well ...and very likely, so should fields. Space-TAGS > should be the foundation of any space listing and thus space inclusion > management. The easiest way would be to introduce a ShadowTiddler > called SpaceTags containing a bracketedList of strings that follow the > same naming conventions as space-names. This way a space name could be > easily converted to an inter-space-link if a space of said tag > existed. I _think_ the plan for this is to use the SiteInfo tiddler in the space with its tags, fields and potentially slices as ways of accomplishing some of what you are talking about. To find the tags associated with a space, one would look at the SiteInfo tiddler in the public bag of the space. > 2) There are certain general options of need when it comes to dealing > with secondary spaces (e.g. spaces included by the space being > included), something like... These scenarios were discussed in the early chats about TiddlySpace and are expected to be accomplished, eventually, through filters. The exact mechanism for that is not yet known, but I can imagine something a bit like the @EXPORTS stuff in Perl. Basically a space would have a tiddler or tiddlers which defines how secondary inclusion options would be managed. These tiddlers would be inspected in two different ways: * At the time when someone choose to include the space the user is asked the questions you suggest. Depending on the answers the info from the tiddlers is used to generate the list of bags that need to be subscribed as well as any filter strings that need to be in the recipes. * At the time of load, those filter strings might inspect tiddlers in the spaces which act as a pointer to filters which the space owner defines in the space (thus allowing other spaces that include this one to be correctly adjusted as the filter list changes). The first one of those seems pretty straightforward and much like you imagine. The second one I'm hesitant about as it could get messy. More thought required. Generally your suggestions seem right on, in spirit, to me. I suspect the interface won't be exactly as you describe, but the tasks are in alignment with what I've heard people (devs and users) talk about. Give the detailed level of control that you are interested in having, it may be worth your while for you to come to grips with the details of the TiddlyWeb HTTP API which allows you far greater control of bags and recipes (and filters) than the TiddlySpace UI currently provides. For experimentation its probably best to operate on your own TiddlyWeb server, but the whole API _is_ available on the tiddlyspace.com server, just have to look under the hood. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
