[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: On permathreads

naming your rifle

>   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

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: 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: permathread: was RE: on permathreads', the
original permathread notice, and any posts to the original RE:
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: 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.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.