[
Lists Home |
Date Index |
Thread Index
]
> If what you are suggesting
>is topic management, the topic maps guys are
>looking for you. ;-)
given that I don't much like topic maps they can keep looking. Quick, I
saw him running over into the RDFlands!! Get your rifle, Jed! :)
Anyway the following here are some not especially bright initial
thoughts on the subject:
Alaric's making a list, I don't like that idea though, lists require
human upkeep - in this case one human's upkeep. He probably has lots of
other things to do with his day.
Many people know what a permathread is, but there are always new people
coming and posting interesting things that rightfully belong to the
thread.
I'm not interested in a great solution to this, I'm interested in a
half-assed one that does something a little better than what was before,
worse is better.
Any old-timer on the list (of which I am certainly not one) is likely to
recognize the permathread when they see it. A worse is better solution
right off the bat is to say that the word permathread should never start
a subject unless said subject is a member of a permathread (I know it's
bad to rely on people for your data but I figure as a discussion starter
this is fine), so if there were a permathread on permathreads then all
someone would have to do is to repost this post as
Permathread: was RE:[xml-dev] on permathreads
This is somewhat related to a very rough proof-of-concept content
management for emails I worked up for our cms product, the demo was
written in rebol the user could define rules such as the above which
would then be used to go get all
'RE:[xml-dev] permathread: was RE:[xml-dev] on permathreads', the
original permathread notice, and any posts to the original RE:[xml-dev]
on permathreads thread, download them to a folder on the client, process
them to a very ugly xml format, copy the emails on the server to
mmx{foldernamecopiedtohere}{OriginalemailsubjectHere} so that the
regular email client could also keep track of it.
The permathread marker document can be added by the same person who
identified the post as a permathread, or it can be added later by
someone else, edited etc. I made an example sucky document with little
thought given to design, except for (snarky here) naming the element
that holds the date originally posted information.
So basically what it would be is something like the following:
1. the additions of permathread at the front of a subject
identifies a thread as a permathread.
2. a permathread.marker found inside of a post in a thread which
has 'permathread' at the front or 'RE:[xml-dev] permathread' at the
front of the subject line can be used to figure out which permathread
this actually belongs to.
3. The original thread can continue to run as the permathread
identified thread can be used to track it as a permathread.
Obviously many problems with this approach, but it's a first idea.
permathread.marker
|
