iamb-dev — Development mailing list. Discussion of implementation.

Re: [Iamb-dev] CVS: iamb admin.cgi,1.3,1.4

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> so it appears auto-diffs are working again? sorry for the double post,
> folks.

Well, it is, sort of, but it's not a diff -u, so they are exceptionally
hard to read.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] CVS: iamb admin.cgi,1.3,1.4

[Matt C. <su...@qx...>]

so it appears auto-diffs are working again? sorry for the double post,
folks.


------
Matt Cashner
Web Applications Developer
Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

[Iamb-dev] CVS: iamb/setup IAMB.mysql,1.2,1.3

[Matt C. <su...@us...>]

Update of /cvsroot/iamb/iamb/setup
In directory usw-pr-cvs1:/tmp/cvs-serv23365/setup

Modified Files:
	IAMB.mysql 
Log Message:
patch for forums. need a misc forum to catch existing threads

Index: IAMB.mysql
===================================================================
RCS file: /cvsroot/iamb/iamb/setup/IAMB.mysql,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -r1.2 -r1.3
*** IAMB.mysql	2000/12/24 02:28:21	1.2
--- IAMB.mysql	2001/01/07 21:58:28	1.3
***************
*** 77,78 ****
--- 77,84 ----
  );
  
+ #
+ # Dumping data for table 'forum'
+ # 
+ 
+ INSERT INTO forum VALUES (0, 'Misc', 'This forum is a collection of unassigned threads.', NULL);
+ 

[Iamb-dev] CVS: iamb admin.cgi,1.3,1.4

[Matt C. <su...@us...>]

Update of /cvsroot/iamb/iamb
In directory usw-pr-cvs1:/tmp/cvs-serv23301

Modified Files:
	admin.cgi 
Log Message:
now forum aware. admin interface to forums coming soon.

Index: admin.cgi
===================================================================
RCS file: /cvsroot/iamb/iamb/admin.cgi,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -r1.3 -r1.4
*** admin.cgi	2000/12/11 02:35:00	1.3
--- admin.cgi	2001/01/07 21:57:37	1.4
***************
*** 22,81 ****
  #################################################
  
! =head2 Main
  
! Regurgitates a template file.
  
  =cut
  
! sub Main	{
! 	my ($iamb) = @_;
! 	my ($template, $details, );
  
- 	$template = 'admin';
- 	$details = {};
- 	return ($template, $details);
- }  #  End sub Main
  
! =head2 ListThreads
  
! Lists threads, with the option of deleting the entire thread. This
! is the default view of the admin interface.
  
! To Do: Remove HTML from this function.
  
  =cut
- 
- sub ListThreads	{
- 	my ($iamb) = @_;
- 	my ($template, $details, $sth,
- 		$id, $updated, $title,
- 	    );
  
!      my $art = $iamb->articles;
!      my $thr = $iamb->threads;
! 	$sth = $iamb->dbh->prepare("select $thr.ID, $thr.updated,
! 		$art.title from $thr, $art
! 		where $art.ID = $thr.ID
! 		order by updated desc
! 		");
! 	$sth->execute;
! 	$sth->bind_columns(undef, \($id, $updated, $title));
! 	while ($sth->fetch)	{
! 		my $threadstats = $iamb->ThreadStats($iamb->dbh, $id);
! 		$updated =  strftime '%D', localtime($updated);
! 		my $s = ($threadstats->{count} > 1) ? 's' : '';
! 		$details->{list} .= qq~
! 		<li><a href="index.cgi?action=Article&article=$id">$title</a>
! 		<small>($threadstats->{count} article$s total,
! 		last post $updated)</font>
! 		[ <a href="admin.cgi?action=Delete&thread=$id">Delete thread</a> ]
! 		~;
! 		$details->{threadcount}++;
! 	} # Wend
!      $sth->finish;
! 
! 	$template = 'threadlist';
! 	return ($template, $details);
! } # End sub ListThreads
  
  =head2 Delete
--- 22,109 ----
  #################################################
  
! =head2 ListThreads
! 
! The name is a bit deceptive here but is kept for backward 
! compatibility. Lists Forums and their Threads. This is the 
! default view of the admin interface (For now).
  
! To Do: Remove HTML from this function
  
  =cut
  
! sub ListThreads {
!     my $iamb = shift;
!     my $art = $iamb->articles;
!     my $thr = $iamb->threads;
!     my ($template, $details);
!     
!     my $sth = $iamb->dbh->prepare("SELECT ID, forum FROM forum");
!     $sth->execute();
! 
!     my $sth2 = $iamb->dbh->prepare("SELECT $thr.ID,
!                                            $thr.updated, 
!                                            $art.title
!                                       FROM $thr, $art
!                                      WHERE $art.ID = $thr.ID
!                                        AND forumID = ?
!                                      ORDER BY updated DESC
!                                   ");
!     
!     $details->{list} = "<b>Forums</b><ul>\n";    
!     while(my $forum = $sth->fetchrow_hashref) {
!         $details->{list} .= "<li>$forum->{forum}</li><ul>\n";
!         $details->{list} .= ListForumThreads($iamb,$forum->{ID}); 
!     }
!     $details->{list} .= "</ul>\n";
!     $template = 'threadlist';
!     return ($template,$details);
! }
  
  
! ###########################
! =head2 ListForumThreads
  
! Lists the Threads for a given Forum. Gives the option of deleting 
! an entire thread.  
  
! To Do: There be HTML here! ARRRR!
  
  =cut
  
! sub ListForumThreads {
!     my ($iamb,$forumid) = @_;
!     my $art = $iamb->articles;
!     my $thr = $iamb->threads;
!     my $list;
!     
!     $forumid ||= 0;
!     
!     my $sth2 = $iamb->dbh->prepare("SELECT $thr.ID,
!                                            $thr.updated, 
!                                            $art.title
!                                       FROM $thr, $art
!                                      WHERE $art.ID = $thr.ID
!                                        AND forumID = ?
!                                      ORDER BY updated DESC
!                                   ");
!         
!     $sth2->execute($forumid);
!     my ($id, $updated, $title);
!     $sth2->bind_columns(undef, \($id, $updated, $title));
!     while (my $thread = $sth2->fetchrow_hashref()) {
!         my $threadstats = $iamb->ThreadStats($iamb->dbh,$thread->{ID});
!         $updated = strftime '%D', localtime($updated);
!      	my $s = ($threadstats->{count} > 1) ? 's' : '';
! 	    $list .= qq#
! 	    <li><a href="index.cgi?action=Article&article=$thread->{ID}">$title</a>
! 	    <small>($threadstats->{count} article$s total,
! 	    last post $updated)</font>
! 	    [ <a href="admin.cgi?action=Delete&thread=$thread->{ID}">Delete thread</a> ]
! 	    #;
!     }
!     $list .= "</ul>\n";
!     $sth2->finish;
!     return $list;
! }
  
  =head2 Delete
***************
*** 203,206 ****
--- 231,237 ----
  
       $Log$
+      Revision 1.4  2001/01/07 21:57:37  sungo
+      now forum aware. admin interface to forums coming soon.
+ 
       Revision 1.3  2000/12/11 02:35:00  rbowen
       Functions are not interpolated in quoted strings.

[Iamb-dev] first forum patch

[Matt C. <su...@qx...>]

the following is the first patch for forum code. actually there are two
diffs involved here. one for the sql stuff that creates a Misc forum which
holds all unassigned threads (all existant threads will appear in this
forum).  a second patch, large, which makes admin.cgi forum aware.  

coming soon: an actual admin interface to forums.

diffs follow .sig

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

--------------------------
Index: setup/IAMB.mysql
===================================================================
RCS file: /cvsroot/iamb/iamb/setup/IAMB.mysql,v
retrieving revision 1.2
diff -u -r1.2 IAMB.mysql
--- setup/IAMB.mysql	2000/12/24 02:28:21	1.2
+++ setup/IAMB.mysql	2001/01/07 21:50:37
@@ -76,3 +76,9 @@
   updated int(11)
 );
 
+#
+# Dumping data for table 'forum'
+# 
+
+INSERT INTO forum VALUES (0, 'Misc', 'This forum is a collection of unassigned threads.', NULL);
+

Index: admin.cgi
===================================================================
RCS file: /cvsroot/iamb/iamb/admin.cgi,v
retrieving revision 1.3
diff -u -r1.3 admin.cgi
--- admin.cgi	2000/12/11 02:35:00	1.3
+++ admin.cgi	2001/01/07 21:50:06
@@ -21,62 +21,90 @@
           );
 #################################################
 
-=head2 Main
+=head2 ListThreads
+
+The name is a bit deceptive here but is kept for backward 
+compatibility. Lists Forums and their Threads. This is the 
+default view of the admin interface (For now).
 
-Regurgitates a template file.
+To Do: Remove HTML from this function
 
 =cut
 
-sub Main	{
-	my ($iamb) = @_;
-	my ($template, $details, );
-
-	$template = 'admin';
-	$details = {};
-	return ($template, $details);
-}  #  End sub Main
+sub ListThreads {
+    my $iamb = shift;
+    my $art = $iamb->articles;
+    my $thr = $iamb->threads;
+    my ($template, $details);
+    
+    my $sth = $iamb->dbh->prepare("SELECT ID, forum FROM forum");
+    $sth->execute();
+
+    my $sth2 = $iamb->dbh->prepare("SELECT $thr.ID,
+                                           $thr.updated, 
+                                           $art.title
+                                      FROM $thr, $art
+                                     WHERE $art.ID = $thr.ID
+                                       AND forumID = ?
+                                     ORDER BY updated DESC
+                                  ");
+    
+    $details->{list} = "<b>Forums</b><ul>\n";    
+    while(my $forum = $sth->fetchrow_hashref) {
+        $details->{list} .= "<li>$forum->{forum}</li><ul>\n";
+        $details->{list} .= ListForumThreads($iamb,$forum->{ID}); 
+    }
+    $details->{list} .= "</ul>\n";
+    $template = 'threadlist';
+    return ($template,$details);
+}
 
-=head2 ListThreads
+
+###########################
+=head2 ListForumThreads
 
-Lists threads, with the option of deleting the entire thread. This
-is the default view of the admin interface.
+Lists the Threads for a given Forum. Gives the option of deleting 
+an entire thread.  
 
-To Do: Remove HTML from this function.
+To Do: There be HTML here! ARRRR!
 
 =cut
 
-sub ListThreads	{
-	my ($iamb) = @_;
-	my ($template, $details, $sth,
-		$id, $updated, $title,
-	    );
-
-     my $art = $iamb->articles;
-     my $thr = $iamb->threads;
-	$sth = $iamb->dbh->prepare("select $thr.ID, $thr.updated,
-		$art.title from $thr, $art
-		where $art.ID = $thr.ID
-		order by updated desc
-		");
-	$sth->execute;
-	$sth->bind_columns(undef, \($id, $updated, $title));
-	while ($sth->fetch)	{
-		my $threadstats = $iamb->ThreadStats($iamb->dbh, $id);
-		$updated =  strftime '%D', localtime($updated);
-		my $s = ($threadstats->{count} > 1) ? 's' : '';
-		$details->{list} .= qq~
-		<li><a href="index.cgi?action=Article&article=$id">$title</a>
-		<small>($threadstats->{count} article$s total,
-		last post $updated)</font>
-		[ <a href="admin.cgi?action=Delete&thread=$id">Delete thread</a> ]
-		~;
-		$details->{threadcount}++;
-	} # Wend
-     $sth->finish;
-
-	$template = 'threadlist';
-	return ($template, $details);
-} # End sub ListThreads
+sub ListForumThreads {
+    my ($iamb,$forumid) = @_;
+    my $art = $iamb->articles;
+    my $thr = $iamb->threads;
+    my $list;
+    
+    $forumid ||= 0;
+    
+    my $sth2 = $iamb->dbh->prepare("SELECT $thr.ID,
+                                           $thr.updated, 
+                                           $art.title
+                                      FROM $thr, $art
+                                     WHERE $art.ID = $thr.ID
+                                       AND forumID = ?
+                                     ORDER BY updated DESC
+                                  ");
+        
+    $sth2->execute($forumid);
+    my ($id, $updated, $title);
+    $sth2->bind_columns(undef, \($id, $updated, $title));
+    while (my $thread = $sth2->fetchrow_hashref()) {
+        my $threadstats = $iamb->ThreadStats($iamb->dbh,$thread->{ID});
+        $updated = strftime '%D', localtime($updated);
+     	my $s = ($threadstats->{count} > 1) ? 's' : '';
+	    $list .= qq#
+	    <li><a href="index.cgi?action=Article&article=$thread->{ID}">$title</a>
+	    <small>($threadstats->{count} article$s total,
+	    last post $updated)</font>
+	    [ <a href="admin.cgi?action=Delete&thread=$thread->{ID}">Delete thread</a> ]
+	    #;
+    }
+    $list .= "</ul>\n";
+    $sth2->finish;
+    return $list;
+}
 
 =head2 Delete
 

Re: [Iamb-dev] API, development, etc

[Ken R. <kr...@qx...>]

Rich Bowen wrote:
> 
> I'm increasingly distressed/confused/irritated by the tone that
> discussion is taking. It seems that we are indeed discussing,
> redeciding, and rehashing, the same issues multiple times. That is,
> without a doubt, suboptimal.

I also have been distressed, even while being a party to it.

My first approximation to a reason for it is this. Matt has been
working on what was decided; I have been working on what I thought
had been decided, which, it seems, is quite different.

> Anyways, it would be really nice if we could get actual tasks up on
> sourceforge, and get those tasks assigned to people, so that people are
> very clear as to what they are working on. We also need to get
> documented some of the decsions that have been made in a rather ad-hoc
> manner, so that we can mark them as decided and move on with life.

I would definitely agree on both. I hereby encourage Matt to
come up with a statement of all that was decided (since I no
longer trust my memory on this), and a list of tasks based on
it. I do want to participate, and I don't want to alienate as
valuable a member as Matt.

> I'm also rather used to working on projects like this without any
> expectation that nobody is going to contribute much, and so I tend to
> view all contributions as a good thing. I suppose that this attitude
> will go away as there is more contribution.

I understand. I wouldn't want to stick my foot in that bear
trap twice, either.

-- Ken

Re: [Iamb-dev] Throwing the APIs to the lions

[Ken R. <kr...@qx...>]

> > The reason that we need the API as I did it is because we have
> > not settled on the stringified tree approach. We first have to
> > figure out what needs to be done, and then decide that the
> > stringified tree will do it, and then start the coding. We can't
> > commit to a data structure that makes our work harder, and we
> > need to define our work before we make that decision.
> 
> we've had this discussion at least five different ways now. we've settled
> most of the issues you've raised. or am i hallucinating an entire
> implementation discussion.

Peace offering: Now that I have put out a preliminary API for the
higher-level calls (still open to discussion and change), would you
like me to next produce lower-level APIs for the stringified tree
structure that supports those APIs? I got from an earlier post that
this is what you were looking for.

> > Blunt reply: Rich lays down laws here, not you. You play by his
> > rules or not at all. He might accept what you say, but he makes
> > the final call.
> 
> i'm not going to get into a pissing contest here except to say that i am
> managing the development branch of this situation and that is what this is
> concerning. yes this is rich's baby but i'm sure rich would love it if we
> took some initiative of our own. that's why the development branch, with
> me (not rich) at the helm, was created. you signed up for the development
> branch knowing who was the project leader. yes, my "leadership" style is
> very firm and sometimes not very tolerant. and if you have issues with
> that, we can discuss them.

I can tolerate (and have tolerated for years) a vast range of
leadership styles, including blunt. I tend to prefer blunt over
squishy; at least I know where I stand. And I apologize; I had
forgotten that you are indeed the leader of this branch.

On the other hand, please know that my follower-ship style
varies with leadership style. With a blunt leader, I will be
a blunt follower. If that is unacceptable, I have plenty of
other things I can be doing, too.

> > I said it above, but remember that we are still exploring how
> > we are going to do all this. You have some good ideas, and we
> > will certainly use them. But you aren't the only one with good
> > ideas, and if you refuse to use what others come up with, this
> > is no longer a team project.
> 
> you want to know what the crux of the matter is? we're renegotiating
> something we spent months bitching and fighting about.  as i said all
> those months ago, i am quite tired of discussing this again and again. i'm
> interested in writing code, good code perhaps.  maybe i should just
> disappear for a while and write up a first code draft of my ideas. but
> then again, maybe i should just disappear all together. it seems the
> stable branch is all about rich doing stuff. and the development branch
> has become all about talking. i am interested in neither. so i dont
> know...

Let me (bluntly) predict what would happen if you vanish then
reappear with the code roughed out: just what happened with Rich.
He became the single person doing almost everything because no
one else understood the fine points of what was going on. Maybe
you'd like that, and it might produce great code that crushes
all competitors, but in the case that you move on, the rest of us
will be stuck again right where we are now.

The reason for the team project approach is to avoid that scenario.
There would be a core of people, all of whom have rather detailed
knowledge, and which could survive the exit of one or several
members. Besides, many eyes make bugs more obvious.

One final note: The months of haggling were not wasted. Perhaps
you have not yet learned that with any large project, planning
is at least as important as coding, and getting everyone on the
same frequency reduces static as you proceed. My delay in getting
the API out was unavoidable, but unfortunate. At least I now have
a detailed understanding of what needs to be going on, and the
API has condensed a lot of that down.

-- Ken

[Iamb-dev] API, development, etc

[Rich B. <rb...@rc...>]

I'm increasingly distressed/confused/irritated by the tone that
discussion is taking. It seems that we are indeed discussing,
redeciding, and rehashing, the same issues multiple times. That is,
without a doubt, suboptimal. It would also seem, however, that we are
typically going so long between times of active development that things
are getting forgotten. The "Coding Day" event was, at best, a good time
for a variety of people to meet one another and brainstorm about a
project that most of them would not, in fact, end up working on. I
expect that some good things came out of it - I was rather uninvolved in
the discussion that actually produced meaningful results. Pity, that,
since it's becoming increasingly clear that I'd like to be more involved
in that side of things.

Anyways, it would be really nice if we could get actual tasks up on
sourceforge, and get those tasks assigned to people, so that people are
very clear as to what they are working on. We also need to get
documented some of the decsions that have been made in a rather ad-hoc
manner, so that we can mark them as decided and move on with life.

The RFC process seems to have been rather useful, when it has been used
well. Since I seem to spend most of my life writing documentation
anyway, I might try to write some docs today. I really need to get an
Apache article written, but I don't have a topic just yet.

I'm also rather used to working on projects like this without any
expectation that nobody is going to contribute much, and so I tend to
view all contributions as a good thing. I suppose that this attitude
will go away as there is more contribution.

I know, I'm rambling somewhat here. Ignore me. But I think that having
well-defined (and documented) tasks would greatly decrease the
perception that nobody is working on what we think they should be. Which
is, in itself, a strange concept on a volunteer project ...

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Throwing the APIs to the lions

[Matt C. <su...@qx...>]

On Sun, 31 Dec 2000, Ken Rietz wrote:

> The reason that we need the API as I did it is because we have
> not settled on the stringified tree approach. We first have to
> figure out what needs to be done, and then decide that the
> stringified tree will do it, and then start the coding. We can't
> commit to a data structure that makes our work harder, and we
> need to define our work before we make that decision.

we've had this discussion at least five different ways now. we've settled
most of the issues you've raised. or am i hallucinating an entire
implementation discussion? 

> Blunt reply: Rich lays down laws here, not you. You play by his
> rules or not at all. He might accept what you say, but he makes
> the final call.

i'm not going to get into a pissing contest here except to say that i am
managing the development branch of this situation and that is what this is
concerning. yes this is rich's baby but i'm sure rich would love it if we
took some initiative of our own. that's why the development branch, with
me (not rich) at the helm, was created. you signed up for the development
branch knowing who was the project leader. yes, my "leadership" style is
very firm and sometimes not very tolerant. and if you have issues with
that, we can discuss them. 

> I said it above, but remember that we are still exploring how
> we are going to do all this. You have some good ideas, and we
> will certainly use them. But you aren't the only one with good
> ideas, and if you refuse to use what others come up with, this
> is no longer a team project.

you want to know what the crux of the matter is? we're renegotiating
something we spent months bitching and fighting about.  as i said all
those months ago, i am quite tired of discussing this again and again. i'm
interested in writing code, good code perhaps.  maybe i should just
disappear for a while and write up a first code draft of my ideas. but
then again, maybe i should just disappear all together. it seems the
stable branch is all about rich doing stuff. and the development branch
has become all about talking. i am interested in neither. so i dont
know...

tonight is not a good night to think about such things. my mood is sour
enough without this nonsense...

/quit

. o O (oh wait. wrong protocol)

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Throwing the APIs to the lions

[Ken R. <kr...@qx...>]

I have to digest what Rich and you wrote, but here are my reactions
to your preliminaries.

> let me preface this with a bit of a rant.

Rants accepts. Just not always obeyed.

> this document was not what i
> requested. the api i requested was an api for the stringified tree
> structure, ala smashed threads, so that i could write some code to deal
> with them.  i did not want to get this far a field without a firm grasp of
> how the data was going to represented in the database. as such, i'm not
> very pleased with this.

Blunt it is: The purpose of this project is not to make you (or
me) happy. Or Rich, for that matter, though he would be happy
with clean, functional code, and that we ought to do.

The reason that we need the API as I did it is because we have
not settled on the stringified tree approach. We first have to
figure out what needs to be done, and then decide that the
stringified tree will do it, and then start the coding. We can't
commit to a data structure that makes our work harder, and we
need to define our work before we make that decision.

> i am further not pleased with this because some
> very basic things we have discussed have been left out, namely a firm
> grasp of the OO nature of the backend code. yes, i'm being very blunt here
> and i'm not meaning to step on toes but we need to get the focus back and
> not spend eons discussing suboptimal ideas. i dont have any desire to
> discuss anymore.

The API does not mandate any particular approach, as far as I
can see. The OO nature of the backend is in the implementation
of the final API as we determine it.

> also a word of warning: i'm going to be laying out some law here. these
> are things we have discussed until i am tired of them and we are going to
> stick to those decision. so bear with me here folks.

Blunt reply: Rich lays down laws here, not you. You play by his
rules or not at all. He might accept what you say, but he makes
the final call.

If it's your way or the highway, I hope you brought your boots.

I said it above, but remember that we are still exploring how
we are going to do all this. You have some good ideas, and we
will certainly use them. But you aren't the only one with good
ideas, and if you refuse to use what others come up with, this
is no longer a team project.

More later. Gotta go to a New Year's Eve thing.

-- Ken

Re: [Iamb-dev] Throwing the APIs to the lions

[Matt C. <su...@qx...>]

let me preface this with a bit of a rant. this document was not what i
requested. the api i requested was an api for the stringified tree
structure, ala smashed threads, so that i could write some code to deal
with them.  i did not want to get this far a field without a firm grasp of
how the data was going to represented in the database. as such, i'm not
very pleased with this. i am further not pleased with this because some
very basic things we have discussed have been left out, namely a firm
grasp of the OO nature of the backend code. yes, i'm being very blunt here
and i'm not meaning to step on toes but we need to get the focus back and
not spend eons discussing suboptimal ideas. i dont have any desire to
discuss anymore. 

also a word of warning: i'm going to be laying out some law here. these
are things we have discussed until i am tired of them and we are going to
stick to those decision. so bear with me here folks.

On Sun, 31 Dec 2000, Rich Bowen wrote:

> > 5. One thing I still don't know: Where is the stringified threaded data
> > structure (what Dan came up with during coding day) going to be stored?
> > It needs to be in memory a lot, for rapid updating, but also needs to be
> > on disk. The iamb_int_verifyDB() call should reconstruct the string from
> > the database and compare it to memory and the disk versions, and correct
> > them, if necessary. As I see it, every forum will have its own
> > stringified data structure.
>
> I think that's right. However, there was and is still some disagreement
> as to whether this piece of data belongs to a thread or to a forum.
> Personally, I still think it belongs to a thread, and will be
> unmanageable and/or unusable and/or icky if it is attached to the wrong
> place.

we've talked bout this at _Great_ length tho that seems to have been
forgotten.  tree structures belong to threads. period. i want the ability
to move a thread to a different forum without rewriting a massive tree
structure.  there will be no forum tree structures. forums are separate
from threads. period.

as for where the tree structures are going to live:  they will live
partially in the database and partially in memory.  the whole purpose of
my original api request was so i could write a daemon to handle the atomic
changes necessary for this tree structure.  the daemon will hold the keys
and will write back to the database when deemed necessary (say if no
changes have taken place to a tree structure in 5 seconds. tis arbitrary
tho).  the purpose of the daemon was to minimize database reads and writes
and to prevent data collisions when two processes attempt to make atomic
changes at the same time.


> > 1. The names of all the calls start with iamb_int, just for simplicity
> > of identification and clarity at this stage of the game. That part of
> > the name can be deleted before production occurs.
> 
> +1 on deleting that part of the name. +1 on leaving it there for the
> purposes of this discussion. +2 on making method names as small and
> concise as possible.

ugh. unnecessary and annoying. and it looks too much like C code a certain
prof forced me to write.

> I wonder if we can return an error object which has nice properties like
> being able to give you a useful error message, but also to be able to
> test it for truth. Or, perhaps, like DBI, you return 1 for success, 0

beautiful idea. a numeric error, a true false error, and a stringified
error.

> > 3. All input parameters are named. This is to avoid the jumble of
> > remembering which order parameters should be in for each of the calls.
> 
> Amen and Halelujah.

praise jesus

> > ====================================
> > -Call: iamb_int_initializeDB(??);
>
> Ooh. Bleah. Maybe you did get too ambitious. I don't know. Perhaps this
> one needs to be considered by our installation guru. Matt? I question
> the sense of having a method call that will get used once in the life of
> an installation.

ok. you can assume that you have valid database information. when this is
installed, all configuration information will be triplechecked. i'll
undoubtedly be templatizing some code to get this into the system but
yeah. assume you have valid database, template, etc information at all
points. make no attempt to correct for bad information from the config in
every piece of code. the installer will take care of this. 

> > -Call: iamb_int_verifyDB(??);
> > -Input parameters: ??
> > -Return value(s): 1/0 (success/failure)
> > -Description: This call should check the status of the database files,
> > verify their consistency, and output potential problems with proposed
> > remedies. Again, until more has been determined, the exact parameters to
> > pass will be subject to change.

bah and double bah. the code will simply fail if they've fubar'd the
database. also, this is a STATELESS system. do you really want to check
database integrity every time a cgi process gets launched. silly and very
not right.  

to quote murphy's law: make a system that even a moron can use and ony
morons will use it.

> > =====================================
> > -Call: $forumID = iamb_int_newForum(DATABASE => $dbh);
> 
> Objection, your honor. I would like the database handle to magically
> appear out of the air. I don't want to have to pass it in. Perhaps this
> is unreasonable, but I want it anyway. I have some vague ideas about how
> to make this possible. Some of them involve mod_perl, but I'd like to
> avoide *requiring* mod_perl to run this. We can discuss this more in the
> implementation stage, but I want to make it clear that that's what I
> want.

hear hear!  the database handle should be part of the object that get
carted around. dont make me ever think about the fact that i'm using a
database. i should never have to realize that i'm working with a database
and thus need a database handle.

ok. i dont have time to think about the rest right now esp since the forum
stuff, imnsho, is just wrong.  here's my read on forums. forums are a
sepearate entity from everything else. they have a name, a description,
and a control list. threads know what forum they are in. articles know
what threads they are in. etc etc. this is the circle of life in IAMB (cue
music) 

ok. i really must go. migraine meds are wearing off.

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Throwing the APIs to the lions

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> On Sun, 31 Dec 2000, Rich Bowen wrote:
> 
> > > 2. All IDs should be the IDs of the root articles. That is, the forum ID
> > > is the ID of the root article of the forum.
> >
> > What the heck does that mean? What is the root article of a forum?
> 
> i havent had a chance to fully grok this document yet either. but if this
> statement says what i think it does, i dont like it. in order for the
> forum code i've been working to actually function, the forum has to be a
> separate entity from the articles.  articles belong to a forum and a forum
> has articles.  now, my code is expendable as always but i think the
> concept is valid.  because otherwise i cannot create a forum with creating
> an article first, which seems silly. of course, maybe i'm completely
> misunderstanding :)

I think that a forum needs to be able to exist without any content. It
makes sense if you think about it from a usage perspective, rather than
a code perspective (which, of course, we should be striving to do). I
want to talk about geek things, I go into the geek forum. I want to talk
about my pet, the pet forum. I want to just blather, I go into the
general forum.

Hmm. Would it be useful to be able to tag a particular article as
belonging to multiple fora? I know, cross posting is the bane of Usenet,
but it might be useful to post a technical-political article
occasionally. Supreme Court rulings on encryption. Microsoft antitrust
rulings. Etc.

Gotta go. The little one is crying.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Re: forums

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> also:
> 
> > Yes, public vs private forums is in the task list already, under the
> > guise of access control lists. The idea is that public forums
> > don't get access control lists (unless it is ban lists) and private
> > forums have to have one.
> 
> is there documentation on this that i've missed somewhere?

No documentation per se. Just a task item.
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=22271&group_id=14613&group_project_id=5910
Geez, I hate SourceForge URLs.

And I discussed it briefly in another missive that I emitted today.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] forums

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> > There are a number of places where code assumes that theres only one
> > forum. Notably, the admin interface. But it's also elsewhere. This
> > needs to be corrected, as it can cause some damage in places. The update
> > unread function is another place where it could cause problems.
> 
> am finally getting around to hacking code :) UpdateUnread is already
> Forum-aware. the rest of IAMB.pm seems Forum-aware as well. i'm getting
> ready to crack admin and fix the issues there. also, any strange forum
> related functions that people want in the module?

My thoughts about forums are rather unforumed ... er ... unformed, most
of the time. But I have some of the following random thoughts:

Forums should have an administrator. This person is not necessarily the
uber-administrator, but is just a user (or perhaps the ability to have
more than one user would be handy to leave open). That user can do
admin-type stuff in that forum.

I'd like (eventually) to be able to say either who is permitted into the
forum (a guest list) or who is to be kept out (a bouncer list). I don't
think that you'd want to have both at one time. It's either allow or
deny. In Apache terminology, it's either "deny from all, allow from
192.168.1" or "allow from all, deny from 192.101.204". I don't think
that this needs to be worked in from the ground, but it might. I have
not thought it through very thoroughally yet.

I also have a desire, which I don't think I've expressed before in this
mailing list, for a furm to be aware of what is being discussed in it,
to a degree. I'm not sure entirely what this means, but I can give two
examples. One, the "links for today" feature. That is, the ability to
pull out what URLs have been mentioned in discussions today. This would
be extremely useful in a news-oriented discussion forum like the Kenya
site. Two, and I don't have any idea how to do this well, the ability to
have a headline page linking into articles. Perhaps a list of hot
topics, or words that seem to be being discussed a lot today. Today on
the Kenya site, for example, everyone is talking about the loony Kenyan
that tried to crash a BA flight from London to Nairobi, and very nearly
succeeded. How do we get that sort of thing to be pulled out to a SSI
link on the front page of the site? For the record, it would seem that
item one is doable, and item two is really not, but it would be neat.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Throwing the APIs to the lions

[Rich B. <rb...@rc...>]

My comments, an executive summary.

In general, I think that Ken has all the bases covered on this. I have
of late, however, become quite the OO-zealot, and would comment
additionally that I think that we could stand to draw some pictures
before we go much farther. I think that IAMB lends itself very well to
being entirely unapologetically OO from the very ground up, and that
user-code (by which I mean code that the programmer writes to do mundane
things - CGI code, in this particular context) should never have to
think about things like databases, reading and writing files, or
outputting HTML. It should create objects, twiddle with the attributes
of those objects, and move on with life, and that the objects themselves
should take care of such administrative details as reading from the
database, writing to DBM files, printing correctly MIME'ed output, and
sending email messages.

It is my opinion (and this is just an opinion, not an executive edict,
and is entirely subject to the whims of the folks that actually write
source code) that articles, threads, forums, and users, are the basic
objects in this product, and that everything worth talking about is the
attributes of those objects, and their relationships with one another.

But, in the long run, we're after "rough consensus and working code." If
it works, to an extent, I'm happy with it.

This is a good first draft of the API, and we should move on from here.
Now, I'll go respond to Matt's messages.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Throwing the APIs to the lions

[Rich B. <rb...@rc...>]

> General ideas for IAMB internals
> 
> 1. The structure of the threading for the board ought to be something
> like this. Each forum has a root that is an article without a parent.
> The text of the forum's article is a description of the forum. Each
> thread of a forum is an article with that forum article as its parent.

I assume that this is roughly analogous to the fact that the "main"
forum has a root article of 0, and a lot of the threading code relies on
this fact. I wonder if changing the root article to something non-zero
is going to break a lot of stuff. While this is not in itself a reason
not to do it, it needs to be seriously considered before we make it so.
 
> 2. All IDs should be the IDs of the root articles. That is, the forum ID
> is the ID of the root article of the forum. The thread ID should be the
> ID of the root article of the thread. A subthread ID (if we need such a
> thing) would be the ID of the top article in the subthread. This allows
> the same routines to do things to subthreads, threads, and forums.

I think that we can already do this, in almost all cases, with the
subthreads. The notion of collapsing a forum is escaping me at the
moment.
 
> 3. The genealogy of an article is the list (array?) of children IDs,
> starting from from the forum root and ending with the given article.
> This will be used heavily in flat mode. Specifically, if we do this
> right, sorting the genealogies will produce the order in the expanded
> thread view, allowing us to recapture the threaded order fairly easily.
> It also allows us to provide helpful headers in the printed flat mode.

However, it is of course more than just a list. It's a tree. Even in
flat mode, you display more than just the direct bloodline from one
article to its great grand papyy. Cousins are included. I can see where
this is useful, but I think that in most cases it is a little limiting.
 
> 4. The distinction between the database containing the articles and the
> user's specific article status markers needs to be carefully maintained.
> In what follows, $dbh is the handle to the article database, while $udbh
> is the user's database file handle.

OK. Important distinction. One small comment, if I may. In moving code
to an OO mindset, on a variety of projects, I've become increasingly
aware of the importance and happy-making-ness of forgetting entirely
about the database. Idealy, I don't want to ever think about the
database. I don't have a database, I have objects. I talk about the
attributes of these objects, like the article's title, the thread's
title, the forum's description, and the user's favorite link color. But
I don't care (from the code perspective) whether that information is
stored in a database, DBM files, cuneaform, or the mind of sentient
gerbils. It took me a long time to make this mental switch, but I've
come to a place where I try, whenever possible, to keep all mention of a
database completely out of the user-code, and entirely in the
module-code.

I'm probably jumping the gun here, since you are after all talking about
the module API, not user code, but I think it's am important distinction
to make and get across to the other readers.

> 5. One thing I still don't know: Where is the stringified threaded data
> structure (what Dan came up with during coding day) going to be stored?
> It needs to be in memory a lot, for rapid updating, but also needs to be
> on disk. The iamb_int_verifyDB() call should reconstruct the string from
> the database and compare it to memory and the disk versions, and correct
> them, if necessary. As I see it, every forum will have its own
> stringified data structure.

I think that's right. However, there was and is still some disagreement
as to whether this piece of data belongs to a thread or to a forum.
Personally, I still think it belongs to a thread, and will be
unmanageable and/or unusable and/or icky if it is attached to the wrong
place.
 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Proposed API for IAMB internals
> 
> General observations:
> 1. The names of all the calls start with iamb_int, just for simplicity
> of identification and clarity at this stage of the game. That part of
> the name can be deleted before production occurs.

+1 on deleting that part of the name. +1 on leaving it there for the
purposes of this discussion. +2 on making method names as small and
concise as possible.
 
> 2. Return values are 1 (for success) and 0 (for failure). This is open
> to debate. Using 0 for success would allow for positive numbers to
> represent failure, which allows the return code to distinguish the
> reasons for failure. But it seems that such an approach was used for
> system calls, and it really makes the code confusing. A better way would
> seem to be to set a global error status variable.

I wonder if we can return an error object which has nice properties like
being able to give you a useful error message, but also to be able to
test it for truth. Or, perhaps, like DBI, you return 1 for success, 0
for failure, and if you get a 0, you can call another method to get that
error message information. Just rambling here. I know that this has been
discussed dozens of times on this and other software projects, so I'll
defer to greater wisdom if someone just wants to show me the back page
of such a discussion.
 
> 3. All input parameters are named. This is to avoid the jumble of
> remembering which order parameters should be in for each of the calls.

Amen and Halelujah.
 
> 4. I undoubtedly got way too ambitious with this, going all the way back
> to the creation of the database. But since I had no real way of telling
> how far back I should go, I decided to keep it in. Others (named Rich)
> can laugh them out of existence with no hard feelings on my part.

Ambitious is good. I've already written the one to throw away. We should
learn its lessons, and not feel tied to it in any way.
 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Site-wide calls (for admin use only)

Are you planning to enforce that in some programmatic way, or is this a
case of staying out of the living room because you're polite, rather
than because I have a shotgun?

> ====================================
> -Call: iamb_int_initializeDB(??);
> -Input parameters: ??
> -Return value(s): 1/0 (success/failure)
> -Description: This call should initialize everything; that makes its
> input parameters a bit difficult to specify until we know what they are.
> Certainly they would include $dbh= article database handle. The call
> should also set up an initial thread (forum ID = 0 or 1). Then again,
> the make procedure might do this instead.

Ooh. Bleah. Maybe you did get too ambitious. I don't know. Perhaps this
one needs to be considered by our installation guru. Matt? I question
the sense of having a method call that will get used once in the life of
an installation.
 
> -Call: iamb_int_verifyDB(??);
> -Input parameters: ??
> -Return value(s): 1/0 (success/failure)
> -Description: This call should check the status of the database files,
> verify their consistency, and output potential problems with proposed
> remedies. Again, until more has been determined, the exact parameters to
> pass will be subject to change.

Um. Not following. Do you mean database check, as in something like a
database compact/compress/repair, or are we just verifying that the
database schema is what it is supposed to be? The former is difficult
without knowing what database we're talking about, and even then can be
hard. The latter is also nontrivial. Perhaps I'm missing something here.
 
> User-oriented calls (for admin use only)

Same question as above

> ========================================
> -Call: $userID = iamb_int_addUser(??, USERDB => $udbh)
> -Input parameters: ?? (I assume the same as currently done)
>                    $udbh = user database handle
> -Return value(s): $userID (non-zero for success)
> -Description: Adds a user to the user database.

Users (might) need to be able to add a new user. This is called
registration. Some sites (see Kenya site for example) will need this
ability.
 
> -Call: iamb_int_deleteUser(USER => $userID, USERDB => $udbh)
> -Input parameters: $userID = database ID for the user
>                    $udbh = database handle for the user database
> -Return value(s): 1/0 (success/failure)
> -Description: This should remove a user from the database. My
> recommended method for doing this is to flag the user as gone, or set
> the password to something impossible. That way, articles from that user
> that still exist will continue to be properly credited. (Or do we want
> to remove all the articles, too?)

No, we do not. We want to obliterate the user's ability to log in by
marking them as deleted, but we do not want to remove their articles
automatically. We might want a cleanup mechanism to check
(periodically?) for deleted users with no remaining articles, and purge
them at that time.
 
> -Call: iamb_int_updateUser(USER => $userID, USERDB => $udbh, ??)
> -Input parameters: $userID = database ID for the user
>                    $udbh = database handle for the user database
>                    ?? = value(s) to change; depends on what's stored
> -Return value(s): 1/0 (success/failure)
> -Description: This would allow a simple interface to user management. A
> single call should be able to update anything (or everything) about a
> user. The iamb_int_deleteUser() might just call this with a new, random
> password. The call can be written so that it changes only what is passed
> in.

Or, as we are doing in various other places, you just keep track of any
attribute that has been modified, and update just those fields.

	$me = User->login(1234);
	$me->fname("Bob");
	$me->update;

This would load a user, reset his first name, and save that information.
No, this is not proposed actual syntax, just an example.
 
> Forum-wide calls (for admin use only)
> =====================================
> -Call: $forumID = iamb_int_newForum(DATABASE => $dbh);

Objection, your honor. I would like the database handle to magically
appear out of the air. I don't want to have to pass it in. Perhaps this
is unreasonable, but I want it anyway. I have some vague ideas about how
to make this possible. Some of them involve mod_perl, but I'd like to
avoide *requiring* mod_perl to run this. We can discuss this more in the
implementation stage, but I want to make it clear that that's what I
want.

> -Input parameters: $dbh = article database handle
> -Return value(s): $forumID = ID number of the newly created forum

Is this actuall an INT, or is it a forum object?

> -Description: This call should create a new forum. The trick is to find
> the $forumID. The database will automatically supply that if you ask for
> autoincrementing. (Deleting a forum is under iamb_int_deleteThread().)
> 
> Thread-wide calls (for admin or user)
> =====================================
> -Call: $threadID = iamb_int_newThread(DATABASE => $dbh, FORUM =>
> $forumID);
> -Input parameters: $dbh = article database handle
>                    $forumID = forum ID
> -Return value(s): $threadID = ID number of newly created entry

Same comment, and question, as above.

> -Description: This call creates a new thread. It is conceivable that
> this could get folded into the iamb_int_newArticle() routine, but that
> will have to wait until further along in the coding.

Yes, I think that a new thread should be autovivified when a new
non-response article is posted. I don't think that this in any way
removes the need for having it as a separate method, but just means that
that method should be called automatically by the new article method,
and the user should never have to directly call the function.
 
> -Call: iamb_int_flattenThread(DATABASE => $dbh, ID => $articleID, OUTPUT
> => $outputfh);
> -Input parameters: $dbh = article database handle
>                    $articleID = article/forum number to flatten
>                    $outputfh = handle of output file, already opened
> -Return value(s): 1/0 (success/failure)
> -Description: This procedure should convert the subthread tree to a flat
> format. In the case that $articleID<0, it should flatten the entire
> database. Part of storage should be the article ID. The main purpose is
> archiving. It is possible that this routine could be used in other
> places as well, and therefore must be re-thought. For example, are there
> other situations that trigger flattening a part of a thread? But using
> an article ID as the forum ID makes this single routine do multiple
> duty. There might be another parameter, such as REMOVE => 1/0, which
> would determine if the stringified forum data string and the database
> itself should be pruned. This would allow a subthread, thread, or forum
> to be eliminated, but archived efficiently. The REMOVE => 1 would
> require an admin, but REMOVE => 0 would be handy for users wanting to
> compress a whole thread.

Ah. So that's what you mean by flattening. Flattening means smashing the
thread structure into one of those bizarre meta-stringy-bob-doohickeys
for toting around the thread structure in a convenient format. OK. I
think I'm following you on this one.

I can't off the top of my head think of any place where I'd want the
entire database thus stringified. Keep in mind that forums are not even
particularly aware of one another, and combining multiple forums into
one flattened-thing may not be useful or even desirable. Remember also
that the admin of one forum is not necessarily the admin of any other
forum. Hmm. That could cause problems. (stream of consciousness email
writing)++
 
> -Call: iamb_int_expandThread(DATABASE => $dbh, INPUT => $inputfh, ID =>
> $articleID);
> -Input parameters: $dbh = article database handle
>                    $inputfh = handle for input file
>                    $forumID = new forum ID (default = old forum ID)
> -Return value(s): 1/0 (success/failure)
> -Description: The expands a flattened thread/forum into the designated
> database. The $articleID should be used for the restore, unless
> specified
> or unless the old number has been reused. The combination of flattening
> a thread and expanding a thread with a new ID allows subthreads,
> threads,
> or forums to be moved. The updating of the stringified forum data string
> will be the biggest challenge here.

Cool. Is the flattened string doohickey an object then? Do we have a
decent name for this structure yet? I vote we call it Zarathud.
 
> -Call: iamb_int_deleteThread(DATABASE => $dbh, ID => $articleID);
> -Input parameters: $dbh = article database handle
>                    $articleID = ID of root of subthread to delete
> -Return value(s): 1/0 (success/failure)
> -Description: This call should delete all the articles in a given thread
> or subthread. It should be heavily guarded against usage unawares. It is
> probably also one of the last functions that needs to be written; it
> won't be used much (hopefully). Deleting an entire forum is possible by
> specifying an forum ID.

This is assuming, of course, that a forumID is just in some respect a
thread ID? I think that's what you're saying. Just checking.
 
> -Call: @subthreads = iamb_int_getSubthreads(DATABASE => $dbh, ID =
> $articleID);
> -Input parameters: $dbh = article database handle
>                    $articleID = ID of top article to scan
> -Return value(s): @subthreads = array of all the article IDs in that
> subthread
> -Description: I don't have a particular use for this call in mind, but
> it strikes me as something that will be very useful. It can get all the
> articles in a forum by passing the forum ID, for example.
> 

This is like the get_kids method (or whatever ghastly name I gave it.
Might be decendants or something like that.) we have now. And, yes, it
does tend to be pretty useful in a variety of places.

> Article-level calls (for admin and user)
> ========================================
> -Call: $articleID = iamb_int_newArticle(DATABASE => $dbh, USERDB =>
> $udbh,
>                         FORUM => $forumID, PARENT = $articleID,
>                         USER => $userID, DATE => $date, TIME => $time,
>                         BODY => $body, ... (?) );
> -Input parameters: $dbh = article database handle
>                    $udbh = user database handle
>                    $forumID = forum for the article
>                    $articleID = ID of the parent article for the article
>                    $userID = reference to a hash of info on the poster
>                    $date = date of posting (or editing), in some format
>                    $time = time of posting (or editing), in some format
>                    $body = article itself
>                    ... (?) = other stuff; see Description
> -Return value(s): $articleID = ID number of new article; autoincrement
> variable in MySQL, I figure.
> -Description: This is the real heart of IAMB, the ability to post an
> article. Certain values are assumed, such as $status{SEEN} = "read".

But that's not an atribute of the article, really, but a relationship
between a particular user and the article, right?

> A lot has to go on in the background. The forum string (of the article
> IDs of all the articles in the forum) has to be updated -- a non-trivial
> task, given the potential for data collisions.

Yes. This frightens me.
 
> -Call: iamb_int_editArticle(DATABASE => $dbh, USER => $userID,
>                         ARTICLE => $articleID):
> -Input parameters: $dbh = article database handle
>                    $userID = reference to hash of info in the editor
>                    $articleID = ID number of article to edit
> -Return value(s): 1/0 (success/failure)
> -Description: This call checks that the person is allowed to edit the
> article (Is this the author? Should administrators have this access
> too?). If allowed, the article is edited, and updated in the
> database. Updating should update the date and time as well (shouldn't
> it?).

I think that it should. It does now, and that was the consensus at the
time. We also might consider, as I said above, offering a time-out on
editing articles. That is, if you're not the admin, you only have N
minutes during which you can edit your articles. The "oops that's not
what I meant" phase, if you will, but preventing the rewriting of
history and the "no, I did not really say that" problem.

> 
> -Call: @siblings = iamb_int_getSiblings(DATABASE => $dbh, ARTICLE =>
> $articleID);
> -Input parameters: $dbh = article database handle
>                    $articleID = ID of article for which to find siblings
> -Return value(s): @siblings = array of article IDs of siblings of an
> article
> -Description: This call searches the forum string of article IDs and
> returns an array of the article IDs that are the same level as
> $articleID in that subthread. I'm not sure why this is useful, but I
> expect that it could be.

It's useful I threading, I think. Although I guess you don't really
approach threading from a "what's in my generation" manner, but more in
a "who are my offspring" manner. So, perhaps it is not useful after all.
We'll have to decide as we get to actual code.
 
> -Call: @ancestors = iamb_int_getAncestors(DATABASE => $dbh, ARTICLE =>
> $articleID);
> -Input parameters: $dbh = article database handle (Is this necessary
> here?)

Since you already (I hope) have a thread (or article) object, you should
not need to pass any arguments explicitly - they are all contained in
the object. So I would say, not, it's not necessary here.

>                    $articleID = ID of article for which to find ancestors

That's in the object, right?

> -Return value(s): @ancestors = array of article IDs of ancestors back to
> the forum root.
> -Description: This call searches the forum string of article IDs and
> returns an array of the article IDs that lead straight back to the root
> article of the thread. The order is yet to be determined, but it seems
> that the easiest one is to put them from immediate ancestor to root
> ancestor. The question is whether or not that is the most useful. One
> item of information coming from this call is the number of ancestors,
> which determines the indentation level of an article. (Should this be
> getParent instead? Would that be more useful? It would certainly be
> faster if you don't need the entire genealogy. You could get all the
> ancestors by recursion on getParent if you need that. The stringified
> threaded data structure for the article IDs would also be very fast,
> certainly faster than all the DB calls if we wanted a genealogy.)

I'm trying to think of where we would use this. I know that at the
moment, we need the parent sometimes ("in response to") and we need the
entire genealogy sometimes (can't think of an example right now, so
maybe I'm hallucinating).
 
> -Call: iamb_int_ignoreThread(DATABASE => $dbh, USERDB => $udbh,
>                         ARTICLE => $articleID);
> -Input parameters: $dbh = article database handle
>                    $udbh = user database handle
>                    $articleID = ID of article to ignore (and subthreads)
> -Return value(s): 1/0 (success/failure)
> -Description: This call marks a thread as ignored. All articles in
> subthreads below this one will also be marked as ignored.

Conceptually, yes. Perhaps not actually in the database. I think that
what we finally hashed out was that a single article will be actually
marked, and its offspring will magically inherit the ignored-ness. Makes
for fewer database entries, and does not end up limiting us in any
meaningful way.
 
> -Call: %status = iamb_int_articleStatus(DATABASE => $dbh, USERDB =>
> $udbh,
>                         ARTICLE => $articeID);
> -Input parameters: $dbh = article database handle
>                    $udbh = user database handle
>                    $articleID = ID of article to query
> -Return value(s): %status is a hash of anything you might want to know
> about an article. I will probably forget some things here, but it should
> include the following items.
>         $status{USER} = $userID
>         $status{DATE} = $date (in whatever format we use) of posting/editing
>         $status{TIME} = $time (in whatever format we use) of posting/editing
>         $status{THREAD} = $threadID
>         $status{FORUM} = $forumID
>         $status{SEEN} = seen or unseen or ignored or bookmarked or ....
>         $status{BODY} = text of article
> -Description: This is a routine that needs to be fast; it will probably
> get
> called a lot. Fortunately, most of this is stored in the database. The
> only exception that I expect is $status{SEEN}, which needs to be checked
> for being ignored. See next call.

These, then, are the attributes of the article object, right? Except for
the seen one, which is not an attribute of the article, per se, but an
attribute of the relationship between a particular user and the article.
In the context of a particular user, it is an attribute of the article -
which is to say, the article is "unread" from that particular user's
perspective, but the article itself has no such attribute, of itself.
 
> -Call: iamb_int_articleIgnored(DATABASE => $dbh, USERDB => $udbh,
>                         ARTICLE => $articleID);
> -Input parameters: $dbh = article database handle
>                    $udbh = user database handle
>                    $articleID = ID of article to check
> -Return value(s): 1/0 (ignored/not ignored)
> -Description: This checks to see if an article is ignored. The process
> will most likely be to call iamb_int_getAncestors (or
> iamb_int_getParent recursively) and check if any of them are ignored. We
> might need to make this iamb_int_ancestorStatus() instead, if we decide
> to
> enlarge the various options of status codes.

Well, we have read/unread, ignored, bookmarked, and should probably
leave this open for an indefinite number of other optional "marks". I
can't think of any right off, but I think that Tim came up with some. We
might even (gasp) have the user able to define their own mark types.
"Interesting", "come back to when I have more time", "Make sure to tell
Betty Lou about this one", and "Ha ha funny", for example, with
read/unread, ignored, and perhaps room for 2 or 5 more standard marks
being left at the bottom of the stack. Not sure how this would be
implemented, but that would be pretty cool.

Random thought. Mark certain articles as "download this to my Palm
device." Just a thought.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Throwing the APIs to the lions

[Rich B. <rb...@rc...>]

I'm trying very hard to get my mind around the concept that a forum is
an article. I'm just not getting it. A forum is, if you will, a room in
which conversations happen. Each conversation comprises a thread. The
articles are statements made by a particular participant in the
conversation. (As an aside, it thus makes very little sense to be able
to edit your articles. Thought: put a time-out on articles - you can
edit it for 10 minutes, but not after? Anyways ...)

It would seem to me that what you're doing is trying to benefit from
various functionality attatched to articles, and get this for free in
forums. That is applaudable. However, saying that a thread @ISA article
is just not so. Perhaps they are both subclasses of some parent class
that I'm unable to visualize.

My view of forums (fora?), and the way that they are currently
implemented, is that a forum is a table (and hence an object) in its own
right. Articles (perhaps this should be threads instead) are attached to
a particular forum by virtue of having the forum ID attached to
themselves. It says "This statement was made in the Green Room."

A better implementation would be, IMHO, the following.

Articles (statements) occur within threads (conversations).
Thread (conversations) occur within forums (rooms).
Forums (rooms) are their own beast.

You state additionally that you would want to inflate, and prune a
forum. I don't know what this means either. A forum merely is a
container that we put threads in. Perhaps I'm being entirely too
concrete and analogy-bound in this, but I can't quite see it in the way
that you are describing it.

However, I do need to read through your API now and comment from that
perspective also.

It is important, however, for a forum to be able to exist without having
any articles in it. That is, the forum must exist first, and discussion
begin in it second. Perhaps "must" is the wrong word here, but rather I
should say that this is the way that I perceive things. In the long run,
if the code works, is readable, and does not suck much, I won't complain
too loudly.

Please explain how I'm misperceiving what you're saying, because I think
you lost me somewhere.

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

Re: [Iamb-dev] Throwing the APIs to the lions

[Ken R. <kr...@qx...>]

> > > 2. All IDs should be the IDs of the root articles. That is, the forum ID
> > > is the ID of the root article of the forum.
> >
> > What the heck does that mean? What is the root article of a forum?
> 
> i havent had a chance to fully grok this document yet either. but if this
> statement says what i think it does, i dont like it. in order for the
> forum code i've been working to actually function, the forum has to be a
> separate entity from the articles.

I guess I don't understand why a forum *has* to be a separate entity.
What are you doing with forums that couldn't be done with the root
article of that forum? (See my response to Rich about root articles.)

> articles belong to a forum and a forum
> has articles.

Of course. Articles belong to a thread and a thread has articles,
too. What is the conceptual difference? A forum is simply a
megathread.

> now, my code is expendable as always but i think the
> concept is valid.  because otherwise i cannot create a forum with creating
> an article first, which seems silly. of course, maybe i'm completely
> misunderstanding :)

The creation of a specific type of article (and I haven't nailed
down what goes into an article to make it a forum, beyond it
having no parent article) *is* the creation of a forum. Or am I
being my usual obscure self?

-- Ken

Re: [Iamb-dev] Throwing the APIs to the lions

[Ken R. <kr...@qx...>]

Rich Bowen wrote:
> > 2. All IDs should be the IDs of the root articles. That is, the forum ID
> > is the ID of the root article of the forum.
> 
> What the heck does that mean? What is the root article of a forum?

All forums have an ID, for obvious reasons. How is that ID chosen?
My initial thought was to make the ID something of an autoincrement,
The first forum would have ID of 0, the second an ID of 1, etc. It
occurred to me that there is no reason for that. There is no place
that I am aware of that the actual ID of the forum makes any
difference. All that really needs to happen is for the forums to
have unique IDs.

Then it occurred to me that this would happen automatically if the
forum was an article of some sort. The database machinery generates
a unique ID for each article. That's it! Make the root article (the
first article, from which all others branch) a regular article, and
threads then are added to the forum in a mechanism identical to the
addition of a subthread to a thread. The same code would work for
both, since it would be the same process. An entire forum would then
be the subthread of the root article.

Finally, it occurred to me that there really is nothing that we
want to do with a forum that we might not also want to do with a
thread or subthread: flatten, inflate, prune, add, move. The need
for writing separate routines for forums and threads is gone. The
same routines would then work for all.

Of course, a forum is not just a regular article. There would
need to be protections built in to keep people from editing or
adding new forums. But that seems to be more a matter of
bookkeeping.

If I still am not making sense, tell me.

-- Ken

[Iamb-dev] Re: forums

[Matt C. <su...@qx...>]

also:

> Yes, public vs private forums is in the task list already, under the
> guise of access control lists. The idea is that public forums
> don't get access control lists (unless it is ban lists) and private
> forums have to have one.

is there documentation on this that i've missed somewhere?

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

[Iamb-dev] forums

[Matt C. <su...@qx...>]

> There are a number of places where code assumes that theres only one
> forum. Notably, the admin interface. But it's also elsewhere. This
> needs to be corrected, as it can cause some damage in places. The update
> unread function is another place where it could cause problems.

am finally getting around to hacking code :) UpdateUnread is already
Forum-aware. the rest of IAMB.pm seems Forum-aware as well. i'm getting
ready to crack admin and fix the issues there. also, any strange forum
related functions that people want in the module?

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Throwing the APIs to the lions

[Matt C. <su...@qx...>]

On Sun, 31 Dec 2000, Rich Bowen wrote:

> > 2. All IDs should be the IDs of the root articles. That is, the forum ID
> > is the ID of the root article of the forum.
> 
> What the heck does that mean? What is the root article of a forum?

i havent had a chance to fully grok this document yet either. but if this
statement says what i think it does, i dont like it. in order for the
forum code i've been working to actually function, the forum has to be a
separate entity from the articles.  articles belong to a forum and a forum
has articles.  now, my code is expendable as always but i think the
concept is valid.  because otherwise i cannot create a forum with creating
an article first, which seems silly. of course, maybe i'm completely
misunderstanding :)

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Throwing the APIs to the lions

[Rich B. <rb...@rc...>]

Ken Rietz wrote:
> 
> And now, the moment you have all been waiting for: the first release
> of the proposed IAMB internals APIs.

More extensive comments to follow, but one thing that immediately caught
my eye ...

> 2. All IDs should be the IDs of the root articles. That is, the forum ID
> is the ID of the root article of the forum.

What the heck does that mean? What is the root article of a forum?

-- 
Rich Bowen --  Director of Web Application Development
http://www.cre8tivegroup.com/  --  ri...@cr...
Have trouble remembering things?   http://www.idforgetmyhead.com/

[Iamb-dev] Throwing the APIs to the lions

[Ken R. <kr...@qx...>]

And now, the moment you have all been waiting for: the first release
of the proposed IAMB internals APIs.

There are several new ideas in it, which need to be agreed upon. And
there are undoubtedly several things that I have forgotten. Just
respond, and I'll see where they fit.

-- Ken

_______________________________________________________________________


General ideas for IAMB internals

1. The structure of the threading for the board ought to be something
like this. Each forum has a root that is an article without a parent.
The text of the forum's article is a description of the forum. Each
thread of a forum is an article with that forum article as its parent.

2. All IDs should be the IDs of the root articles. That is, the forum ID
is the ID of the root article of the forum. The thread ID should be the
ID of the root article of the thread. A subthread ID (if we need such a
thing) would be the ID of the top article in the subthread. This allows
the same routines to do things to subthreads, threads, and forums.

3. The genealogy of an article is the list (array?) of children IDs,
starting from from the forum root and ending with the given article.
This will be used heavily in flat mode. Specifically, if we do this
right, sorting the genealogies will produce the order in the expanded
thread view, allowing us to recapture the threaded order fairly easily.
It also allows us to provide helpful headers in the printed flat mode.

4. The distinction between the database containing the articles and the
user's specific article status markers needs to be carefully maintained.
In what follows, $dbh is the handle to the article database, while $udbh
is the user's database file handle.

5. One thing I still don't know: Where is the stringified threaded data
structure (what Dan came up with during coding day) going to be stored?
It needs to be in memory a lot, for rapid updating, but also needs to be
on disk. The iamb_int_verifyDB() call should reconstruct the string from
the database and compare it to memory and the disk versions, and correct
them, if necessary. As I see it, every forum will have its own
stringified data structure.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Proposed API for IAMB internals

General observations:
1. The names of all the calls start with iamb_int, just for simplicity
of identification and clarity at this stage of the game. That part of
the name can be deleted before production occurs.

2. Return values are 1 (for success) and 0 (for failure). This is open
to debate. Using 0 for success would allow for positive numbers to
represent failure, which allows the return code to distinguish the
reasons for failure. But it seems that such an approach was used for
system calls, and it really makes the code confusing. A better way would
seem to be to set a global error status variable.

3. All input parameters are named. This is to avoid the jumble of
remembering which order parameters should be in for each of the calls.

4. I undoubtedly got way too ambitious with this, going all the way back
to the creation of the database. But since I had no real way of telling
how far back I should go, I decided to keep it in. Others (named Rich)
can laugh them out of existence with no hard feelings on my part.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Site-wide calls (for admin use only)
====================================
-Call: iamb_int_initializeDB(??);
-Input parameters: ?? 
-Return value(s): 1/0 (success/failure)
-Description: This call should initialize everything; that makes its
input parameters a bit difficult to specify until we know what they are.
Certainly they would include $dbh= article database handle. The call
should also set up an initial thread (forum ID = 0 or 1). Then again,
the make procedure might do this instead.

-Call: iamb_int_verifyDB(??);
-Input parameters: ??
-Return value(s): 1/0 (success/failure)
-Description: This call should check the status of the database files,
verify their consistency, and output potential problems with proposed
remedies. Again, until more has been determined, the exact parameters to
pass will be subject to change.


User-oriented calls (for admin use only)
========================================
-Call: $userID = iamb_int_addUser(??, USERDB => $udbh)
-Input parameters: ?? (I assume the same as currently done)
		   $udbh = user database handle
-Return value(s): $userID (non-zero for success)
-Description: Adds a user to the user database.

-Call: iamb_int_deleteUser(USER => $userID, USERDB => $udbh)
-Input parameters: $userID = database ID for the user
		   $udbh = database handle for the user database
-Return value(s): 1/0 (success/failure)
-Description: This should remove a user from the database. My
recommended method for doing this is to flag the user as gone, or set
the password to something impossible. That way, articles from that user
that still exist will continue to be properly credited. (Or do we want
to remove all the articles, too?)

-Call: iamb_int_updateUser(USER => $userID, USERDB => $udbh, ??)
-Input parameters: $userID = database ID for the user
		   $udbh = database handle for the user database
		   ?? = value(s) to change; depends on what's stored
-Return value(s): 1/0 (success/failure)
-Description: This would allow a simple interface to user management. A
single call should be able to update anything (or everything) about a
user. The iamb_int_deleteUser() might just call this with a new, random
password. The call can be written so that it changes only what is passed
in.


Forum-wide calls (for admin use only)
=====================================
-Call: $forumID = iamb_int_newForum(DATABASE => $dbh);
-Input parameters: $dbh = article database handle
-Return value(s): $forumID = ID number of the newly created forum
-Description: This call should create a new forum. The trick is to find
the $forumID. The database will automatically supply that if you ask for
autoincrementing. (Deleting a forum is under iamb_int_deleteThread().)


Thread-wide calls (for admin or user)
=====================================
-Call: $threadID = iamb_int_newThread(DATABASE => $dbh, FORUM =>
$forumID);
-Input parameters: $dbh = article database handle
		   $forumID = forum ID
-Return value(s): $threadID = ID number of newly created entry
-Description: This call creates a new thread. It is conceivable that
this could get folded into the iamb_int_newArticle() routine, but that
will have to wait until further along in the coding.

-Call: iamb_int_flattenThread(DATABASE => $dbh, ID => $articleID, OUTPUT
=> $outputfh);
-Input parameters: $dbh = article database handle
		   $articleID = article/forum number to flatten
		   $outputfh = handle of output file, already opened
-Return value(s): 1/0 (success/failure)
-Description: This procedure should convert the subthread tree to a flat
format. In the case that $articleID<0, it should flatten the entire
database. Part of storage should be the article ID. The main purpose is
archiving. It is possible that this routine could be used in other
places as well, and therefore must be re-thought. For example, are there
other situations that trigger flattening a part of a thread? But using
an article ID as the forum ID makes this single routine do multiple
duty. There might be another parameter, such as REMOVE => 1/0, which
would determine if the stringified forum data string and the database
itself should be pruned. This would allow a subthread, thread, or forum
to be eliminated, but archived efficiently. The REMOVE => 1 would
require an admin, but REMOVE => 0 would be handy for users wanting to
compress a whole thread.

-Call: iamb_int_expandThread(DATABASE => $dbh, INPUT => $inputfh, ID =>
$articleID);
-Input parameters: $dbh = article database handle
		   $inputfh = handle for input file
		   $forumID = new forum ID (default = old forum ID)
-Return value(s): 1/0 (success/failure)
-Description: The expands a flattened thread/forum into the designated
database. The $articleID should be used for the restore, unless
specified
or unless the old number has been reused. The combination of flattening
a thread and expanding a thread with a new ID allows subthreads,
threads,
or forums to be moved. The updating of the stringified forum data string
will be the biggest challenge here.

-Call: iamb_int_deleteThread(DATABASE => $dbh, ID => $articleID);
-Input parameters: $dbh = article database handle
		   $articleID = ID of root of subthread to delete
-Return value(s): 1/0 (success/failure)
-Description: This call should delete all the articles in a given thread
or subthread. It should be heavily guarded against usage unawares. It is
probably also one of the last functions that needs to be written; it
won't be used much (hopefully). Deleting an entire forum is possible by
specifying an forum ID.

-Call: @subthreads = iamb_int_getSubthreads(DATABASE => $dbh, ID =
$articleID);
-Input parameters: $dbh = article database handle
		   $articleID = ID of top article to scan
-Return value(s): @subthreads = array of all the article IDs in that
subthread
-Description: I don't have a particular use for this call in mind, but
it strikes me as something that will be very useful. It can get all the
articles in a forum by passing the forum ID, for example.


Article-level calls (for admin and user)
========================================
-Call: $articleID = iamb_int_newArticle(DATABASE => $dbh, USERDB =>
$udbh,
			FORUM => $forumID, PARENT = $articleID,
			USER => $userID, DATE => $date, TIME => $time,
			BODY => $body, ... (?) );
-Input parameters: $dbh = article database handle
		   $udbh = user database handle
		   $forumID = forum for the article
		   $articleID = ID of the parent article for the article
		   $userID = reference to a hash of info on the poster
		   $date = date of posting (or editing), in some format
		   $time = time of posting (or editing), in some format
		   $body = article itself
		   ... (?) = other stuff; see Description
-Return value(s): $articleID = ID number of new article; autoincrement
variable in MySQL, I figure.
-Description: This is the real heart of IAMB, the ability to post an
article. Certain values are assumed, such as $status{SEEN} = "read".
A lot has to go on in the background. The forum string (of the article
IDs of all the articles in the forum) has to be updated -- a non-trivial
task, given the potential for data collisions.

-Call: iamb_int_editArticle(DATABASE => $dbh, USER => $userID,
			ARTICLE => $articleID):
-Input parameters: $dbh = article database handle
		   $userID = reference to hash of info in the editor
		   $articleID = ID number of article to edit
-Return value(s): 1/0 (success/failure)
-Description: This call checks that the person is allowed to edit the
article (Is this the author? Should administrators have this access
too?). If allowed, the article is edited, and updated in the
database. Updating should update the date and time as well (shouldn't
it?).

-Call: @siblings = iamb_int_getSiblings(DATABASE => $dbh, ARTICLE =>
$articleID);
-Input parameters: $dbh = article database handle
		   $articleID = ID of article for which to find siblings
-Return value(s): @siblings = array of article IDs of siblings of an
article
-Description: This call searches the forum string of article IDs and
returns an array of the article IDs that are the same level as
$articleID in that subthread. I'm not sure why this is useful, but I
expect that it could be.

-Call: @ancestors = iamb_int_getAncestors(DATABASE => $dbh, ARTICLE =>
$articleID);
-Input parameters: $dbh = article database handle (Is this necessary
here?)
		   $articleID = ID of article for which to find ancestors
-Return value(s): @ancestors = array of article IDs of ancestors back to
the forum root.
-Description: This call searches the forum string of article IDs and
returns an array of the article IDs that lead straight back to the root
article of the thread. The order is yet to be determined, but it seems
that the easiest one is to put them from immediate ancestor to root
ancestor. The question is whether or not that is the most useful. One
item of information coming from this call is the number of ancestors,
which determines the indentation level of an article. (Should this be
getParent instead? Would that be more useful? It would certainly be
faster if you don't need the entire genealogy. You could get all the
ancestors by recursion on getParent if you need that. The stringified
threaded data structure for the article IDs would also be very fast,
certainly faster than all the DB calls if we wanted a genealogy.)

-Call: iamb_int_ignoreThread(DATABASE => $dbh, USERDB => $udbh,
			ARTICLE => $articleID);
-Input parameters: $dbh = article database handle
		   $udbh = user database handle
		   $articleID = ID of article to ignore (and subthreads)
-Return value(s): 1/0 (success/failure)
-Description: This call marks a thread as ignored. All articles in
subthreads below this one will also be marked as ignored.

-Call: %status = iamb_int_articleStatus(DATABASE => $dbh, USERDB =>
$udbh,
			ARTICLE => $articeID);
-Input parameters: $dbh = article database handle
		   $udbh = user database handle
		   $articleID = ID of article to query
-Return value(s): %status is a hash of anything you might want to know
about an article. I will probably forget some things here, but it should
include the following items.
	$status{USER} = $userID
	$status{DATE} = $date (in whatever format we use) of posting/editing
	$status{TIME} = $time (in whatever format we use) of posting/editing
	$status{THREAD} = $threadID
	$status{FORUM} = $forumID
	$status{SEEN} = seen or unseen or ignored or bookmarked or ....
	$status{BODY} = text of article
-Description: This is a routine that needs to be fast; it will probably
get
called a lot. Fortunately, most of this is stored in the database. The
only exception that I expect is $status{SEEN}, which needs to be checked
for being ignored. See next call.

-Call: iamb_int_articleIgnored(DATABASE => $dbh, USERDB => $udbh,
			ARTICLE => $articleID);
-Input parameters: $dbh = article database handle
		   $udbh = user database handle
		   $articleID = ID of article to check
-Return value(s): 1/0 (ignored/not ignored)
-Description: This checks to see if an article is ignored. The process
will most likely be to call iamb_int_getAncestors (or
iamb_int_getParent recursively) and check if any of them are ignored. We
might need to make this iamb_int_ancestorStatus() instead, if we decide
to
enlarge the various options of status codes.

[Iamb-dev] CVS diffs

[Rich B. <rb...@rc...>]

Since the SourceForge move, no CVS diffs have been sent ouy. I don't
know what I'm doing wrong, as I have followed the docs on the
SourceForge site. If anyone can look through those and suggest what we
might change, that would be nice.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/