SuperSpaces for include to other spaces

[gimntut]

Need superspaces for grouping special spaces. Example: tools, languages, images, themes and etc. Move spaces from

• http://edit.tiddlyspace.com
• http://hl.tiddlyspace.com

to

• edit.tools.tiddlyspace.com
• hl.tools.tiddlyspace.com and other.

Move space from http://rus.tiddlyspace.com to rus.languages.tiddlyspace.com

Need to convert ordinary spaces into special. Need to choose space for including from list or combobox, example one choice:

• spacename.tiddlyspace.com/_language
• spacename.tiddlyspace.com/_theme

multiselect:

• spacename.tiddlyspace.com/_tools

[cdent]

This is an interesting idea but unlikely to happen as as a great deal of the code in tiddlyspace that identifies a space is based on the idea that there's only one level of separation between the main hostname (e.g. tiddlyspace.com) and the hostname of a space (e.g. cdent.tiddlyspace.com). Adding in another layer would be quite an undertaking, especially given that it is quite likely the functionality you're interested in achieving could be done with tags on the SiteInfo tiddler.

I believe that pmario, maans, tobias in the google group have done some work in this area. @pmario or @tobibeer may be able to comment more?

I think the idea is that a SiteInfo tiddler would be tagged with "tools, languages, images, themes and etc." Then searches of the form /search?q=tag:tools%20title:SiteInfo could then be used to find all those spaces which have declared themselves a "tool".

[pmario]

you may have some luck with:

http://tiddlyspace.com/search?q=tag:languages%20title:SiteInfo%20_limit:9999 http://tiddlyspace.com/search?q=tag:plugin%20title:SiteInfo%20_limit:9999 http://tiddlyspace.com/search?q=tag:theme%20title:SiteInfo%20_limit:9999

The only problem is, that there is no central info about, which tags for SiteInfo tiddler are used.

Some spaces / users did include plugin spaces, but didn't remove the SiteInfo tag, so they are listed as plugin spaces, which is wrong.

There is some space for improvement here.

[gimntut]

Should be a zone for people (space, blog) and should be a zone for tools (shared scripts, plugins, themes). Now is mixed, so very very many empty spaces. Tiddlyspace seems dead.

Let my tools place in myspace.tiddlyspace.com/_tools. I'm can create new subspaces with tools or include other subspaces. Example,

• gimntut.tiddlyspace.com/_tools/hl.gimntut
• gimntut.tiddlyspace.com/_tools/edit.cdent

[tobibeer]

@gimntut

I believe you've too quickly jumped to describing some sort of solution. However, what seems in need of being assessed first is your actual goal and any requirements that may come with it. It's definetely not (yet) about URL patterns or dropdowns! Feel free to prepend the below spec to your original post.

@cdent and @pmario I am pretty certain that what is asked for neither is a need for special URL patterns nor a way to find things.

Goal

What I believe @gimntut is after is a kind of aggregated inclusion in order to achieve a kind of application, like tbGTD for example — which I will defininetely not port to TiddlySpace unless this is implemented.

Requirements

1. First of all, this must not be in the form of any TiddlySpace user tagging a SiteInfo tiddler in some way!
2. It must be such that a space @App not only includes all of @App.Bar, @App.Baz or @Mumble etc but also sets inheritance for those includes such that they be passed down to any other space that itself includes @App.
3. If you wish, @App is a kind of tiddlyspace application that may itself include a number of spaces whose SiteInfo tiddler is tagged plugin or other spaces that serve as components (e.g. a dictionary) or resources (e.g. images). a) However, @App is not the actual application in use but only the blueprint.
4. Keep in mind that this does not involve recursive inclusion! It would already open up a great deal of possibilities if this were possible for just one level. a) This perhaps called shallow inheritance pattern may only be desired for some but not all spaces included by @App, like @App.Help may only be staged in @App directly but not in any instances.

Solution

Here's what I'd suggest as a solution to the above...

• A checkbox or preferably a colored vs. greyish picto next to each included space allows to activate or deactivate shallow inheritance for any included space.
• Shallow inheritance being set for an include, the recipes of other spaces that include @App may need some form of inherited inclusion pattern.
  • Perhaps shallow inheritance could be checked against some space inheritance index stored at the server when cooking a space based on its recipe.
  • With such an index even 'application bundles' aggregating a number of applications (thus going all the way to a second level) may not be too far fetched using something equivalent to what in Salesforce SOQL is called a relationship query [1]
  • In any case it is not the inherited spaces that are listed in some @UserInstanceOfApp recipe but only the master or application space, perhaps indicated by some form of otherwise not allowed prefix, e.g. +@App instead of just @App.
• When some eventual user loads his or her @UserInstanceOfApp space then inclusion is handled in a way that inherited spaces are loaded along with other spaces included in @UserInstanceOfApp.
• If an application designer such as myself would not want for some parts of @App to be passed down to any @UserInstanceOfApp space, then these contents will have to be put into some @App.MasterOnly space for which shallow inclusion is turned off, see 4a) above.
• It may be desireable for the end user to be able to easily see or navigate to a list that shows which spaces in his or her @UserInstanceOfApp have been included thanks to @App.
• Not only for debugging purposes, it is quite desireable to have some information in a space-list popup in the spaces tab that indicates thanks to which (application-)space(s) some (plugin-)space has actually been included via shallow inclusion.

[1] pseudo query for fetching 2 levels worth of inherited includes from an index table called Parent having both a Space and Parent column; compare to SOQL...

myAppSpaceIncludes = ['app', 'bar']
spaces = [
    SELECT
        Space,
        (SELECT Space FROM Parent WHERE Parent = Space)
    FROM
        Parent
    WHERE
        Parent IN :myAppSpaceIncludes
]

[pmario]

@gimntut There has been a discussion about space inclusion some time ago. https://groups.google.com/group/tiddlyspace/browse_thread/thread/e3a1b4050393c72c

@tobibeer I'll need to read your specs again, when I'm in the mood to dig into it. In the first run I don't have any idea, what you wan to achieve.

[mumble]

(Hi, it looks like I got CC'ed into this issue somehow? Sorry for commenting here, but I see no email addresses in the Github notifications. Can someone un-CC me? Thank you!)

[cdent]

I remain confused. Inclusion is already aggregate, so I'm not sure what's actually being asked for here, except perhaps a way to turn off the default aggregate inclusion to allow only including the bags that are native to the space being included. That's perhaps doable, but doesn't appear to address what @gimntut is after.

If space X includes Z and Y, when space A includes X it gets Z and Y too.

And all of this can be inspected by looking at the public recipe of a space: The bags that are in the recipe indicate the spaces that have been included.

So, for something like tbGTD one would presumably create several spaces for the various plugins, a space for documentation, a space for stub content, and then a space which aggregates (by inclusion) all those spaces. A person who wants to use the app, then, would just include that one (last) space.

JavaScript tools which can inspect recipes can figure out the various hierarchies.

It's very important that whatever tools get created here use the existing entities: bags, recipes, tiddlers. Additional indexes on top of those things are not really an option. As things stand now the "space" concept is an artifact of recipes, they don't exist in an of themselves. The inclusion concept is an artifact of recipes and bags.

My impression of @gimntut is a desire to be able to see what spaces are actively being built and are available for doing stuff. If that's the case then that's the job of SiteInfo and it is the responsibility of the space makers to make sure their SiteInfos reflect the right info.

But, without more clarity on the desired behavior it's hard to say. As almost always seems to happen with these things: the base bits of functionality, in terms of recording and accessing the information, are there, but the UI and documentation is not.

[gimntut]

Now: 1 plugin = 1 space I need: 1 plugin = 0 space. Spaces is talking place (blog). For plugins to be another place.

[tobibeer]

@cdent

While topic #1031 turns out to be rather about partial inclusion — you've mentioned that "inclusion was already aggregate"...

If I thus included @SomePlugin into @MyApp as the app designer and then @SomeOne included @MyApp into @TheirSpace would changes such as...

a. tiddlers created, edited or removed b. spaces included or unincluded

...in either of...

1. @SomePlugin
2. @MyApp

...eventually find their way to @TheirSpace?

If not, then I guess I will move my last post into a new issue — unless that already existed somewhere.

Update Matrix

Changes to...	in @SomePlugin	in @MyApp
Tiddlers edited, created, deleted	Updates to tiddlers in @SomePlugin pushed to @TheirSpace?	Updates to tiddlers in @MyApp pushed to @TheirSpace?
Spaces included / unincluded	Updates to included spaces in @SomePlugin pushed to @TheirSpace?	Updates to included spaces in @MyApp pushed to @TheirSpace?

[cdent]

@gimntut : might be worthwhile for you to look at recipe and filters for some concepts that are a part of the tiddlyweb API that may be useful for understanding the tools that can be applied to your goals. I think I'm getting closer understanding what you're trying to achieve, but not quite reaching full understanding as we're not entirely on the same page with regard to the existing functionality in the system.

@tobibeer : Probably best we move your questions to the google group, but in short: tiddler updates do propagate (because that what's inclusion is: the tiddlers are in your spaces's recipe when a space is included) but recipe updates do not. The latter may be perceived as a limitation but it could also be perceived as a way of insuring that space makes effectively communicate about their spaces.

[tobibeer]

@gimntut

I believe your issue may also be understood as one of setup. For example, if you wanted...

• just the articles
• just some plugin

...of some @friend space, then the problem may actually be that @friend does not provide those things separately in...

1. @friend.articles
2. @friend.toolX or @toolX respecitvely

However, I have come to think — especially with my own stuff — that such a separation is quite desireable especially when content reuse is a desired goal.

The thing is however, that you may just not be in the position to make @friend change its content structure to just that. However, one could argue that it were possible and likely very desireable that a space is created for @toolX.

You could, for example just go ahead and do that and possibly include the owner / members of @friend as a member to it in order to share ownership for @toolX with its presumed creator.

Although it is generally possible to include all public stuff of @friend — @you (partially) including just articles@friend may actually not be desired by the owner / members of @friend.

In that respect and the recent discussion pointed out by Mario I think it really is desireable that actually the owner / members of a space can decide on what should be (partially) includable.

In a way it feels like public must not be equalled with (partially) includable.

[gimntut]

@cdent recipe and filter - good for take, but first you need to find what you need. It is difficult to share with others. My friends do not speak English. They do not know me personally. They do not know where to look for the space http://rus.tiddlyspace.com. Without it, they can not use tiddlyspace. Need one place for translates. Need one place for tools. Need one place for themes. Simple do public, simple do take.

[cdent]

@gimntut Okay, I'm starting to understand it now; you're right there is a definitely a need for improved tools for discovery.

I'll comment more tomorrow after having a think about ways to deal with it overnight. As the week progresses hopefully we can build a prototype to really work around some of the ideas.

[cdent]

Okay, took me a bit longer than expected (other things prevented getting started) but I've created a (not fully functioning) prototype of a tool that provides a way to discover what spaces are out there. It's based on the notion that you should be able to go to one page, see topical groups of space that can be included, easily inspect them and easily include them. The result is called tsiscover.

That application presents a bit of information about itself. For more see this commit.

Please comment here or in tsiscover's repo with ways in which this is good or bad, right or wrong. It's not intended as a perfect solution but rather as a concrete thing over which to discuss the options.

[pads]

This looks pretty good.

It does highlight the problem with how people are using the SiteInfo tiddler though. For example, there are a few spaces under theme which in fact are not theme-only spaces but they have included a theme and that theme's SiteInfo tiddler has become theirs. I don't know how this has happened but I can see it leading to confusion.

I guess one handy feature to help resolve that is to have an option to flag a space as incorrectly tagged and have this information presented for other users to see. Something like "x people believe this space does not belong in this category".

[cdent]

not theme-only spaces but they have included a theme and that theme's SiteInfo tiddler has become theirs

That's a problem that can be improved over time. From the "Hi" block in the app:

Note that some of these spaces have the incorrect tags as a result of included SiteInfo tiddlers. Newer spaces are always created with their own SiteInfo so this problem will eventually fade away.

That's because the local space's SiteInfo will always win. Older spaces that don't have their own SiteInfo could be given one if we wanted.

[pmario]

... Older spaces that don't have their own SiteInfo could be given one if we wanted.

+1

[cdent]

One class of SiteInfo tiddlers that will be hard to deal with are the result of people using import instead of include to grain functionality from another space. We should probably annotate the import interface (in the tiddlywiki backstage) to point out that importing from tiddlyspace should not be done. We could even explicitly prevent it (or at least warn).

[gimntut]

tsiscover very fine. Only need filter for long lists. @cdent can not prevent the importation until including of certain tiddlers. Could use a tiddler similar to the DefaultTiddlers with list of included tiddlers (from field 'origin') Only need simple tool for add tiddlers (path of tiddler) to list.

P.S. May be in future separate "Include" to "Include for self" and "Include for all"?

[cdent]

I reckon this issue has been a very good discussion leading to some productive experimentation, but as it stands is not itself directly actionable, so I'm going to close it. There will be progress on a space discovery tool, probably something similar, but not identical, to tsiscover.

In the meantime if there is something left unresolved, please open another issue with details.