iamb-dev Mailing List for IAMB -Iamb A Message Board (Page 6)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/iamb/iamb/Community
In directory slayer.i.sourceforge.net:/tmp/cvs-serv25986

Modified Files:
	IAMB.pm 
Log Message:
Fixed thread ordering


Most mailing list software have default settings such that responding to
an article does NOT go to the whole list, but only to the individual
that posted the article you're responding to. I've changed this setting,
so that responses will go to the list.

Ken Rietz wrote:
> 
...
> > 3) Limit by date. This is not quite done, but I almost have it working.
> > Pretty simple, once we had limit by number, since it's just another
> > 'where' clause. Of course, I'm not convinced that this is particularly
> > useful, so I did not have a lot of incentive to get it working.
> 
> There seem to be two reasonable definitions of "date":
> 
> 1. Date that the thread began (root entry)
> 2. Date of the latest entry in the thread
> 
> The second of them would, on first thought, be the more useful, but
> limiting to just the subthreads with entries after a certain date
> would have the potential of splitting a single thread into multiple
> subthreads. That would fracture continuity. Maybe the UI could be
> handled to reflect common roots, but I'm not sure how.
> 
> I'd suggest we need to think this one out a bit better before
> implementing.

Perhaps the only really useful thing then is "threads with new content".

> > 3) Documentation. Sucks. Lots. Need. Nuff said.
> 
> Right up my alley. Let me at it.
...
> I am assuming that the docs are in CVS as well, and changes to
> them also get reported to this list.

Perhaps I was a little TOO optimistic in referring to the documentation
as though it actually existed. I'll be more clear. There ain't none. If
you write some, you'll need to pick a spot to put it in CVS (like, say,
a docs subdirectory). At that point, yes, it will be in CVS, and changes
will be reported to the list.

There is some POD in the code, but that does not count as user docs.
There used to be an installation doc, but it got so far out of sync with
reality that it has gone away.

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


Update of /cvsroot/iamb/iamb
In directory slayer.i.sourceforge.net:/tmp/cvs-serv25294

Modified Files:
	Community.pm 
Log Message:
Fixed some typos and documentation inconsistencies. Nothing substantive.



OK, I have IAMB set up to automatically mail out diffs when code changes
are made. Of course, as with everything with SourceForge, this may take
a day or two to actually take effect, since there has to be actual human
intervention in one step of the process. Sheesh.

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


Update of /cvsroot/iamb/CVSROOT
In directory slayer.i.sourceforge.net:/tmp/cvs-serv19161

Added Files:
	syncmail 
Log Message:
Added syncmail so that we can get automatic diffs.



Update of /cvsroot/iamb/CVSROOT
In directory slayer.i.sourceforge.net:/tmp/cvs-serv17905

Modified Files:
	loginfo 
Log Message:
Adding additional detail to the commit message


I've got CVS automatically emailing the mailing list when a code change
is made. I'm still working on getting the actual diff mailed out. It's
having locking issues - the diff is trying to get a lock at the same
time that the checkin is trying to get a lock, and it's hanging
indeffinately. I'll get this working soon, but meanwhile, if you make
changes, I should know about it immediately, I just won't know what you
changed, but at least I can do a diff myself.

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


Although there are still some people that I would like to have signed up
on the project who are still no-shows, I think that almost everyone is
here. One of you is in daily-digest mode, which is less than ideal, but
I assume that it's more about time availability than level of interest.

Anyways, here's where the project stands right now.

We've got a pretty stable piece of code. It is hard to install, hard to
configure, and hard to administer, but it's pretty easy for the user.
You already knew all of this.

In the last two weeks, I've implemented the following long-requested
functionality:

1) Sort by thread updated: Whereas before, the most recently *started*
thread appeared at the top of the page, now the most recently *updated*
thread appears at the top. This means that your unread articles will
almost always be at the top of the page, even if they have been added to
a very old thread.

2) Limit by number: With a &limit=10 argument on the URL, you can limit
the number of article that appear in the main view. This still needs to
be added to the UI in some easy-to-use fashion.

3) Limit by date. This is not quite done, but I almost have it working.
Pretty simple, once we had limit by number, since it's just another
'where' clause. Of course, I'm not convinced that this is particularly
useful, so I did not have a lot of incentive to get it working.

The following tasks are what will likely be implemented soon (as in the
next 7 days).

1) Cookie authentication. HTTP auth, managing .htpasswd files, and being
tied to Apache, are all irritations that I don't feel like putting up
with any longer. Matt has some code that should give us cookie auth with
little or no work. And I have some code that will give us cookie auth,
but which is perhaps slightly less elegant. I went ahead and implemented
it from scratch, even though Matt already had something, because it was
an interesting problem. So we have two pieces of code to choose from.
Perhaps we can post both of them to the mailing list and see what people
think.

2) Forum support. This has been in the code for a long time, and just
needs some UI work to make it a reality. Support for multiple forums,
although it is simple to do, will make this software an actual serious
alternative to some of the other packages out there. With forums, I see
very little that would set, say, UltimateBB above IAMB.

The following tasks are ones that I think need to be thought
about/discussed/implemented RSN.

1) User management. Once Cookie auth is in place, user management will
be less of a hurdle. Creating a user now involves three steps. With
cookie auth, it would be just one - shove them in the database.
Consequently, although it was discussed that I submit the code running
on TM3 as a starting point for this, I think now that it would just
muddy the waters.

2) 1.0 release. Perhaps this is a little premature, but I think that it
would be useful to have a 1.0 release in mind. Perhaps if we can discuss
some concrete goals that we can work towards, so that we can recognize
the 1.0 release when we get there, that would be cool. I think that
we're probably at 0.75 or even more. After all, this code has been in
production for almost a year now on a fairly busy site.

3) Documentation. Sucks. Lots. Need. Nuff said.

Two more things:

1) Please encourage Wes, Dan, and whoever else, to at least get on the
mailing list, and perhaps join the development team. 

2) If you make modifications to the code, please mention it on the list.
If you've been added to the developers list, this means that you have
commit access to the CVS repository. If you make changes to the
repository - as in any code changes - people need to know about it.
Eventually, I'll modify the repository so that all changes get
automatically get mailed out to the mailing list. I'm still trying to
figure out how to do that. In fact, I might spend the afternoon doing
that, rather than working on those other features. But until I get that
working, PLEASE notify the list when you make changes.

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


Long long ago, there was a request to have threading sorted by thread
updated, rather than by thread started. That is, the thread that has
most recently had content added to it will appear at the top.

This request is resolved, with the following patch.

It's amazing how simple some things are once you set your mind to them.
I am sure this could use some code cleanup, but it works for now.


rbowen@rhiannon:/usr/local/apache/cgi-bin/iamb$ cvs diff index.cgi
rb...@cv...'s password:
Index: index.cgi
===================================================================
RCS file: /cvsroot/iamb/iamb/index.cgi,v
retrieving revision 1.17
diff -u -r1.17 index.cgi

--- index.cgi   2000/11/19 05:04:39     1.17
+++ index.cgi   2000/11/27 02:26:40
@@ -61,9 +61,17 @@
                                              $iamb->expandall;
        $collapseall = $form->{collapseall};

-     $sth = $iamb->dbh->prepare("select * from " . $iamb->articles . "
+     my $art = $iamb->articles;
+     my $thr = $iamb->threads;
+     $sth = $iamb->dbh->prepare("select $art.ID, $art.title, $art.body,
+                    $art.date_time, $art.author, $art.email,
$art.email,
+                    $art.url, $art.parent, $art.link, $art.image,
+                    $art.authorID, $art.forumID, $art.threadID,
+                    $thr.updated
+                    from $art, $thr
                        where forumID=$form->{forum}
-                       order by date_time desc
+                    and $art.threadID = $thr.ID
+                       order by updated desc
                        ");

        $sth->execute;

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


All issues from RT have been moved to SourceForge. All RT accounts will
now be changed to read-only, so that no new issues can be opened in RT.
Eventually, I'll make the system wide open, but read-only. That is, I'll
make it so that there's public access to read the issues that were in
there, but nobody can open any new issues. That way we can reference
discussion in the old system, and not have to copy everything over.

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


su...@qx... wrote:
> 
> i present to you what looks a lot like IAMB but is not by us.
> 
> http://www.marcbrinkmann.de/cgi-bin/cgiforum.pl?thesection=test

1) He's using CGI.pm and Time::Local for most of his heavy lifting
2) Although he's got some sort of template thingy going on, it is
hand-rolled, and so very limited. And there's still a lot of HTML in the
code.
3) Data is all stored in text files. Bleah
4) The file was corrupted, and so I did not see most of the templates,
so I'm not sure what they look like.

But, apart from that, it looked interesting. I have not attempted to get
it working yet.

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


I added some additional stuff to RFC 3, which is in the iamb-dev cvs
tree. It's not very exciting - just some stuff that I'd like to make
configurable options for people when they are logged in, vs. when they
are not logged in.

You can see just the diff if you click on the "browse cvs repository"
link in the cvs area.

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


su...@qx... wrote:
> 
> i present to you what looks a lot like IAMB but is not by us.
> 
> http://www.marcbrinkmann.de/cgi-bin/cgiforum.pl?thesection=test

Cool. Apart from being really ugly, this is pretty cool. I'll look at
the code tonight and see if there's anything interesting in it.

Any interest in approaching this guy about cooperation if the code seems
that it would benefit us to do so?

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


i present to you what looks a lot like IAMB but is not by us.

http://www.marcbrinkmann.de/cgi-bin/cgiforum.pl?thesection=test


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




su...@qx... wrote:
> 
> On Sat, 18 Nov 2000, Rich Bowen wrote:
> 
> > I came across a module called Config::FreeForm, which seems really cool,
> > but you're still stuck with the problem of having an external config
> > file. The problem, by the way, is that you have to change settings in
> > that file, but you also have to, somewhere, tell IAMB where that
> > configuration file lives. Hence, you're changing things two places.
> 
> external file is a problem? i beg to differ. i understand the quandry here
> though.  why not assume a default location for the config, like every
> other program in the world? or ask the user in the installation process
> and fill it in the main module via Text::Template?

Which would mean, of course, that this falls under the "installation
process sucks like a hoover" bug report.

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


On Sat, 18 Nov 2000, Rich Bowen wrote:

> I came across a module called Config::FreeForm, which seems really cool,
> but you're still stuck with the problem of having an external config
> file. The problem, by the way, is that you have to change settings in
> that file, but you also have to, somewhere, tell IAMB where that
> configuration file lives. Hence, you're changing things two places.

external file is a problem? i beg to differ. i understand the quandry here
though.  why not assume a default location for the config, like every
other program in the world? or ask the user in the installation process
and fill it in the main module via Text::Template?

PANTS

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




As you may have noticed, I've been moving the things from the Talk RT
queue to SourceForge. SourceForge makes a distinction between tasks and
bugs, so most of the things, being feature requests rather than bugs,
have been classified as tasks. I'm not quite sure how it works, in
regard to members taking responsibility for an unassigned task, so
please feel free to play around in there and let me know if there is
something that I need to turn on.

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


I'm tinkering with the idea of moving the configuration stuff somewhere
other than in an ini file. It seemed like a good idea at the time, but
from a documentation standpoint, you end up changing things too many
places.

I came across a module called Config::FreeForm, which seems really cool,
but you're still stuck with the problem of having an external config
file. The problem, by the way, is that you have to change settings in
that file, but you also have to, somewhere, tell IAMB where that
configuration file lives. Hence, you're changing things two places.

Any suggestions, comments, or strange esoteric remarks greatly
appreciated on this topic.

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


su...@qx... wrote:
> 

> RFC 3 (see iamb-dev cvs tree) proposes a cookie authentication layer.
....
> thoughts anyone? shall i post the code for approval?

That would be pretty cool. If we can move away from HTTP auth for
authentication, then we can have a better chance of running on
non-Apache servers.

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


first post.

but seriously...

RFC 3 (see iamb-dev cvs tree) proposes a cookie authentication layer. I
have such a layer cooked up from work. How it works currently:

use IAMB::Auth;

on import(), the Auth module checks your cookie against the database. bad
data or no data? it redirects you to a configurable login page.

dont want it to authenticate?

use IAMB::Auth ();

currently, it does not set $ENV{REMOTE_USER} but could easily be made to
do so.

thoughts anyone? shall i post the code for approval?

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





2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (12)	Dec (74)
2001	Jan (42)	Feb (11)	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov (2)	Dec
2002	Jan	Feb	Mar (1)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec

iamb-dev Mailing List for IAMB -Iamb A Message Board (Page 6)

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