response 10 of 16:

Jun 27 16:03 UTC 2007

In a sense, threading is already possible in Backtalk - you can say, for
instance "re resp:6" and Backtalk will create a link back to response
#6.  I guess that's not really full-blown threading in the sense it's
usually meant on mailing lists and usenet groups, though.  Not sure I'd
want that - when discussions can branch into sub-discussions and
sub-sub-discussions, following the whole thing becomes exponentially
cumbersome.  I like the strictly linear response structure that one has
in conferences here, and also in most blogging software.

Grex blogs provide an opportunity to make the rest of Grex more visible.
 I'd like to see sidebar links to the Grex home page and Backtalk
entrance page on every blog page, for example.

Again on the subject of linking, can the Backtalk blogging system avoid
the auto-linking flaw that currently exists for conferences?  What I'm
talking about is this.  Consider the statement:

    Be sure to check out item:agora,14 for the latest Happy Hour news.

Backtalk will link this to item 14 of the current Agora, which as I type
this is indeed about the Happy Hour.  Three months from now, Agora will
have been restarted, item 14 is likely to be about something completely
different, and the above statement will be wrong, making me look like an
idiot.  :)

I guess Backtalk is doing the best it can with that, given that there is
no built-in system of "unique identifiers" for items that is guaranteed
not to change over time.  I'm just wondering if this can be avoided for
the blogs, or even some day remedied for the conferences too.

response 12 of 16:

Jun 27 18:50 UTC 2007

Controls on linking:

  I'm currently writing a new access control scheme for Backtalk.  This
  will give very fine grained control of access in a conference.
  Depending on the conference configuration, these permissions will be
  editable either only by cfadm or by fairwitnesses for the conference.
  On Grex the fancy configuration settings will only be used for blogs,
  where they will be settable by the blog owners.  You'll be able to
  control exactly who may post, who may edit, erase, etc.  You'll also
  be able to control who can link items out of the conference, what
  conferences they can be linked to, and which items can be linked.
  The default will probably simple be not to allow linking out of
  blog items.

  Of course, this wouldn't in general, prevent Picospan from linking
  an item from a blog to a conference, since Picospan won't pay
  any attention to my access control settings.  But Picospan won't
  even have the blogs in it's conflist, so it won't know those
  conferences exist, and won't create any links from them.

The problem with the item:4 references in linked items, really goes back
to the fundamental half-wittedness of Picospan's data structures.  I
could solve the problem by expanding out the links at post time, so that
an links like item:14 would be automatically convertedinto
item:coop,14. But even that wouldn't suffice, because if coop restarts we'd
want the" coop" will no longer point to the same place.  Really we want ite
m:coop9,14 (or whatever).  Here "coop9" is something we hope will be a
uniquename for the conference, good forever.  But, in fact, given the Picospan
data structures, there is no way to find such a uniquename for a conference, or
to ensure that it remains unique.  To really solve this problem requires
creating some new data structures, and leaving picospan compatibility in the
dust.  Probably a good idea, on the whole.

Having trees of responses instead of a linear list of responses is sort
of the other major model of conferencing.  Backtalk inherits some
low-level infrastructure for that from Yapp.  In yapp, when you respond
to an item from the "respond or pass prompt" they you can say "resp 13"
to say that you are responding to response 13 of the item.  Yapp still
displays the responses in chronological order, but responses entered
that way will say <responding to response 13> or something on that, so
the "parent" of the response is stored.

I could write an interface that would actually display these as a tree.
 Then you'd be able to have a dual view of the same item.  From one
interface, it would look like a tree of responses, from another
interface it would look like linear list of response, with a lot of them
having "Re: response 23" kinds of headers.  I have never actually
implemented a hierarchical interface though, probably mostly because I
was never really very fond of them.  It'd be nice to do in an AJAX
interface, where you can expand out arbitrary subtrees though.

response 14 of 16:

Jun 28 02:01 UTC 2007

Not in a blog: only the blogger can start new items.  I think some will 
find the 'threaded' view more useful.  If the programmer wants to write it,
let's see how it works.

response 16 of 16:

Jun 30 00:21 UTC 2007

Re #14: Maybe the blogger should be able to choose whether the linear,
threaded, or both views are available to his/her readers.

Re #15: Yes, at a party you may move between groups and take part in
multiple discussions, but this is more like multiple items than it is
like multiple threads within an item.  Multiple threads is something
that would be impossible to do live.  It would mean taking part in
multiple discussions simultaneously, as well as starting new discussions
on the fly, and continuing the old ones as well.  The human mind is
incapable of the level of multitasking that would require.