iamb-dev-internal

[Iamb-dev-internal] iamb-dev and modperl

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

i had mentioned to you, rich, that i was going to look at rewriting the
current iamb functionality as a series of modperl handlers just for the
fun of it and because i'm bored.  is the cvs rearrangement of the dev tree
an indication that you like this idea? :)  

basically, i'm asking what the frell is going on in the dev tree and what
direction you are apparently gunning for in this rearrangement.


KEN, HEY KEN, is api-vaporware-0.01 coming out soon? :)

m.

Re: [Iamb-dev-internal] iamb-dev and modperl

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

Matt Cashner wrote:
> 
> i had mentioned to you, rich, that i was going to look at rewriting the
> current iamb functionality as a series of modperl handlers just for the
> fun of it and because i'm bored.  is the cvs rearrangement of the dev tree
> an indication that you like this idea? :)
> 
> basically, i'm asking what the frell is going on in the dev tree and what
> direction you are apparently gunning for in this rearrangement.

The rearrangement and general clean-up is for a variety of reasons.

First, in the spirit of write-one-to-throw-away, I'm doing a little bit
of throwing away. Most of this stuff was things that needed to go away
in order to facilitate the move to the StdModule-ish structure.

Other things, like the move of the unclassifieds into a subdirectory,
were more of getting clutter out of the way, in case we need it some
day.

But, yes, I've been giving some thought to the notion of doing things as
a set of mod_perl handler. And, perhaps a little more ambitiously, I'd
like to pursue whether we can do it as *both* a mod_perl handler *and*
CGI, and factor out the parts that are in both. Basically, the handlers
would be written in such a way that everything can be called as an
object method if we want to. And the CGI programs would be written in
such a way that that *only* things that they did were things that
mod_per does not do - stuff like CGI-ish form handling, and any cookie
stuff that was necessary, and any session management that we can't rely
on mod_perl to do for us, and for *anything* else, the make method calls
into the handlers/modules.

I think that this is potentially difficult, and I've never seen any
project do this, but those are incentives, rather than reasons to not do
it, dontcha think?

Anways, I was going to pause for a breather in my slash-and-burn to
suggest this and see what peoples' reactions would be. I suggested the
notion to Ken on Sunday night, and he, with of course no knowledge of
mod_perl and hence very gullible, thought it was a great idea.

And, all those folks that have been looking for an excuse to learn
mod_perl can listen a little closer and perhaps contribute something.

Reactions? Comments? Questions? Strange snide remarks?

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

Re: [Iamb-dev-internal] iamb-dev and modperl

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

On Tue, 30 Jan 2001, Rich Bowen wrote:

> First, in the spirit of write-one-to-throw-away, I'm doing a little bit
> of throwing away. Most of this stuff was things that needed to go away
> in order to facilitate the move to the StdModule-ish structure.

cool.

> I think that this is potentially difficult, and I've never seen any
> project do this, but those are incentives, rather than reasons to not do
> it, dontcha think?

um, actually this could be sort of easy.  what if in the cgi, we set up a
faked modperl environment and then called handler() with appropriate
params?

> Anways, I was going to pause for a breather in my slash-and-burn to

small request. in the future, can i at least be notified such things are
going to take place so i can at least pretend to be project
leader? thanks. :)

> Reactions? Comments? Questions? Strange snide remarks?

I HAVE LARGE PANTS.

m.

Re: [Iamb-dev-internal] iamb-dev and modperl

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

Matt Cashner wrote:
> 
> On Tue, 30 Jan 2001, Rich Bowen wrote:
> 
> > First, in the spirit of write-one-to-throw-away, I'm doing a little bit
> > of throwing away. Most of this stuff was things that needed to go away
> > in order to facilitate the move to the StdModule-ish structure.
> 
> cool.
> 
> > I think that this is potentially difficult, and I've never seen any
> > project do this, but those are incentives, rather than reasons to not do
> > it, dontcha think?
> 
> um, actually this could be sort of easy.  what if in the cgi, we set up a
> faked modperl environment and then called handler() with appropriate
> params?

Cool. I knew, when you said that it would be hard to do, that you would
come back in 2 days with a cool implementation suggestion! :-)
 
> > Anways, I was going to pause for a breather in my slash-and-burn to
> 
> small request. in the future, can i at least be notified such things are
> going to take place so i can at least pretend to be project
> leader? thanks. :)

Yes. Will do. The removal of the Community::* stuff was a continuation
of the creation of the StdModule stuff. The rest was the result of
momentum more than anything else. I'll discuss first, implement later,
next time. Any changes that need to be rolled back?
 
> > Reactions? Comments? Questions? Strange snide remarks?
> 
> I HAVE LARGE PANTS.

Well, I wasn't going to say anything, but now that you mention it ...

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

Re: [Iamb-dev-internal] iamb-dev and modperl

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

On Tue, 30 Jan 2001, Rich Bowen wrote:

> Yes. Will do. The removal of the Community::* stuff was a continuation
> of the creation of the StdModule stuff. The rest was the result of
> momentum more than anything else. I'll discuss first, implement later,
> next time. Any changes that need to be rolled back?

not at all. was just surprised is all.

m.

Re: [Iamb-dev-internal] iamb-dev and modperl

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

Matt Cashner wrote:
> 
> i had mentioned to you, rich, that i was going to look at rewriting the
> current iamb functionality as a series of modperl handlers just for the
> fun of it and because i'm bored.  is the cvs rearrangement of the dev tree
> an indication that you like this idea? :)

I talked with Rich about this during the Super Bowl (non-commercials
time), and like what he is thinking. I agree with him that it sounds
tricky to do, but exceptionally flexible and worth while trying. If
nothing else, we will learn a boatload about mod_perl and modules in
general :-).

> KEN, HEY KEN, is api-vaporware-0.01 coming out soon? :)

It is taking *much* longer to get this semester going than I dreamed,
but I can see the end. Once I get things in place, they just chug
along. It's a routine, or a rut, depending on the perspective, but
I like it.

That's the long answer. The short one is that, yes, expect it in
less than one week. Once I give a time period like that, I view it
as something of a commitment, and tend to keep it.

-- Ken

[Iamb-dev-internal] IAMB $stree API, version 2E-10

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

> KEN, HEY KEN, is api-vaporware-0.01 coming out soon? :)

It's now mistware; fire away. :-)

I hope that I have understood what Matt is asking for this time.
Last time was more than a bit off.

Well, I worked on typing it out, and am really quite embarrassed
at how small it really is. Once I got rid of all the calls that
shouldn't have been there in the first place, there wasn't much
left.

-- Ken

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

API for $stree methods for IAMB
+++++++++++++++++++++++++++++++

Definitions (since I found myself using terminology inconsistently)


Thread: An article that has no ancestor together with all its
descendants.

Root article: a top-level article in a forum. Also called the root of a
thread.
(The root is a single article; a thread is potentially many more.)

Subthread: Any article in the thread, together with its descendants.
(Note that the thread is also, by abuse of terminology, a subthread.)

Flat mode: (This is what I have gathered; I could be way off here.)
A printed listing or display of all bodies of the articles in a
subthread
that (somehow) allows you to understand how all the articles were
connected.

Genealogy: A list of article IDs that starts with the root article ID
and continues to the article ID, each ID being an immediate descendant
of the previous ID. An alternative is the reverse order.

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

General observations:

1. I am assuming here that I am only dealing with the $stree itself.
There are no calls affecting users, database stuff (not even the
consistency call that I leave for Matt's daemon to run), or objects
other than the $stree string itself. That is, the $stree calls
reflect only what other calls have done. You would create (plant)
a stree as a part of the process of starting a new thread. The
$stree call itself does none of that. (I was way out of bounds
in the previous API.)

2. I am assuming that the $stree will be an blessed string in the
appropriate thread class.

3. I have dropped all the iamb_dev prefixes as unnecessarily
pedantic. We all know that this is the development branch.

4. I have gone with the idea of using gardening metaphors for the names
of the calls: you plant a new stree; prune or graft a branch; a new
article is called a bud; etc. Am I just being silly? These can be
changed to more standard terminology very easily.

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



-Call: $stree = plant stree( ARTICLE = $ArticleID );
-Input parameters: $ArticleID = ID of root article
-Return value(s): $stree = the newly created stree
-Description: It is assumed that the article has already been added
to the database, and therefore has an ID. The initial $stree looks
like "[$ArticleID]". The call should also bless the $stree into the
appropriate thread class.


-Call: $branch = $stree -> prune( ARTICLE = $ArticleID );
-Input parameters: $articleID = ID of subthread article to delete
-Return value(s): $branch = the pruned part, suitable for grafting
elsewhere
-Description: This call should delete all the articles in a given thread
or subthread from the $stree. The removed string goes into $branch.


-Call: $stree -> graft( BRANCH = $branch, GRAFTPOINT = $ArticleID );
-Input parameters: $branch = branch to be added
		   $ArticleID = ID of article onto which the branch
			is grafted
-Description: This call inserts a subthread into thread. The intention
is that the prune + graft combination allows a rather flexible means of
low-level manipulation of the $stree, moving subthreads around.


-Call: $stree -> bud ( NEWARTICLE = $newArticleID, PARENT =
$parentArticleID );
-Input parameters: $newArticleID = ID of article to add to $stree
		   $parentArticleID = ID of article to which the new
			responded
-Description: This call manipulates $stree to add the new article ID
at the correct point.


-Call: @siblings = $stree -> siblings ( ARTICLE = $ArticleID );
-Input parameters: $ArticleID = ID of article to find siblings for
-Return value(s): @siblings = array of article IDs of siblings of an
article
-Description: This call searches the $stree and returns an array of
the article IDs that have the same immediate ancestor as $articleID.
I'm not sure why this is useful, but I expect that it could be.


-Call: @ancestors = $stree -> heritage( ARTICLE = $ArticleID );
-Input parameters: $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 $stree of article IDs and returns
the genealogy of the article. The order is yet to be determined, but it
seems that the easiest one is to put first the immediate ancestor and
last the root article. The question is whether or not the reverse order
is more useful.


-Call: $level = $stree -> branch_level( ARTICLE = $ArticleID );
-Input parameters: $ArticleID = ID of article to determine indentation
			level for
-Return value: $level = how many generations from the root article this
			article is
-Description: This would be useful to have for some flat mode stuff, and
could be done by simply counting ancestors, but a more efficient
algorithm
exists for just finding $level. Again, this call might never be used,
but
then again, it might.


-Call: ($before, $after) = $stree -> dissect( ARTICLE = $ArticleID );
-Input parameters: $ArticleID = ID of article to split $stree at
-Return values: $before = part of $stree string strictly prior to
			(not including) the $ArticleID
		$after = part of $stree string that follows $ArticleID
-Description: This call would split $stree at $ArticleID into two
substrings, $before and $after. It would be called by
$stree -> bud(), $stree -> prune(), and $stree -> graft(), so it is
worth writing once separately.

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

On Fri, 2 Feb 2001, Ken Rietz wrote:

> Root article: a top-level article in a forum. Also called the root of a
> thread.
> (The root is a single article; a thread is potentially many more.)

this is not accurate.  forums exist seperate from threads and
articels. we've had this discussion before.

m.

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

Matt Cashner wrote:
> 
> On Fri, 2 Feb 2001, Ken Rietz wrote:
> 
> > Root article: a top-level article in a forum. Also called the root of a
> > thread.
> > (The root is a single article; a thread is potentially many more.)
> 
> this is not accurate.  forums exist seperate from threads and
> articels. we've had this discussion before.

I'm not clear how he is contradicting that. Threads are in forums. A
root article, this says, is the first article in a thread. That is, it's
an article that has no ancestors. The "in a forum" bit up there could be
ommitted without changing the sense of the statement.

Right?

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

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

On Sat, 3 Feb 2001, Rich Bowen wrote:

> top-level article in a forum. Also called the root of a
                    ^^
                      i misparsed this as "is"

sorry.

m.

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

Rich Bowen wrote:
> 
> Matt Cashner wrote:
> >
> > On Fri, 2 Feb 2001, Ken Rietz wrote:
> >
> > > Root article: a top-level article in a forum. Also called the root of a
> > > thread.
> > > (The root is a single article; a thread is potentially many more.)
> >
> > this is not accurate.  forums exist seperate from threads and
> > articels. we've had this discussion before.
> 
> I'm not clear how he is contradicting that. Threads are in forums. A
> root article, this says, is the first article in a thread. That is, it's
> an article that has no ancestors. The "in a forum" bit up there could be
> ommitted without changing the sense of the statement.
> 
> Right?

I intended "top level article in a thread." And, yes, it could be
omitted.

I am not sure what a forum is, actually. If you could enlighten
me, Matt, I'd appreciate it.

-- Ken

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

> I am not sure what a forum is, actually. If you could enlighten
> me, Matt, I'd appreciate it.

A forum is an organizational thingy. It's just a collection of threads
that are in a particular subject area. It could be also thought of as a
sub-community.

Take a look at http://discussion.visorcentral.com/vcforum/index.php as
an example. One community (Handspring Visor users) but multiple forums
(software, hardware, accessories, troubleshooting, etc). Then each forum
contains threads. Which contain articles.

In the Kenya web site, I'll have Social, Government, AIDS, and perhaps
others. But they are all part of the Kenya community.

Forums will have (possibly) access control lists (who can view, who can
post, etc). They will possibly be invisible to some people. They will
possibly be read-only to some people. Ooh, they could be write-only to
some people - as in, you can post an article in the Support forum, but
you can't read other people's articles. Only the Support Staff could
read all the articles.

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

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

On Sat, 3 Feb 2001, Rich Bowen wrote:

/me nods in agreement with all the wise man hath spoken

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

Rich Bowen wrote:
> 
> > I am not sure what a forum is, actually. If you could enlighten
> > me, Matt, I'd appreciate it.
> 
> A forum is an organizational thingy. It's just a collection of threads
> that are in a particular subject area. It could be also thought of as a
> sub-community.
> 
> Take a look at http://discussion.visorcentral.com/vcforum/index.php as
> an example. One community (Handspring Visor users) but multiple forums
> (software, hardware, accessories, troubleshooting, etc). Then each forum
> contains threads. Which contain articles.
> 
> In the Kenya web site, I'll have Social, Government, AIDS, and perhaps
> others. But they are all part of the Kenya community.

I understand the concept, I think (which usually gets me in a lot
of trouble). Further questions: How are forums implemented? How do
threads become members of a forum? What is the meaning of it all?

My vague remembrances:
1) A person belongs to a forum by virtue of some forum variable
associated with that user. Only threads belonging to that forum
variable's value are displayed. Access control, in part,
controls what that variable can be.
2) Threads also belong to forums by virtue of some value stuck
somewhere in the database.
3) Forums "know" what threads belong to them because they only
pull out of the database articles with FORUM=value.
4) The threading of articles used to occur by some process
running through the database like a maniac, waving dead
chickens. Now, however, it will occur because of $stree,
provided Matt and I can convince Rich it is a good idea.

Am I close?

-- Ken

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

On Sat, 3 Feb 2001, Ken Rietz wrote:

important note here: forums dont work yet. so this is all sort of
vapourware and if this needs to chagne for the future than thats
fine. thats what this branch is for.

> My vague remembrances:
> 1) A person belongs to a forum by virtue of some forum variable
> associated with that user. Only threads belonging to that forum
> variable's value are displayed. Access control, in part,
> controls what that variable can be.

yes and a person can belong to more than one forum.

> 2) Threads also belong to forums by virtue of some value stuck
> somewhere in the database.

yup

> 3) Forums "know" what threads belong to them because they only
> pull out of the database articles with FORUM=value.

yup

> 4) The threading of articles used to occur by some process
> running through the database like a maniac, waving dead
> chickens. Now, however, it will occur because of $stree,
> provided Matt and I can convince Rich it is a good idea.

yeah, that's pretty much it. the ickiness was kept to a minimum by only
going one layer deep.  you only see this article and its immediate
children. 

also, on this list, we dont have to convince rich so much. he's not
project manager over here remember :) and i'm already sold. i was sold in
october.

/me pokes DrBacchus.

m.

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

looks good.  

once i start writing code based on this, we'll find the real flaws in the
api :)

m.

Re: [Iamb-dev-internal] IAMB $stree API, version 2E-10

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

Matt Cashner wrote:
> 
> looks good.
> 
> once i start writing code based on this, we'll find the real flaws in the
> api :)
> 

And the code for the APIs should be around shortly as well.

-- Ken