TiddlySpace [was Hoster Hacking Days]
Paul Downey
Gillies, Martin Budden and myself in the office, joined by Jeremy
Ruston.
First step was for us to all speed with the current version, and find
out what was missing by importing our own current TiddlyWeb and
TiddlyWiki projects.
This exercise was educational for those who hadn't yet used hoster,
and highlighted a few issues, one of which the UX when importing was
tackled by Mike and Ben, the other, a small Safari UI glitch I picked
up. We intended to continue with this approach, evolving Hoster to the
platform to meet BT's needs, in particular one canonical BT project
"Elvis".
But then Jeremy started to sketch out his vision of "TiddlySpace" (a
name suggested by Martin during discussion).
We already have TiddlyWiki, TiddlyWeb, TiddlyWebWiki, TiddlyHoster so
adding yet another name and project is, well tricky, but has merit in
that it concentrates on building an ecosystem of how Spaces will
interact with each other, even when they aren't hosted on the same
instance of Hoster, by introducing a additional constraints above
Hoster, TiddlyWikiWeb and TiddlyWeb.
My current understanding of these constrains are as follows:
* A TiddlySpace instance has users
* Each user is given a space, with the same name as their user, e.g. "psd"
* A space is a pair of recipes, with an associated bag: Public and Private
* When "psd" is logged in, and visit their space they see the output
of the Private Recipe
* When "psd" isn't logged in, he sees the output of the Public Recipe.
* When anyone else visits the space, they see the Public space
* There's a process of publishing from Private to Public (not yet
discussed in detail)
Then:
* A user may create a space with a different name, e.g. "psd" creates "osmosoft"
* A user may invite other users to the space, e.g. "psd" invites "FND"
to "osmosoft"
* All users in a space have the same privildges, i.e.
** "psd" may invite other people
** "FND" may invite other people
** "FND" may kick "psd" from the space
** "FND" may kick himself from the space+
** "psd" can kick himself from his own space+
+ strange, but recoverable out of band talking to an admin.
My current understanding is the space namespace is flat, so a user
can't be created if a space already exists with their name, and you
can't create a space using the name of an existing user.
So a space is designed for teams, "small groups of trusting users",
which raised a lot of discussion about collaboration patterns in
general, but does work well within an organisation, such as BT.
There's some way to go realising this vision so next week we'll hold a
TiddlySpaces day on Wednesday and Thursday to make progress by walking
through the URIs and wireframing the UI.
Most importantly, we'll start to build another prototype using the
Hoster code. Ideally we should devolve shared parts of the UI into
plugins we can share across Hoster, TiddlySpaces and other
TiddlyWeb/TiddlyWebWiki patterns.
Michael blogged a note of the vision diagram:
And I captured the whiteboard following the constraints discussion, here:
http://www.flickr.com/photos/psd/4314304768/
--
Paul (psd)
http://blog.whatfettle.com
chris...@gmail.com
> We held our first Hoster Hacking day, with Michael Mahemoff, Ben
> Gillies, Martin Budden and myself in the office, joined by Jeremy
> Ruston.
Thanks for providing this summary, I was hoping somebody would, as
from the IRC side of things it was clear stuff was happening, but not
what that stuff was.
> First step was for us to all speed with the current version, and find
> out what was missing by importing our own current TiddlyWeb and
> TiddlyWiki projects.
After observing how people are using hoster, thus far, I've got some
comments on importing, development and related stuff (below).
> Most importantly, we'll start to build another prototype using the
> Hoster code. Ideally we should devolve shared parts of the UI into
> plugins we can share across Hoster, TiddlySpaces and other
> TiddlyWeb/TiddlyWebWiki patterns.
This is very good to hear. Devolution of stuff sometimes seems like a
pain in the ass, but it helps to create boundaries and containers.
It is at the boundaries of things where bugs are most likely to be found.
In the longer run the extra work creates a more maintainable system.
There's a delicate balance between trying to optimize for development
_now_ or taking care of things later.
There's a fair amount of stuff in the tiddlyhoster package which can
likely be pulled to its own thing, for example the
tiddlywebplugins.hoster.serialization module, which makes for a
"pretty" recipe and bag listing page would be nice to be able to run
on tiddlyweb.peermore.com but I don't really want to make that site a
tiddlyhoster instance (yet).
Now might also be a good time to mention some of the hackability that
is built into how templates are handled in any tiddlyweb package that
uses the tiddlywebplugins.templates: By default the template files are
pulled from the Python site-lib, however you can override one or more
of the templates by making a 'templates' dir in the instance dir, and
copying in a copy of the original template file and then modifiying
it. This can be a useful way to hack on the presentation if you're not
of a mind to mess with the Python code etc.
On importing wiki's and other stuff: The wimporter tool has proven
more useful than I expected. I put it together because, in my usual
fashion, I wanted to demonstrate that something was possible. Once
that something was shown to be possible I was assuming that further
experimentation would lead to alternate tools that did it better. In a
sense this is happening with the work Mike and Ben are doing to
improve wimporter and bimport however that stuff is in the same model:
From an interface hosted by the target server select some stuff which
will bring into this server.
That's clearly a useful and powerful model, but there's another which
I'd like to see but don't really have the TiddlyWiki chops to just
kick out (like I did with wimporter). I want to be able, while in a
file:/// based TiddlyWiki, to select N tiddlers, set their server.host
and server.type and server.workspace fields and press a <PUSH> button
to send them to server.host. Besides the different ordering in this
model, it also changes what is the first class entity in the import
process. It takes it to the tiddler, which is the TiddlyWebWay.
Besides just being useful, it will also build the TiddlyWiki side code
which allows for easy management/manipulation of server.host,
server.type, server_workspace. Once that is present it becomes
relatively easy to accomplish several feats, from within a TiddlyWiki:
* move tiddlers between bags
* move tiddlers between tiddlyweb servers
* move "tiddlers" from a mediawiki server, Twitter, anything else
TiddlyWiki has adaptors for to some other place (including a tiddlyweb
server)
All in the control of the individual sitting with the TiddlyWiki,
without the need for complex server interfaces.
In theory all the bits necessary for this handling are present in
TiddlyWiki already, it's a matter of assembling them into a useful
plugin.
For those TiddlyWikis that are on http:// instead of file:/// proxy
handling could be used.
I hope that makes some sense. I fear that TiddlyWeb perhaps makes
server side changes _too_ easy and thus people tend to think about
extending its functionality by modifying things there. In its earliest
conception, though, TiddlyWeb was designed to be headless, with
TiddlyWiki and other javascript laden pieces of HTML being the locus
of innovation, experimentation and interface. This continues the
patterns of behavior that make the web good: push intelligence to the
edges and the individuals.
--
Chris Dent http://burningchrome.com/~cdent/
[...]
Paul Downey
> Thanks for providing this summary, I was hoping somebody would, as
> from the IRC side of things it was clear stuff was happening, but not
> what that stuff was.
We could try and to become more formal with an agenda, scribe, and
dial-in but it's always very hard to involve people remotely when
there is a critical mass conversing and working informally face to
face.
chris...@gmail.com
Yes, I'm not suggesting anything change. I think the right thing
happened here: You had a useful chat, and the outcome was posted here.
So all that's all good.
FND
> outcome was posted here.
Indeed - thanks for relaying that, Paul!
FWIW, I agree with Chris that we should aim for functionality to be
provided via the client wherever possible.
-- F.
Paul Downey
> FWIW, I agree with Chris that we should aim for functionality to be provided
> via the client wherever possible.
Agreed, and one of the motivations for creating another
plugin/project/layer is to separate the concerns of the client-side UI
from the server-side platform, which we see as being TiddlyWikiWeb +
some small, generic plugins.