Dec 12 19:27 2002 from Raj We can add others as we see fit. This is for the discussion of whether and how we want to go about upgrading the version of Citadel for Halibut. The latest round of user table corruption is what lead to it. Chances are that if we do upgrade, we'll probably lose the message base as well as potentially the user base. Is it worth it? Should we roll our own or should we go with citadel/ux 6.01a? Dec 12 19:29 2002 from Mark I'll tell you the answer from the admin (read: Josh) We almost definetly won't be using Citadel/UX of any version unless they really clean up their code. He'd rather stick with what we have, or roll our own. More details to come. Dec 12 19:31 2002 from beavisblah I was under the impression that the reason things haven't changed is that Josh has neither the time nor the masochistic tendency to update the bbs software. Dec 12 19:32 2002 from beavisblah And I'd venture to guess the has even less time now than he did when last speaking of it. Dec 12 19:32 2002 from the boy Is there anything other than Citadel that would be fine and work out of the box? Dec 12 19:34 2002 from Mark This is what I know about the system: It's currently client/server. There Dec 12 19:35 2002 from beavisblah I don't think that Josh will allow anthing to be used right out of the box. He's audited (read the code line for line) much of the software that runs on chiba, iirc. Dec 12 19:35 2002 from the boy :| yeek Dec 12 19:36 2002 from Raj Well, according to the docs, the 5.x was a major re-write, and the 6.x was supposed to be a huge cleanup. I haven't compiled a cit variant since I compiled 4.11 on my mac (ages ago (don't ask)). I can give it the once or twice over and see what I can discover. As for anything else, I've not found anything else that will do anywhere near what we need it, not without whole ass-loads of additional stuff. Dec 12 19:39 2002 from Mark Bah, bad cut'n'paste. Let's try that again. This is what I know about the system: It's currently client/server. There is a well(ish) defined protocol between the client and the server (your typical text based TCP protocol.) The server is what josh is interested in replacing as that is where most of the problems (both stability and security) exist. The current server uses proprietary (but documented) binary file formats for everything and uses file locking (ala flock() or similar) for multiple access control. Josh doesn't like this. He suggested a system that uses the file system for hierarchtical(sp?) storage of data. Eg: data/ data/users/ data/users/Mark data/users/Josh data/users/Raj ... data/rooms/ data/rooms/Lobby/ data/rooms/Lobby/.config data/rooms/Lobby/.info data/rooms/Lobby/[message number] ... data/rooms/Mail/ data/rooms/Mail/.config data/rooms/Mail/.info data/rooms/Mail/[message number] etc, etc, etc... If a server that uses this format could be written, it would be easy to fix any file corruptions. Hopefully, it would be even easier to find the bug that caused the file corruption and fix it. We could also write a converter that would take the current set of binary files and build a data/ directory from them, allowing us to pick-up where we left off. Dec 12 19:40 2002 from keith Yup. And frankly, we want it that way. Pretty much "out of the box = insecure", and there is a reason why Josh admins chiba... I can't see going to a newer version of Citadel being all that great of a thing. Rolling our own certainly would be "the way to go", but this is of course easy to say for someone who wouldn't be directly involved in the actual writing the code for such a thing (conceptual design I can help with, as well as testing... but that's about it). ...and agreed that either way, I'm sure Josh has less time than before to even think about this, for whatever that is worth. *shrug* Dec 12 19:42 2002 from Mark Oops, I left some important info out. Using a different file for everything like that allows some safety in file locking (ala Maildir from qmail). When creating a message, you work in a temp file first, build it up properly, then move it into place, which is atomic if I remember proplerly. Dec 12 19:44 2002 from Mark I can help work on code, but we really need someone to spearhead the project, and I'm not sure I'm that person. I can code, but I've never really done design. Dec 12 19:45 2002 from Will I still say run an NNTP server and just write a client that looks like the current citadel interface... Dec 12 19:45 2002 from nd or just use existing clients... =) Dec 12 19:46 2002 from Mark Right-o. You're incharge.. Dec 12 19:46 2002 from Dave Why don't we try out using a news-type interface? What could it hurt? Dec 12 19:46 2002 from Will Well, when I suggested that before everyone threw stones at me. So I'm trying to become more moderate (at least around y'all). Dec 12 19:47 2002 from Mark I've said it before, I'll say it again. Y'all can use whatever you want to communicate however you want. The Halibut BBS runs in Citadel. It's historic. That's just how it is. Dec 12 19:47 2002 from nd I've been totally pro going to an NNTP interface for years. But totally feel will's pain on the last time he brought it up. Dec 12 19:48 2002 from Dave Yeah, I remember. We were in the ph33r change (small 'c', mind you). But, since we have to switch to SOMETHING, we may as well try out some alternatives. Dec 12 19:48 2002 from Dave Doh...ph33r change MINDSET. And, of course, smitty wants to get all historic on us. ;-) Dec 12 19:49 2002 from nd > Dec 12 19:47 2002 from Mark >I've said it before, I'll say it again. Y'all can use whatever >you want to communicate however you want. The Halibut BBS runs in >Citadel. It's historic. That's just how it is. that being the case - why is this discussion even happening? Dec 12 19:49 2002 from Dave Good point. I sometimes forget who's said what. How would rolling our own continue to bhe Citadel? Dec 12 19:49 2002 from Dave er...be Citadel. Dec 12 19:49 2002 from Mark We're discussing re-writing the Citadel backend, not changing to another platform. Dec 12 19:51 2002 from devilpike I've never used nntp anything to do anything online, so my feeling would be... how do I get to Halibut? Teach me please? Dec 12 19:52 2002 from Raj There's something to what you say about the individual files for the users, but I'm not sure at all that this would be a good idea for the message base. Part of my concern there would be performance. IE, when we're in High Prattle Mode(TM), we could run into some rather serious contention issues with disk throughput. Not only performance, but also disk space usage, considering each message (more often than not <512 bytes per message) would be an incredible disk hog. As for project management, I could probably handle that if I could get a hand with the coding and design... Dec 12 19:53 2002 from beavisblah Honestly, y'all can discuss all you want. I don't see anything happening with the bbs software any time in the measurable future, except maybe Josh figuring out how to nuke my old info and the citademon. Dec 12 19:54 2002 from Mark Linux is efficient enough with its filesystem that I'm not at all worried about performance, even with this croud. Dec 12 19:54 2002 from Will dp: exactly why I said "write an nntp client that looks like citadel does now". Then we could interchange any standard nntp server backend we want, with the bonus that users who prefer other clients can use whatever nntp client they want. Writing a new backend just seems like reinventing the wheel to me. Dec 12 19:55 2002 from Will Of course, I'm not volunteering to do any work on this whatsoever. so I'm gonna shut up now :D Dec 12 20:01 2002 from devilpike hee hee! Dec 12 20:07 2002 from Raj I do NOT like the idea of any kind of nntp solution as there's NO WAY of guarenteeing anonymity with it. I personally don't post anonymously, but I know that there are those that do and I feel that having the anon functionality, especially with some of the topics discussed here, is going to have to be a fundimental and unnegotiable part of whatever design we may or may not come up with. In any event, I don't think we should put down one iota of code without at least bouncing it past Josh. I don't know nearly enough about security to be able to even pretend like I know what I'm doing... Dec 12 20:07 2002 from devilpike Agreed on the anon part... that's become important for a lot of folks, I think. Dec 12 20:17 2002 from Raj (on the upside, I finally found the full source for Citadel 4.11...) Dec 12 20:39 2002 from 'possum girl Wake me when it's over. :\ Dec 12 20:42 2002 from the boy hee hee Dec 12 20:44 2002 from Raj OK. /me fills a bucket full of icewater with a sprinkling of pollywogs, in anticipation of the day... Dec 12 20:47 2002 from Will re anon: uhh, well if everyone is using the character-based-new-client that we wrote, there would be no trace of posting IP (cause it'd be chiba, always), and the client could simply use 'anonymous' as the name. Regular NNTP client users wouldn't be able to post anon. You're mixing your view of existing NNTP networks (ie, usenet) into my vision of *just stealing some code* from NNTP server people to replace the citadel backend. Big difference. Dec 12 20:52 2002 from Raj Lemme think about that a sec. I still don't really like the idea of nntp... Dec 12 20:53 2002 from the boy ha! tell us how you really feel Dec 12 20:56 2002 from Will Mark's idea of using Maildirs is kinda cool. Are there any bare-bones NNTP servers out there that use MAildir for storage? Probably not. Are there any libraries to handle Maildir that would make writing a new client easier? In that case, you might not need a 'server' at all, so much as a cron job to expire messages, since the clients would be hitting the message base directly. I suspect that's what Mark had in mind... Dec 12 21:00 2002 from Raj I'd have to take a better look to see how maildirs handles things before I make any Grand and Sweeping Pronouncements(TM) either way. Dec 12 21:00 2002 from rookie Will has nntp on the brain Dec 12 21:10 2002 from The Other Dave And I have Squish on the brain, just because I once wrote a BBS software using it as the message base store. But ah well... Dec 12 21:49 2002 from Mark Will: You're talking like re-writing the backend would be re-inventing the wheel. I think re-writing the client would be harder and more re-inventive. The server is (or rather, should be) a dumb data-store to client interface with a well defined protocol. The client has to deal with users and look pretty and deal with different screen sizes and and and... No matter which way you go (Using the Citadel front end with an NNTP ^W^W our own backend, or using an NNTP backend with our own front end), you're re-writing one part, either the client or the server, and using existing, well established protocols in the middle (NNTP or CitaShit). Switching to NNTP, while being more "standards compliant" which is admitedly a good thing, would be changing more of the system. By re-writing the backend, we're swapping out a single piece of the puzzle, the piece with the most problems, and IMHO the easiest piece to re-write. If you want to embark on rewriting a BBS to use an NNTP backend, be my guest. You may even be able to convince me to switch to it for The Halibut BBS. But, for the project that Raj and I (and probably Josh) are talking about, it's going to be the Citadel front end (which everyone loves, right? ;) with a new back end. Dec 12 21:50 2002 from Change I think we should do everything in one big flat textfile that everybody has read/write access to. /me ducks and runs Dec 12 21:51 2002 from TheFinn everyone wants a new backend *) Dec 12 21:53 2002 from kraydon I don't. My backend is just fine. Dec 12 21:54 2002 from TheFinn Well there is that... Dec 12 22:10 2002 from The Other Josh Some of us may have opinions about Citadel's code quality but does it really impact our daily lives enough for any of us to care enough to create the time to rewrite/replace it? Really now...I've heard the horror stories about Citadel's code (and I agree with the conclusions of them) but does any of that really matter enough that we should be even having this discussion again? Sure, there are many ways Citadel could be improved. Sure, this discussion is a recurring theme about once a quarter. Sure, we're all smart enough to come up with a means to solve this problem. But, for the love of gawd, has any of us ever found the time or inclination to actually do something about it? No. Somehow I find it hard to believe that Citadel has gotten any worse than it always has been. Can't we all just along (with Citadel)? :-) Dec 12 22:11 2002 from Will The answer to that question is a resounding "maybe!" Dec 12 23:12 2002 from keith TOJ: I don't think there is a way to answer that in an absolute, as there are too many issues involved. The BBS means different things to different people at different times. As such the problems existing in the current incarnation of the BBS impact people based on those variations. Likewise the amount of time that people have on their hands varies, and means different amounts to them. *shrug* Two thoughts though... these are problems that we have been talking about for years. How long do you just go on living with problems that are a regular annoyance, and that you have every reason to go on being a regular annoyance, before you put some time into fixing them for the future? Secondly, if it's determined that there actually is in fact not enough time on people's calendars to do it, so be it... but is talking/thinking/planning it enough to at *least* get to the point where it can be judged properly as a time constraint? I don't know, I guess to me taking the attitude of "it's not any worse, so just leave it alone" seems too anti-innovation to me. I mean who knows what a project like this could yield as a "good thing"? Sure it would clear up some things that annoy many of us here... maybe some new ideas would come out of the process. Maybe we'd end up with some new functionality that we can't even think of now, but would become apparent during the process. Or maybe, just maybe, some of the people putting time into it would get some personal satisfaction out of a "job well done", and knowing that their work and time is appreciated by a large group of their friends who no longer have to deal with yet one more annoyance in their lives, thanks to that same time and effort. *shrug* Dec 12 23:22 2002 from Mark The problem that spurred this is the corruption in the user's file that's making Cindy login as beavisblah, which I get to hear about everynight, so I have a bit of an incentive.. :) Dec 12 23:25 2002 from devilpike haha! Dec 13 00:35 2002 from nd I'd also reply to TOJ's post that the consistent and ongoing end of discussion for every iteration of this item in the time that I've been on the bbs is - "Citadel IS the BBS." And then a general loss of interest in the thread based on which side of the would-like-to-see-additional-functionality / are- Josh-and-will-implement-any-changes spectrum. At least, that's my defeatist rationalization. Dec 13 00:38 2002 from Change Yeah, I'm not really sure why this conversation is even happening if Mark is unwilling to stray from the Citadel path...go ahead and look at the newest release, run through the code, see if it's worth it, if so then go ahead and implement it. If the binary file format is documented, then there shouldn't be much of an issue in converting from that to whatever new format the new code groks. Dec 13 00:50 2002 from nd that's sorta my thought on it. Dec 13 01:11 2002 from keith I guess I'm confused about what exactly is being argued about here. It may just be that I'm glazing over some of the technical details as some of them get out of my area, and others of them I just don't want to think about enough while at work to make sense of them. But it seems to me that I'm seeing... Mark wants to redesign the backend. The suggestion is made to use an NNTP backend, and write a frontend for it. Mark wants to stick with the existing front end. People realize Mark wants to stick with the front end. People get confused about why there is anything to discuss. Maybe I just don't understand what is actually confusing people here. *shrug* Dec 13 01:14 2002 from Change In that case, go forth and redesign the backend, great idea, you're in charge...if the frontend is staying the same then we shouldn't see any differences, right? Dec 13 01:14 2002 from Change (and I still think that the current data could be imported into the new system) Dec 13 01:48 2002 from catfish When did Halibut ever need a reason to make messages? I thought every just liked the sight of their own typing. ;-) Dec 13 06:04 2002 from Trisha I think I will zap this room, since it's unlikely I am going to understand much oft he conversation. Unless my input will beneeded at some level? Dec 13 06:39 2002 from Mark Clarification: Citadel is an environment, a UI, a style of BBS. It is not a particular implimentation or program. There have been litterally dozens of Citadel implimentations over the 20+ years it's existed on platforms starting on CP/M, going through DOS, Windoze, Unix, Amiga, Atari, Apple and I'm sure others. The term "Citadel" refers to the concept of a Room Based system with this particular interface that we use here. When I say I want to stick with Citadel, I'm not refering to this particular implimentation of Citadel (which is known as Citadel/UX). "Back in the days," I started on Cit86 and switched to Asgard at one point. Then, when I moved the BBS to Unix, I picked up Citadel/UX. Citadel/UX, as everyone has heard Josh and I state many times, is horribly written and impossible to audit. We've seen many bugs that affect stability. All these bugs that we've seen have been with the server side implimentation of Citadel/UX. The proposal on the table is to replace Citadel/UX with something else. The ideas presented so far are: - Find another Citadel that'll run in Unix (haven't found any.) - Upgrade to a newer version of Citadel/UX. They've gone through two major releases since what we're running, and one of them claims to be a major clean-up. I haven't looked into this yet, it may be what we end up doing. - Re-write the backend of the existing system. This is what Raj and I have been proposing. - Replace the system entirely, using something like an NNTP backend and re-writing a Citadel frontend. Assuming we can find enough people who are interested in doing the work, I"d like to see the third option happen. I think it'll be fun, it can be written with security as a major design feature, and we can (hopefully) trust it. Option one depends on another implimentation existing, nevermind it being better than Citadel/UX. Option 2 is a posibility; like I said, I haven't looked at it. Option 4 sounds like _MUCH_ more work than is really warranted. I have very little interest in rebuilding a front end/UI. Backends are much easier IMHO, nevermind the fact that NNTP doesn't provide all the functionality we use, eg: paging, chat, private mail, reassurance that a message posted by "Mark" was really posted by "Mark." (NNTP is too easy to spoof. Granted, the way the current Citadel is written, you could do the same thing, but that's something I hope to fix. (Thanks to Raj for finding this particular bug...)) Does this clarify what everyone is discussing? I'm pretty much only interested in Options 3, 2 and 1, in that order of preference. Dec 13 07:33 2002 from Dave Actually, I think that helps a lot. I had no idea; I thought these were all just ports of the same program. Dec 13 16:35 2002 from Raj Dave: Not even remotely. Mark: *sniff* I'm so PROUD of you. You've come such a LONG way since that gangly teenager with the spike haircut and distressing habit of spelling 'guys' as 'guies'. Seriously, though, I couldn't agree more with Mark's assessment. Trying to re-write this thing in NNTP would be opening a can of worms, security wise, that I'm not willing or probably even capable of facing. However, the current instance of Citadel isn't much better. Granted, it's quite difficult to post something as someone else (though I could without too much fuss, but I don't since I can get in sufficient trouble with my own account thenkyew), an NNTP backend, by its very design, would not only allow this but encourage it. We don't want this. I agree with Mark's assessment, as well as his order of options and their priorities (though we might want to give a little more than passing scrutiny to the newest version, for security if nothing else). Just my $.03CN. Dec 15 00:13 2002 from Raj OK, I was sittin' on the can, where I usually do my best thinking, and came across this bit of 'genius'. I'll post the idea and see what y'all might think. I was thinking about just what Citadel was and what the individual messages are, and what would be required on a multi-user system. Essentially, you have a user inputting data into a message base. Each message is a given length, and the headers contain bits and pieces of information. Now in a multi-user environment, you need to worry about such nicities as file locking and other stuff to keep people from trouncing on each other's entries. Now, we could try writing our own back end, going through all the pain involved, and probably giving up half way. or... We could take the idea presented in paragraph 3 and put it into place using existing technology. No, I'm not talking about the latest citadel. I'm talking about using a database. Postgress should be able to handle all of our backend needs, and this would leave our expertise available for coding what should be a fairly trivial front end process. I could probably hack together a decent prototype schema in a few days, and if we do it right, we might even be able to use the existing client as the front end. I don't recommend this approach, but it's something we can debate and chew over. Personally, I think it could be a serious alternative to hand-writing the whole damn thing from scratch. Discussion? Dec 15 00:15 2002 from Change Methinks Josh will develop some kind of interesting eye twitch when the words "database" and "chiba" are mentioned in the same sentence ;) Dec 15 00:21 2002 from Raj Perhaps. But then, perhaps not. There are plenty of databases in production service in secure environments... Dec 15 00:23 2002 from Mark Yup. I already thought about that. Yes, it makes the coding of Halidel, or NewCit, or whatever you want to call it, easier, but the system as a whole becomes _MUCH_ more complex and, from a security standpoint, this is a Bad Thing(tm). Not to mention, you're pretty much not going to get any sort of a database system installed on Chiba. What Change said. Otherwise, it's a fine idea. It would make the data-store much easier to deal with. It handles all the locking and atomicity for you. It's nice. Dec 15 00:26 2002 from Raj Ah well, it was an idea. Dec 15 02:04 2002 from Josh There's no reason to put it in a database. sticking each message in a fine will work just fine for our purposes... Dec 15 02:42 2002 from Raj I was looking at it from an ease of use and maintenance standpoint. It would be easier to control and essentially guarantee anonymity, if we did it right. Do we NEED to? Probably not, I suppose. Barring something as grandiose as Postgress, how do you feel about something like a BerkeleyDB API? Dec 15 02:54 2002 from Mark Why? What does that buy us? I'll tell you what it doesn't buy us, and that's files that are simple to edit and correct when things go wonky on us. Dec 15 03:59 2002 from Raj it buys us better file locking in a multi-user environment. Unless you really want to devise a multi-threaded server with (spit)flock(), that is... Dec 15 04:02 2002 from Raj ya know, upon re-reading, I think I was answering the wrong question. The reason for the DBMS (informix, oracle, postgres, etc) would be the better file locking. I'm only making an assumption that the same would be available to BerkeleyDB. Does that answer the question you were asking or did I actually mis-interpret the original question? Is it friday yet? Dec 15 04:06 2002 from Mark Nope, that was it. I think the idea with Citadel is that most of the files are write once, read many. So, the process who writes the file builds it as a temp file then moves it into place so everyone else can read it. As long as everyone only reads the file, it won't matter if multiple processes are reading it. (This, of course, assumes that rename() is atomic, which I think it is.) Dec 15 14:06 2002 from Josh and you need locking on a large scale, why? I think the general message post system would require 1 lock on a counter file, and that's about it... Dec 15 17:17 2002 from Mark Other things may require locks, like updates to user files, but even that might be gotten around. Dec 15 17:44 2002 from Josh (hence, 'general message post system'. Yes, other things require locking, but in practice, these things don't happen much...) Dec 15 18:17 2002 from Mark True. You're right, the bulk of the activity shouldn't require locking except for the counter which contains the "next message number". Dec 15 18:25 2002 from Mark Josh: Am I correct in remembering that delete and move are atomic? I guess it doesn't matter if delete is, you can just move it first then delete it. :) Dec 15 18:28 2002 from Josh no, they are not, though they are um... nearly atomic. :-) In fact, most programmers assume that they are. In may OSes, they are (*BSD). In linux, they are not. Dec 15 18:33 2002 from Mark Hrm... Are they Atomic-Enough for our purposes? Dec 15 18:45 2002 from Josh Not really. What did you have in mind? Dec 15 18:48 2002 from Mark Well, I thought the whole idea was that to avoid locking, you'd make the file as a temp, then move it into place, and that this was guaranteed to work because move was atomic. One moment, there's no message. The next, it's there and it's all built properly. This was the idea behind Maildir and how it's safe. Am I totally off base? Dec 15 18:59 2002 from Dave I would think that the problem is if two processes think that they should be building file number X at the same time. What if there was some process (thread-ish thing) that had to be queried by anything wanting to create a file and it pretty much handled the doling out of file name/numbers? When you make this request, you just wait until it gets back to you. Maybe you block until it's your turn, maybe you get serviced right away. But since the only process that can give you your number will only process one at a time, it never repeats name/numbers. Dec 15 19:01 2002 from Mark That's the "One file needing flock()ing" thing that Josh was talking about. The problem with using a process is that it's not percistant between restarts. Using a file with that number in it is persistant. Dec 16 11:42 2002 from Josh Mark: DJB, (and all other UNIX MTAs that I can think of) try to use 'rename' as atomic, which works in BSD but does not in linux. Dec 16 17:40 2002 from Mark Alright, that's what I was thinking of. Do you know if anyone has looked at how hard it would be to make it atomic? Dec 16 17:41 2002 from Mark Well, shit, if you really wanted to be nasty, just lock the whole filesystem while in rename().. Eww... Dec 16 19:40 2002 from Josh ummm... just stick a lock 'round it? Easy. Screws with your performance, though... Dec 20 23:26 2002 from Raj That's the problem. We run into either performance issues or, more likely with this group, problems with one message trouncing on another. I think we could probably rely on the current atomic-ness of the linux rename() call, if we wrap it up properly. If we give each message their very own personal identification number (either global over the entire message base or local to each individual room) and use that as a sort of serialization mechanism. I'm sure we could put the number in an unsigned long long int (that should cover even this chatty lot), and keep it in memory as well as on disk. Personally, I'm of a mind to keep the number local to each room, but that's not cast in stone by any stretch. Back to my database idea, though, I'm not trying to be difficult, I'm just curious as to see why it's so contentious to the security minded. I've been around databases for a long time and haven't found it to be a serious problem. Educate me. I'm more than a little curious as to why it gives Josh a twitch... Dec 21 02:54 2002 from Josh DBs are big, complex things, often run with silly-level privileges. Just to make things worst, people have this weird tendency to trust them, primarily (in my experience) because they don't understand them. Dec 21 03:10 2002 from keith The sad thing is, I have learned (the hard way) how true Josh's last post is. Specifically in regards to some of the developers that I work with... (yes, who develop a database front-end application). Dec 21 08:07 2002 from Mark Raj: I'll throw my vote in for globally unique message numbers. Makes moving a post from one room to another really easy. Dec 21 21:45 2002 from Dave good call, mark Dec 23 17:39 2002 from Josh and having one post in multiple rooms, which would be nice... Dec 23 17:39 2002 from Dave How would that happen? Dec 23 17:57 2002 from Mark OooOOOOooo! Cross Posting! Yes! Hadn't thought of that! :) Dec 23 17:57 2002 from Mark Dave: Hard Link the file from one Room to the other room. The message now exists in two places. Dec 23 18:01 2002 from Dave Sorry; that wasn't what I meant. :-) I wonder how the UI would handle cross posting of messages? Dec 23 18:01 2002 from Dave (ie. how would you enter the message so that it was cross posted?) Dec 23 18:03 2002 from Mark That's something that would need to be addressed. If we do stick with the current frontend, unmodified, we wouldn't be able to do it. If we either re-write or modify the front end, then we could do it however we want. Maybe a .nter rosspost or something like that. Dec 23 18:05 2002 from Dave Hmmm...okay. I could see that. Go to a room. .nter rosspost, then list all the other rooms, then enter the message. Dec 23 18:05 2002 from Dave Oh! Better idea! Make it one of the "post entry" options. Right along side of eplace and bort Dec 23 18:16 2002 from rookie That was my thought. Dec 23 18:19 2002 from Mark Could do that too.. My problem is that is so spinal, I'd almost rather have it at the begining where I'm still thinking about it. Of course, this doesn't mean that we can't have it in both places. :) Dec 23 18:26 2002 from Dave My problem with doing it first is: how do you crosspost something that was . nter scii? Dec 23 18:31 2002 from Mark Ooo.. Good call.. That's why we'd do it both places. :) Dec 23 21:36 2002 from Rusty Any chance of getting some type of raw IO? I've been playing with the idea of putting up a web front-end on my home computer, since I seem to be going to a lot of places that don't allow telnet, but do allow web access. Having it go through Telnet is utterly doable, but if it's being rewritten anyways... ;-] Dec 23 21:48 2002 from Mark The plan was to only re-write the back-end. Some people are talking about features that would require changes to the front-end as well. Strictly speaking, there's a TCP protocol between the two; you could write your own web based front end, if you wanted. I suspect that Josh would require it be run from Chiba since the TCP port is firewalled to the rest of the world. Dec 23 21:55 2002 from Dave In fact, he might not even allow you to run it there. :-) Dec 23 21:56 2002 from Josh Well, it isn't firewalled, though it should be. I'd prefer to limit the interface to programs running on chiba. Dec 30 15:19 2002 from Raj Sorry for the long delay, folks. Shortly after I posted that question about databases, our router went tango-uniform. Still down at the house, but I am back at work, so... So the biggest problem with databases isn't so much the fact of databases themnselves as with the six-toed thimbledicks that try to put them together. I can accept that. As for the crossposting potential, I like it in concept, but the implementation would have issues. Could we set up the facilities to disallow certain rooms to be crossposted to? Dec 30 17:23 2002 from Mark We _COULD_ do anything. It's a matter of what we want to do. FOr the first stab at this project, I don't think we should add any new functionality, just replace what's there. Currently, they use globally unique message IDs, so so shal we. Dec 30 19:03 2002 from Raj Here's something else to think about: how about a little of both? Global unique message IDs as well as room specific IDs? That would make crossposting easier, if that's the direction we like to head eventually. Dec 30 19:04 2002 from Mark What would room specific IDs buy us, other than the headache of trying to keep the two associated properly? Dec 30 19:15 2002 from Dave Something Rick mentioned a while go: being able to change what your "default" room is. Right now, of course, it's the Lobby. If you have no rooms to read, and you do a oto, you go to the lobby. I think Rick would rather his "default" were the Lunch Time> room. Dec 30 19:27 2002 from Raj Mark: I figured it would be easier from the cross-posting standpoint, Dec 30 19:34 2002 from Raj Mark: I figured it would be easier from the cross-posting standpoint, especially after you've done the nigh-on instinctive and realize that you wanted to also post it to another room. Thus, ferinstance, I can get a listing of msg numbers from the room [.r)ead h)eaders] then .e)nter c)rosspost. You give the room based msg number for the crosspost, enter the room, and Bob's Yer Uncle. One of the reasons I kinda favor the double number approach is that it would lower the likelyhood of trouncing any crossposts that might already exist on the message. Also, what happens if you want to delete a message from a given room (say, f'rinstance, I accidentally crossposted a rant into Ladies Room and it was supposed to go into, say, Nerdism (one hell of a typo, wot?)). Anyway, if you want to just delete it from the room, you .d)elete m)essage [localnumber] to delete from the local room, or if you want to remove all traces of that one post that was posted in heat or without adequete forethought to the feelings of others, you .d)elete m)essage [globalnumber]. See where I'm going with this? Dec 30 19:36 2002 from nd but it's bad normaized data that way... (I can envision an implementation where it's not stupidly bad normaized data, but it still doesn't seem good. This opinon formed without knowing the complete underlying message id structure and alyout.) Dec 30 20:10 2002 from Raj It's an idea. I'm not going to turn red in the face and start flinging large antlered mammals if we don't go with it. It's just something to think about... Dec 30 20:52 2002 from rookie Raj, but couldn't the same thing be accomplished with .d)elete m)essage [globalnumber] . If the roomname is specified, the cross-post is deleted only for that room, if it is not specified, then it is deleted for all rooms. Dec 31 05:52 2002 from Mark Or, better yet, just hard link the message from one room directory into another. When you're in room A> and delete the message, you only delete that one link. Then to really get rid of it, you'd have to go to B> and delete it there as well. This would be more accurate of a "cross post" anyway, IMHO. Dec 31 05:55 2002 from rookie Hee hee hee. NewClit. Dec 31 17:05 2002 from Raj I was wondering when someone was going to notice that... As for the .d)elete m)essage [globalnumber] , I suppose that's another way of doing it. Actually, it's probably a better way, if we're going to go with a directory heirarchy. But this means we're going to have to maintain a table of pointers for each room that will tell us which files are pointed where in the event we want to delete a crossposted message from all rooms. Also, how are we going to maintain a 'last read' listing? I'm not all that sure I trust timestamps. Perhaps a data file in each directory listing which person read which last message (and whether or not it's zapped, for that matter)? Or would we keep a global table for that in one central location? Dec 31 17:53 2002 from Mark I'm guessing that each user would have a list of RoomNum:LastRead pairs in their user account. Dec 31 17:56 2002 from Raj OK, that's an idea. So the plan so far is that we're keeping the user and room facilities essentially seperate? Also, since we've been known to do behind-the-scenes planning for this or that event (surprise birthday parties, etc), will these files be non-readable by their respective owners? Dec 31 18:14 2002 from Mark Are you thinking of Unix "ownsers" or BBS "ownsers?" Unix and the BBS had totally different name spaces for users; there is no corrilation between the two. All the files in Unix will be owned and readable by the Citadel user, not by any other user, as it is right now. Dec 31 18:31 2002 from Raj OK, that answers my question. In essence, we'll continue to follow the current model in that the Unix owner will be "bbs" (or whatever) and non-readable by those that don't need to know. Another feature just dribbled into my mind, though: make it possible for aides to zap rooms, and also be able to exclude aides from rooms as well. Also, let's consider a feature that allows an 'exclude' list, instead of having to invite everyone except those that we want to keep out. It'll keep the typing down to a minimum, and this way we won't have to specifically invite those that we happen to forget during room creation. Does that make sense? Dec 31 18:37 2002 from Mark Yes. Both of those are good ideas. Who's taking notes? Dec 31 18:39 2002 from Raj I'll tell ya what: we need a 'project manager' for this beastie. I'll volunteer for that function, as long as I can get others to agree to a) my management, and b) help out with the coding. Dec 31 18:39 2002 from Josh I disagree. It's reasonable for Aides to not be able to zap rooms. That being said, we aides probably shouldn't be wandering about as an aide user. Dec 31 18:47 2002 from Dave Basically, y'all should have done what Mark did and make a mortal user and an aide user. :-) Dec 31 18:58 2002 from Mark I just got tired of not being able to for ignore rooms, but I can go in and do Aidly things if necessary. Dec 31 19:38 2002 from Josh As long as we're getting all ohh-and-ahhy over this, how about a useful su-esque functionality... Dec 31 19:41 2002 from Mark To give an aide the posibility to give up ones aidely priveleges and re-gain them when needed? Very nice. Dec 31 19:42 2002 from Mark Oh, and to answer Raj's post, I accept you as a project manager, and I will help with design and coding and what not. So, does this mean you're taking notes of the brainstorming we're doing right now? Dec 31 19:45 2002 from Dave "Good idea. You're in charge." ;-) Jan 1 07:31 2003 from keith I'm sure this has already been thought of, but just to be sure... Mark, you mentioned the link from post in B> to be posted in A>... you'd need to delete the link in A> and then the message in B> to get rid of it totally, of course. We'd want to make sure that as long as the link in A> existed, that the message in B> cannot be deleted. Jan 1 09:04 2003 from Dave Nah, don't use symbolic links, use hard links. Then you don't have to worry about that. Jan 1 21:04 2003 from keith Yeah, I mentioned this to Mark the other night, and he pointed out that I had missed the fact that he's talking about hard links. Silly me - I deal so much with FAT and NTFS these days, that I sometimes forget about the existance of hard links. Jan 1 23:17 2003 from Josh I've been playing with an idea for message anonymity that would (given proper functionality of the server) provide for traceable messages within a given time period. After this time period, the information required to link the sender with the message would be destroyed, and the message would be truly anonymous. This would allow for Aidely retribution within a certain time period. After this time period, the identity of the sender would be lost. Jan 1 23:44 2003 from Josh Every time I read through Citadel's website, I get a rash. Now Citadel is 'Groupware', and includes pop3, imap, and smtp. It (of course) also integrates with PAM and LDAP. I think that I'm going to vomit. Jan 2 00:10 2003 from Will Most software I read about causes that reaction in me these days. Only it's usually in the form of a request at work, "please install piece of shitty commercial bloatware X on server Y. We paid $15,000 for said piece of shitty commercial bloatware, and we need it to do our jobs, so please get this done before you leave for the day." Jan 2 07:39 2003 from Mark Alright, I've started taking notes on our discussions. I think I've got just about everything we've agreed upon so far: http://www.halibut.com/~mark/halidel/ If there's something you think I've missed, let me know and I'll add it. I've also started working on a file layout scheme. None of what I've documented is set in stone. In fact, there are some things I'm not so sure about. I want to discuss them here. What are your opinions on having a Mail/ directory in every user's directory, then hard linking messages between Mail/ directories? This seems an elegant solution to the special case that is the Mail> room. Can anyone see something wrong with this idea (documented in that link I gave earlier), or have a better one? I'm not hard set on file locations right now. In fact, I think I have conflicting information between the text and the sample layout on files like .nextmessageid and .nextroomid.. Any suggestions on this? Jan 2 17:23 2003 from Raj Mark: thanks. How about liking that somewhere where I have permissions to add notes and the like. Also, to get all technical and shit for a second, I've still got grave, GRAVE concerns about how we're going to handle unique file numbers for each room. We tend to do a lot of follow-on posting (see messages with "Nice Collision" for an example). If we rely on these numbers, how can we be guaranteed of not trouncing on each others messages? This is not to say that I don't think we can do it. I just want to dangle that particular carrot in front of one and all and keep it firmly in view. Jan 2 17:33 2003 from Raj Oh, and on a side note: I've taken a look at Citadel 6.01a. In this endeavor that we call "application development", there are many traps and pitfalls. These dragons are known as "memory leaks", "unchecked bounds", "failure to check important function and system call return values", and "Just Plain Bad Design", amongst others. It is my most distressing duty to inform you that the dragons won. Jan 2 17:36 2003 from Josh We just make the number selection atomic. It's actually quite easy, assuming that everything happens on one machine. It would also be quite easy across multiple machines, assuming that you were willing to make one machine responsible. It's the case where several machines are trying to do it that we run into problems... Jan 2 17:47 2003 from Dave Indeed. If you have some function that is atomic, and everything just requests a number from that function, it should be fine. Jan 2 18:10 2003 from Raj Indeed. The Brightly Decorated Moose of Enlightenment came from on high and smote me with the understanding of how we can do this while including crossposting. One unique number, hard linked to individual rooms. Simple. I'm surprised that it didn't occur to me sooner (blame it on Christmas. I usually do). Make it atomic, locking the particular variable (with possible copies to disk as needed for backup and reboot purposes), and Bob's yer uncle. If implemented properly, it'd certainly quiet any qualms I'd have with the concept (I'm sure y'all will sleep better knowing that). Jan 2 19:14 2003 from Raj I've also looked over the list, and have a question about the 'decaying anonymity' for lack of better verbiage. What would be the purpose? What good would it be, and how would it benefit, for aides to be able to see who's posting what? Jan 2 19:31 2003 from Josh Ability to put the smack down on someone doing something disruptive (posting pages and pages of 'a's for instance). I'm interested in making it so that 'certain' people (think of them as people as a particular "Aide+" role) can wander over to the message database, and (with the help of a tool) figure out who wrote a particular anonymous message, as long as it was written recently. I don't want this to be easy to do, and I don't want it built into the citadel interface. It should require shell access and be a pain to do. I don't want non-disruptive messages to be traceable (ideally, at all). Unfortunately, I can't think of any way of having disruptive anonymous messages be traceable while keeping the non-disruptive messages untraceable. So, a compromise: make all messages traceable, but only for a small time period. Aides must catch these early. After a certain amount of time, the messages become untraceable automatically. Oh, the term should really be 'decaying traceability'. :-) Jan 2 19:47 2003 from Dave I think the issue is that, though it's not a problem now, it _is_ an open system and anyone who know about it can log in, create a user, and be an asshole if they so choose. Jan 2 19:52 2003 from Raj OK, fair enough. I see your point, but I'm not sure I agree with the concept. One of my biggest soapboxes has been and probably always will be guaranteed anonymity. I suppose that if it must be painful to be able to get to the information, I can stiffle my objections, but I'm still very leery about the whole thing. Here's an idea, though: how about, when the anonymity is broken, have some sort of message posted somewhere (perhaps M)ail'ed to the poster and/or other aides). Plus, for every 'violation', a reason must be entered. Howzat grab ya? Jan 2 19:58 2003 from Josh Actually, we have had a couple of problems in the past. Raj: Bear in mind that the described system is much better than today's. Re: informed breach of anonymity; I like the idea, but it wouldn't be compatable with my initial idea for the design. Having said that, I've been trying to resolve some other problems, anyway, so that's probably fine. I'd prefer a public forum posting over a private forum. Jan 2 20:08 2003 from Raj OK, we can do a public forum posting for such violations, or we could also make it aide-configurable and let the aide themselves determine whether the message should be publicly viewable or kept under wraps. Any way is fine by me. Jan 2 20:12 2003 from Raj On a different note altogether: I'd like to definitely see the room name length bug removed entirely. Perhaps, in the directory structure, we could use 'room numbers' and have a name in a table somewhere that ties a name to a number. Thus, say, if I wanted to create a room called 'Raj flings Mooses at Schtoofa for no good reason', I could. Do we want to limit name lengths, or do we just want to put a hard limit on room name lengths (using BOUNDS CHECKING, of course, to make sure that if I were to create that room, I wouldn't risk the Wrath of Josh for being a chowderhead and crashing the BBS). Comments? Jan 2 20:14 2003 from Dave IIRC, the current version does bounds checking, but they seem to have an endpoint problem. Jan 2 20:19 2003 from Raj It's obviously not enough bounds checking. My point, I suppose, is that no matter how it's currently done, it ain't done well enough. That's one that's driven me nuts, and I'd like to see it decided one way or t'other, eventually. Jan 2 20:19 2003 from Josh Well, the 'crashing the bbs' thing is a consequence of our current software being a POS. Obviously, the user shouldn't be able to spcify room names that are too long. What 'too long' is... well, that's an implementation detail... Jan 2 20:25 2003 from Raj Agreed. As soon as Mark gives me access to the notes for Halidel file, I'll add that to the things to do section (personally, I'm in favor of putting this in phase one, but I'm open to suggestion on this) Jan 3 01:55 2003 from Mark The only thing that worries me aboutthe room name thing is that I think it's a client problem, not necessarily a server problem. It should still get fixed, but I think it's a venture into the client code to do it. Jan 3 01:55 2003 from Mark More in a bit. I've gotta go get dinner.. Jan 3 02:15 2003 from Mark Nevermind. I don't think I have any more to say right now. :) Jan 3 04:46 2003 from Mark Next question: C or C++? More to the point, OO or not? Jan 3 05:43 2003 from Mark Welp, I've started writing some sample class definitions (assuming OO; I think better that way.) I'm also assuming C++. Josh: From a security standpoint, is this a Bad Thing(tm)? Is C++'s inherant greater complexity a bad enough thing that you'd not want to use it? Even if so, the good news is that what I'm doing would translate to structs and libraries pretty easily, we'd just have to enforce our own rules on what's read-only and what's read-write within a particular object. (So far, the only real OO thing I've done is to expand on a normal read-only object to make it read-write for creation.) Anyway, what I'm working on is at the usual URL: http://www.halibut.com/~mark/halidel/index.html Jan 3 06:04 2003 from Mark I'm done writing class definitions for the evening. The general structure is thus: class Message is a read-only object used for reading messages. class NewMessage::Message is a read-write object used for creating new messages (big shock, 'eh?) class AideMessage::Message is a read-write object used by aides for viewing and modifying messages after they've been written. There's a very similar structure for class User and class Room. There's a lot of detail missing from what I've got written right now, but I think the idea is there. I'm mainly looking for comments on it and suggestions for better ways of doing things. Jan 3 06:20 2003 from rookie Mark: If I remember correctly, Josh has...opinions about C++. It doesn't seem like what is to be written warrents C++ over C... Jan 3 06:37 2003 from Dave rookie: werd Jan 3 07:36 2003 from Josh I have no problems with OOD, but I don't like C++. I would be generally OK with C++ for this project, I suppose, if there were a compelling reason. Re: design notes: text editors aren't part of the backend, and for that matter, neither is the web UI. I don't think that messages in mail should disappear after they are responded to. Why are user directories stored based on the user id and not the name? why the leading '0's on IDs? Re: OOD If OO, why in gods name would we even possibly consider going with standard character arrays for strings? I don't agree that there should be separate classes for the same thing, based on the mode of access allowed to the operator at the time. This is something that should be enforced by logic elsewhere, and have nothing to do with the class at all. You need a way to create the things, and pretty much no one should be able to do anything after that. I don't understand why you have three classes for what seems like it should be one class. Perhaps I'm just being dense. (this applies to both the message and user classes) Ugh. I don't think that messages should include the ability to write to a room. That's what room objects should be for, which should take messages in some method. Why would we use time_t if we are using OOD? Doesn't this cry out for a class? Jan 3 16:49 2003 from Mark The compelling reason to use C++ on this project: It looks like I'll be doing most of the coding (I'm the only one to jump up and start, and I've got the time), and it's what I'm most familiar with. I could be talked into C if there were an even halfway decent technical reason for it, but from a coding standpoint, I prefer C++ because it's what I know and how I think (Thank you, Staley.) Re: design notes: Re: Text editors. You'll note that the webpage you're viewing has more info on it than just the backend redesign we're talking about. I go into different phases of the project and address (roughly) what will be done in each phase. I don't think I note specifically that text editors and web UIs are in phase two, but they are added features, and I do say that no new features will be added in Phase 1, the back-end redesign. User Directories stored based on uID, not Name: same reason the rooms are; so user names and room names can have arbitrary characters that shells get confused with. I'm not heart set on this; most shells will deal well(ish) with strange characters in file names, so when we have to go in by hand and edit/read files, we'll just deal with it, but I thought it would be easier to traverse the tree if the directory/file names were just numbers. Granted, this means that we have to keep name <-> number associations in our heads while going around, so I'm not going to push for this very hard at all. Leading 0's on IDs. I don't know. I was second guessing that even while I was typing it. I think the reason I did it was so that an 'ls' would sort them numerically, but it shouldn't matter. char * vs. class String. Because the "standard" string classes are a pain in the ass to deal with. But, I've got a string class (from Staley) that works pretty damn well that I'd be willing to use. For most smallish, non text intensive projects, I usually just continue to use char * and printf() and scanf(), not that damn cin and cout stuff. I could pretty easily be convinced to use class String here. I just think that the backend isn't doing anything very interesting in the way of text processing so char * wouldn't be too hard to deal with. Re: Three different classes for one object concept: This is where I need someone else's opinion on the whole OO thing. It makes sense to me. They're derived from the "real" class for that object, so technically, they all are the same thing, some just have added features, which is what the whole OO thing really is. It could be done in logic if we need to, but doing it with the OO model makes more sense to me. This is one I'm going to defend a bit harder than most. Re: Message->WriteMessage() vs Room->WriteMessage(). Yeah, that was one I was debating too. In reality, I don't think it much matters. In theory, I think the question is whether a Message writes itself to disk, or whether a Room writes a message to disk. I could go either way. It just means that a room needs to be able to get at the data from the Message (easily done ).. Ooo! Ooo! Ooo! messageFile << Message! We all know how much we LOVE the redirection operators! :) time_t is just an int, if memory serves. It seemed rather a lot of overkill to turn it into a class. I'm not quite sure what using a class here would gain us. Jan 3 17:53 2003 from Josh Re: "It doesn't matter much"; well you can get any number of functional designs that do the same thing, many of which are counter-intuitive and thus difficult to extend. The whole point of a "design" phase in a project of this size is to get something that is actually consistent and easily understood at the tail end of it. Any one of us could probably sit down and code something that basically works, probably in about an afternoon. The point is to get it to be _nice_ and _easy_ and _secure_. (which is one of the reasons I'm still not in love with the C++ aspects of this project) Anyway: to the point. I'm just saying that aspects of your design make no sense to me. If I'm strange and different (and it's intuitive to everyone else) then fine. If, on the other hand, others think that some of these things are a bit odd, then we should change the design. Further C++ stuff: If you're willing to give up most of the C++ 'syntactic sugar', then I'm grand with C++. If, on the other hand, you're all about extending 'new', overloading the '[' and '++' operators, and having copy constructors with a cherry on top, I'm not down with that. Jan 3 17:55 2003 from Josh To restate: The code should be _obvious_, both design and language aspects. If any portion of the code is non-obvious, we should change it, or accept it and comment heavily. Jan 3 18:05 2003 from Josh Re: Three sub-classes, and thus three objects: I still don't see the point. You have a few discrete ways to access the object, so you codify these access methods as sub-classes? That make no sense to me. This yields three different types of objects (which are admittedly related, but not the same object) to be one thing. That seems to break the whole OO idea, where a real (or abstract) thing is an object. They are all the same thing (a Message, a user, etc), you just access them differently. So why not just access them differently? Why actually extend the object to do this? OK, let's start here: What do you gain, and what is the cost. I see the cost, but I don't see the gain. The cost is that the design is more complex; there are several types of classes (and objects) that are basically the same thing. I don't think it's intuitive. Fine. What's the gain? Jan 3 20:13 2003 from Mark Re: Syntatic Sugar. The only operators I might overload would the comparison operators on any container classes, and the *spit* << and >> operators for IO on objects like User and Message, and only maybe on those. And, I totally agree that the code should be obvious. The point to three classes (two sub-classes) is enforced access at compile time. It makes the code easy to read and say "Oh, this is a Message as read by the system for display. Oh, this is a NewMessage, must be creating a new one. Wait a second, I'm getting an error while compiling. Oh look, I can't do an Aidely Thing(tm) to a Message, I need to have an AideMessage here to do that. AideMessages only appear in code where it's allowed." If you're trying to do something to the wrong kind of Message, you'll find out earlier than you would if it were a run-time thing. I'll say it again. I'm not heart set on any of this, this is just how my mind layed it out in a first run swag at it. All that access restriction stuff could be run at runtime, but IMHO, you're more likely to find access restriction bugs at compile time the way I'm suggesting. Jan 3 22:20 2003 from Josh I can't think of any reason to overload the "<<" and ">>" operators, as we'll probably want to make those explicit method invocations. I don't have a problem overloading the comparison operator, unless it is overloaded in a non-obvious way, or it has side effects. As for enforced access, this makes sense in some contexts, but I don't see the point in this instance. There _have_ to be programmatic (run-time) enforcement mechanisms in any case (how does the program govern when it can convert a NewMessage to a Message or a Message to an AideMessage?), so I don't see how judicious use of 'const' and written in access rules don't solve the problem in the same way, but more simply. Compile time protection is spiff, but I don't understand why we can't get this in another way. Perhaps I'm missing the (oh god, no) use cases you're envisioning. Sure, I want an admin to be able to delete stuff, but not edit it. I want a user to be able to make a new message, but the composition of the message is client side, not server side, so why not just make a new message with a constructor, and then make it generally immutable, other than through particular interfaces that are only allowed to Aide (as in, the program will only call these methods when an Aide directs it to...) Jan 3 23:18 2003 from Mark Ooo.. Alright, you've sold me on at least one thing: Creating a message totally in the constructor. Then, it can be done in class Message. This I do like. I haven't thought about it much yet, but I think the same thing will work for Room and User. Another thought. There are various "global" things that are useful to have access to inside methods, such as the username of the currently logged in user, the unix filesystem home directory of the BBS software, etc.etc. Is there an easy way to make this all accessable to the methods of (for example) class Message without having to pass in a class GlobalConfig object, or some such? Is this one of those times when it might be handy to actually _HAVE_ a (literally) global variable so we don't have to keep passing it everywhere? Gah. I've got a lot to say about this, but can't put it in a coherent format without sounding like I should be riding rollerblades down Venice Beach wearing a turban instead of trying to assist in building a software project. About global variables, we can probably get away with a minimum of those, since (if we're going with classes) we can put most of the info in a user class and/or room class, or the balance being retrieved from standard system calls. As for Syntactic Sugar, though: Sugar belongs in cereal, in badly prepared office coffee, and mixed with cinnimon and put on toast on cold winter mornings. You'll note that nowhere in there was any programming actually mentioned. Nuff said. Jan 6 18:48 2003 from devilpike Holy shit, Raj, you're that guy with the turban and the guitar? That's a hell of a secret identity! Jan 6 18:56 2003 from Mark His name is actually Raj R. Raj. Jan 6 19:16 2003 from Raj Yes, it's my secret identity. I ... I had to come out. Jan 8 17:27 2003 from Raj File formats: a necessary evil. Since we've decided to go with a flat file one-file-per-message type format with each room represented as a directory on the disk instead of the infinitely superior idea of a dat[random conceted blather deleted for brevity]ith yak's milk. But that's beside the point. We're here to discuss file formats. Seriously, here's what I see for what goes in the individual message file: username:messageflags:unixdate:message content goes here. For the anonymous rooms, we simply replace the username with the string 'anonymous' or '(Not Logged In)' or whatever. We handle this on the server side, I'd say, for ease of coding, and initial, early support for anonymous rooms. We can move it to the client at a later date, if you wish. As for the message number, I think that should be the filename. Comments? But now we talk of rooms. We tend to like to get creative with room names, being a creative lot that we are. We like to do funky things like putting spaces in room names, and perhaps maybe a splash of color if we're in the mood. Can't do that on a Unix filesystem, though. Thus, we have a room number that ties directly to a room name. room 1 -> lobby, room 2 -> Things that move, etc. But how to keep them tied together? Good question. We can do it one of two ways (that I've seen so far. This number is subject to negotiation, argumentation, or random incrementation or decrementation as I see fit. Where was I? Oh yes...): We put in some sort of .roomname file in the directory itself, or we build and maintain a global room name file ala /etc/group or the like. I'm in favor of the centralized file idea myself, if for no other reason than you have one place to go when looking for a corrupted message. I like centralized files. They're a lot easier to maintain, and will (if they're flat files) make fixing the problem that forced the creation of this room in the first place. But we're not talking about the user base file just now. We're talking about message file formats, and if I keep wandering on and prattling off in different directions like this, we'll NEVER get this blasted thing built. Anyway the room file can be something like this: 0:Lobby 1:Raj and tb's Fancy Food Fight Room 2:PR&S 3:Short Term Memory Loss etc. When the room gets pruned or disappears, we can do one of two things: delete the subdirectory and remove the text before the number, thus allowing the room to be reused, or keep the contents of the directory, add a flag to the file that indicates that the room is inactive, and forever keep the mapping above, or do some combination of same. Personally I'm in the 'reuse the number and nuke the contents' camp. Comments? Now as long as the user file has come up, I have some opinions about that, too (Raj? With Opinions? Really?). I think I'm going to take my model from /etc/passwd for the format, ie: username:password:usernumber:homedir I've only done these four since most of the rest is user specific and can be put into various files in homedir (last login in one file, last read in various other files, etc). That's about all I can think of for now. I'm sure other stuff will come to mind. Comments? Jan 8 17:29 2003 from Raj Incidentally, messageflags in the message above would be such things as whether it's anonymous, if it's crossposted (or perhaps where it's crossposted from/to), etc. And I was also thinking about flags for the room file, but the flags themselves (anonymity, include/exclude list, etc) can go in the room config files themselves. I'm gunna shut up now. Jan 8 17:57 2003 from Raj OK, page has been updated. I've dropped in a couple of my ideas. Make of them what you will. Jan 9 16:15 2003 from Raj Feature Idea: .oto requests that have multiple entries (.boo for books or That Other Room(TM) was what brought this to mind) will return a choice. Comments? Jan 9 17:32 2003 from Josh That isn't a server thing, that's a client thing. Jan 9 20:39 2003 from Raj I'm not so sure. The server would have to return both (or multiple?) choices, wouldn't they? Jan 10 06:46 2003 from Mark Lemme expand: That's _ALSO_ a client thing. This isn't a show stopper, just means it gets added to the list of requested features and gets thought about later. Jan 10 16:36 2003 from Raj Oh, right. That's how I intended it. It was a feature request, not a foot-stomping demand of what must be in the early early versions of the first alpha that we put into place. I guess I should have made myself clearer.