目标：一个全方位的网络虚拟社区

发信人: walklooktalk (千红一窟), 信区: BuildingBBS
标　题: 我们做点什么？
发信站: The unknown SPACE (Sun May 14 12:29:13 2000), 站内信件

目标：一个全方位的网络虚拟社区。

这个想法在现在看来，也许已经不是很新鲜，但从我们的BBS
的基础来看，这是最现实的一个方向。
放眼海外的华人网站，目前并没有一个十分强劲的网络社区存在。
这也许是一个暂时的空缺，我们有这么好的基础，为什么不去尝试一下。
现在网站的潮流之一，就是“私人化”，要能留住用户，最好的办法
除了“留下用户自己的东西”还会是什么呢？这也是BBS为什么会吸引人
的地方所在，因为在这上面留有你的文章、你的网友...

所以，网站提供的服务的宗旨是“留下用户自己的东西”，基于这个想法，
我觉得可以提供如下服务，欢迎大家补充：
1.讨论组/精华区/文摘区
这是我们最大的资本，可以将BBS的讨论组移植过来。
另外，可以将这个概念丰富化，我觉得可以提供以下几种类型的讨论组：
公共讨论组：普通用户具有读、写的权限，其它权限版主定制；
俱乐部讨论组：成员具有读、写的权限，其它权限版主定制；
个人讨论组：版主任意定制；
如果在讨论组加上Email定阅的功能，就可以涵盖 mailing list 的功能。
2.邮件
3.chat/talk/message
chat/talk可以用applet来实现，message可能需要写一个ICQ一样的东西。
4.投票
5.个人主页/文件夹/相册
6.个人管理
与个人有关的一些定制，如好友、坏友名录、个人信息、个人参数等等。
7.系统管理
8.地址簿/Bookmarks
9.Calendar

欢迎大家补充，先把大目标定下来，然后分头细化，我可以负责“讨论组”
这一块，基本就是把原来BBS的东西完善化，所以有些经验。

Thanks.
--

我是一匹脱缰的野狗，狂奔于你荒芜的心上。

千山我一独行

※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: 24.147.15.53]

发信人: andrews (旱鸭子~Torpedo in water!), 信区: BuildingBBS
标　题: Re: 我们做点什么？
发信站: The unknown SPACE (Sun May 14 12:55:30 2000), 站内信件

【 在 walklooktalk (千红一窟) 的大作中提到: 】
: 目标：一个全方位的网络虚拟社区。
这样的目标需要多大的硬件支持? 完全业余的工作
是否完成这个目标?

: 我觉得可以提供如下服务，欢迎大家补充：
: 1.讨论组/精华区/文摘区
: 这是我们最大的资本，可以将BBS的讨论组移植过来。
: 另外，可以将这个概念丰富化，我觉得可以提供以下几种类型的讨论组：
: 公共讨论组：普通用户具有读、写的权限，其它权限版主定制；
: 俱乐部讨论组：成员具有读、写的权限，其它权限版主定制；
: 个人讨论组：版主任意定制；
这个应该没有问题.
: 如果在讨论组加上Email定阅的功能，就可以涵盖 mailing list 的功能。
: 2.邮件
邮件的话, 不如只做邮件转发功能. 我想很多人不愿意把BBS上
的ID和现实中的身份联系起来, 做转发是比较有意义的. 反过来说,
是否有必要为大家提供邮箱? 我看意义不大.
: 3.chat/talk/message
: chat/talk可以用applet来实现，message可能需要写一个ICQ一样的东西。
telnet BBS系统的优势之一就是"集成". 聊天消息灌水都可以用
一个TELNET 界面完成. 如果做WWW界面这些东西还要分开, 很多用户
可能不好接受.此外WWW界面的消息等等缺乏实时性(每次都要刷新才
能看到新消息, 不甚方便)
: 4.投票
没有问题.
: 5.个人主页/文件夹/相册
这些东西会需要多大的系统负担?
: 6.个人管理
: 与个人有关的一些定制，如好友、坏友名录、个人信息、个人参数等等。
没有问题.
: 7.系统管理
: 8.地址簿/Bookmarks
: 9.Calendar
这些都没有问题.

: 欢迎大家补充，先把大目标定下来，然后分头细化，我可以负责“讨论组”
: 这一块，基本就是把原来BBS的东西完善化，所以有些经验。
: Thanks.
我对系统底层的东西更关心, 如何提高效率和稳定性?
比方FBBS使用UNIX文件系统作为底层, 不满1K的文件都当
1K来存. 可是一般版面上大多数文章实际内容都不到1K,
这样造成的浪费有多少?
再就是我以前提过的问题, 同样用户数量, 究竟是WWW
方式下系统资源耗得多还是TELNET下的多?


--
望远镜里烟雨迷蒙的远方, 两艘日本海上保安厅的巡逻艇正在驶近, 海豚直升机
低低悬停在其正前方, 正挡住去路.
"命令直升机最后一次警告, 钓鱼台是中国领土, 外国舰船不得驶入."
日本巡逻艇上火光一闪, 海豚直升机猛得一抖, 炸裂成一个鲜艳的火球.
"开火还击."
双100炮怒吼起来.

发信人: thrust (滚来滚去的西瓜虫), 信区: BuildingBBS
标　题: Re: 我们做点什么？
发信站: The unknown SPACE (Sun May 14 15:50:37 2000), 站内信件

【 在 andrews (旱鸭子~Torpedo in water!) 的大作中提到: 】
: 【 在 walklooktalk (千红一窟) 的大作中提到: 】
: 我对系统底层的东西更关心, 如何提高效率和稳定性?
: 比方FBBS使用UNIX文件系统作为底层, 不满1K的文件都当
: 1K来存. 可是一般版面上大多数文章实际内容都不到1K,
: 这样造成的浪费有多少?
应该说, 为了提高效率, 这种浪费是不可避免的.
: 再就是我以前提过的问题, 同样用户数量, 究竟是WWW
: 方式下系统资源耗得多还是TELNET下的多?
你这里的系统资源是指的什么?
如果对于网络资源, 当然是TELNET占得多. 用户每按一个键,
都要进行一次TCP的传送, 这当然是很浪费的. WWW在这上面具有优势.
对于系统资源(CPU/HD)来说, 我认为TELNET当然是有优势的, 因为每个用户自始
至终只需一个进程服务, 而且这个进程大部分时间处于空闲状态.
在WWW方式, 每看一条消息就需重判一次合法性,初始化状态上下文等等.
从内存上说, WWW也是有优势的, 用户数再多, 也只有那么些HTTPD在服务.


--
嘿嘿, 韦大人, 您猜对了, 又是我出卖您的!

发信人: walklooktalk (千红一窟), 信区: BuildingBBS
标　题: Re: 先做一下普及教育吧
发信站: The unknown SPACE (Mon May 15 11:30:22 2000), 站内信件

【 在 TAR (星--Flying......) 的大作中提到: 】
: 【 在 kyu (水海飘香-教父) 的大作中提到: 】
: : 2000年开工了,加入了,我美!!!!
: : 下面是我的一些看法:
: : 1,运行平台:Linux+Apache+Apache JServ+JDK+postgresql
: : 主要以Java servlet实现服务端的工作.(绝对好于CGI,简单于NSAPI)
: : 好处:可靠省钱,全free呀!,参与开发者也可方便的构造自己的开发环境
: : 坏处:抛弃原有的,可惜呀.
: : 2,设计上希望导入CORBA(Common Object Request Broker Architecture).
: : 这样可以增强系统的伸缩性,延缓系统的老化速度.
: : 3,希望站长对原有的系统做一个介绍,我一点也不清楚.
: 原来的telnet和www系统主要缺陷在哪里?

主要缺陷为：缺少可伸缩性，随着负载增大，很难通过有效的办法来负载均衡。
缺少可维护性，不好做进一步的开发。
缺少可靠性，需要修改的BUG很多，这些代码经过多人修改，可读性也很差。

: 是什么原因要完全另起炉灶,重新开发.
: : 4,希望站长罗列一下设计开发人员的必备知识,以便大家赶快学习.
: 这一点在目前应该是非常重要的,可能很多人还没有实际开发经验,
: 站长和有条件的网友能否共享一些开发所需要的技术资料?

还是那句话，请仔细阅读本版第1篇文章“项目规划书”。
第1步只是“需求分析”，我们没有特殊的技术背景要求，这也是目前成员
比较多的原因，随着项目的进展，大家的熟悉，再慢慢地进行分工。

--

我是一匹脱缰的野狗，狂奔于你荒芜的心上。

千山我一独行

发信人: ray (稀里呼噜), 信区: BuildingBBS
标　题: 建议--投票系统
发信站: The unknown SPACE (Sun May 28 18:04:17 2000), 站内信件


关于系统需求的部分，我个人是比较关心投票系统的部分

记得这个BBS最早的初中有建立/实习一个民主的意愿在里面。
那么一个完善的投票体系很重要。
原有的简单投票法颇有弊病。 比如多ID问题。后来站方好象是做了不少
改进的，3K是否可以介绍一下现在情况如何，是否要准备作些改进呢？
如果有改动的需要，我愿意试试这块。

ray

发信人: TAR (星--Flying......), 信区: BuildingBBS
标　题: 能否在原来的基础上进行大规模改进呢
发信站: The unknown SPACE (Sun May 28 20:56:38 2000), 站内信件

我觉着完全重新来可能工作量太大
而且以志愿开发，能否成功很难说
这里很多人对已有的BBS系统是比较了解的
能否对它进行全面的测试，找出影响性能的地方，
对关键部分彻底改写
修改系统的Bug,依次改进,提高可靠性
制定统一规范，将对原有的代码重新改写，保证可读性
......

--
--无聊中,虽然我应该努力工作

※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: 130.161.67.116]

发信人: walklooktalk (千红一窟), 信区: BuildingBBS
标　题: 需求分析大纲
发信站: The unknown SPACE (Sat Jun 3 16:59:46 2000), 站内信件

首先非常抱歉，最近一段时间比较消沉。

关于本站的新站建设，肯定是以WWW为主的，这是大势所趋，
我想不用多争。

新站的规模，可以做大，也可以做小。
做大的话就是只要是个性化的服务，都可以提供，其实也就
相当于一个portal了。
做小的话就是把BBS的交互功能，如讨论组、聊天等，做精做好，
也不失为一种特色。

我本来的想法是做大，希望能够听听大家的意见，但这么多天下来，
好象有建设性的意见并不多。

那我就拟一个大纲，加括号的是可做可不做的，其余的是必须做的。
我也把这篇文章发给大家在BBS的邮件帐号里，你对哪几部分感兴趣，
请回信告知，也可以多人做同一部分的需求。到时候，拟出名单来
好将这个项目进行下去。

大纲如下，我只是凭个人经验拟的，如果有不同看法，或有增、删意见，
欢迎提出来讨论：
------------------------------------------------------
1.讨论组
2.精华区
3.文摘区
4.投票
5.邮件
6.talk
7.chat
8.message
9.系统管理
10.个人管理
(11.个人主页)
(12.个人文件夹)
(13.个人相册)
(14.地址簿)
(15.Bookmark)
(16.Calendar)
--

我是一匹脱缰的野狗，狂奔于你荒芜的心上。

千山我一独行

※ 修改:．walklooktalk 于 Jun 3 17:02:13 修改本文．[FROM: 24.147.15.53]
※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: 24.147.15.53]

发信人: ColdIce (hot), 信区: BuildingBBS
标　题: 安全子系统需求分析(初稿)
发信站: The unknown SPACE (Mon Jun 5 21:16:44 2000), 站内信件

安全子系统需求分析(初稿)

1. 为使新系统做到既具高安全性同时又不失灵活性与可扩展性，我建议
把安全子系统(security sub-system)独立于各项具体服务(services)，
如公共版面，私人版面，聊天，邮件，消息，各项系统或个人设定等等。

2. 认证(authentication)与授权(authorization)应当各自独立。认证
应当是把一个具体(操作期间???)(session)与某一特定用户(user)相映
射的动态过程，而授权则是把一个具体的服务与某一特定用户或用户群
及相应权限映射起来的静态过程。在提供服务时，系统通过session把
动态的认证与静态的授权联系起来以决定是否提供相应服务。

3. 认证与可监控性

3.1 我们应当对所有访问用户进行认证，以保证足够的可监控性，对一个
session, 必须记录其访问地址，即使通过proxy访问，必须记录用户名，
同时允许匿名登录。我们的最后结果应当是session=user=realIP，而与
所要求服务无关。
3.2 提供服务无关的IP保护，对给定的IP范围予以屏蔽，但系统管理员
在需要的时候能方便地查询。
3.3 认证过程以注册时提供的密码为唯一标识。在忘记密码时应该提供
某种方式在无须管理员干预的情况下重新获得，比如发给用户的注册
email。
3.4 为保证用户的密码不被窃听，可以提供加密方式的登录认证方式。
这项要求取决于系统负担。
3.5 必须防止机器人登录及灌水。所以有必要对访问客户段软件作一个
认证。(个人觉得java或java script可以搞定，设想过没做过二万五千里)
3.6 允许用户在系统范围内自定义session发呆时间，系统管理员可定义
系统许可范围。

4. 授权机制

4.1 用户应该被确定一个安全等级，比如0--99。用户可以被归于一个或
若干个安全组(group)。
4.2 授权机制可以以用户之安全等级界定，如>10许可读，<50不许可读写。 style="font-weight: bold;">发信人: thomas (00), 信区: BuildingBBS
标　题: Re: 建议--投票系统
发信站: The unknown SPACE (Thu Jun 8 04:15:03 2000) WWW-POST


关键是人员的认证呀。但是看看如buy.com这类的大站点
都因为自己coupon系统的问题而被我们乱用的。这个站
怕是仍然做不好这一点吧。

可以想到的就是如www方式投票时，可以限定一个ip只能
够投一票的等等。即使这样，误差难免，而且和网虫想
玩花样的精力有关。

【 在 ray (稀里呼噜) 的大作中提到: 】
:
: 关于系统需求的部分，我个人是比较关心投票系统的部分
:
: 记得这个BBS最早的初中有建立/实习一个民主的意愿在里面。
: 那么一个完善的投票体系很重要。
: 原有的简单投票法颇有弊病。 比如多ID问题。后来站方好象是做了不少
: 改进的，3K是否可以介绍一下现在情况如何，是否要准备作些改进呢？
: 如果有改动的需要，我愿意试试这块。
:
: ray
:
:

--
\=/, _-===-_-====-_-===-_-==========-_-====-_
| @___oo ( )
/\ /\ / (___,,,}_--= 落难的时候应该一个人慢慢走出困境 )
) /^\) ^\/ _) =__ 成功的时候应该不忘帮助过自己的人！ )
) /^\/ _) (_ 年轻的时候最怕的就是因为过分执着 )
) _ / / _) ( 在意而伤害了别人。 )

※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: ]

发信人: ColdIce (hot), 信区: BuildingBBS
标　题: 系统管理功能需求(草稿)
发信站: The unknown SPACE (Thu Jun 22 11:06:50 2000), 站内信件

想了这么久，没什么好想法，先写点再说吧，大家群策群力啊。

1. 有关安全认证的部份见前面的贴子。

2. 统计
2.1 系统必须记录足够的信息以作为统计基础
2.2 统计结果定期发表，并清除或压缩老记录。
2.3 统计项目可包括(不限于，欢迎增加)
A. 各版被使用受欢迎程度(人时，文章数)，可以小时或天为单位
B. 系统用户登录数，系统负担大小，文章数，以小时或天为单位
C. 登录用户来源分布
D. 新增用户数，所有用户数，以天或月，年为单位
E. 用户点击模式？？(保密)

3. 备份
3.1 系统提供方便的手段设置备份参数，如时间，数量等等
3.2 备份以各服务为单位，这样在需要的时候可以只回卷该服务
而不影响其他，也应当提供全系统恢复以备 不测。
3.3 各具体服务提供的类似删文的备份与此无关，但具体服务
提供的备份手段应当做到谁误删谁就可以恢复以减轻管理
员负担


4. 状态监控
4.1 系统提供状态监控功能，旨在使管理员可方便查看当前系统
资源分配状况，实时查出消耗资源过多的进程或用户，有利
于定位BUG或做坏事的用户
4.2 应当给出按CPU或MEM占有率排序的进程列表
4.3 应当给出当前已登录用户占用资源列表。

5. 日志
5.1 日志记录应当简洁明了又不忽略重要信息
5.2 对管理类操作应当都作出记录，以防止滥用职权的情况
5.3 用户的重要操作如登录退出发表文章发信等等，以防止
滥用本系统的情况，同时在一些纠纷中可充当证据
5.4 日志的查询和搜索必须方便易行。

--
西北望，射天狼

※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: 137.132.61.102]

发信人: thomas (00), 信区: BuildingBBS
标　题: Photo Album, Address book, Calendar, and more(需求分析草案)
发信站: The unknown SPACE (Sun Jul 16 03:41:42 2000) WWW-POST


Photo Album
主要是参考了www.zing.com的制作，因为自己就是在用那个站点存贮
数字照片的。
1. 相册管理：一个用户应该有多本相册，因此有添加删除相册和相
片的操作；提供对相册内所有照片的游览；安全性角度，可以共享或
是私藏；相册属性还有背景、音乐、相册说明和在整个站点中的索引
设置。上载和下传图片则见下面两点。
2. 上载图片：除了通过网页选择文件之外，还应该提供小程序支持
任意多的图片同时选择上载。当然如果提供全部的FTP支持将会是更
好的。
3. 下传图片及其它：许多网上图片集站点只提供上载而没有下传。
那么用户就得自己保存所有上载的图片。从功能上讲是不够完善和方
便的。如果可以打包让用户下载自己制作好的图片集，或者我们帮助
用户制作成Kodak CD就更好了。还有制作照片服务。
4. 照片管理：提供一些基本的功能，这是可以参照如PhotoShop和gi
mp一类的程序的。有旋转、放大缩小、亮度调节、对比度调节和删除
(可以group删除)。调节好的相片如果能够允许用户再下载，显然功
能就比其它站点会更多些。最后是一个安全性问题，用户可以选择哪
些照片是可共用的，而哪些是自己有版权的---类似于BBS上发表的文
章啦。同样，站点也可以要求对相关的照片打上站点的标记，以保护
自己的权益，并进行宣传。
5. 索引：可以根据用户名、相册名、或是相片名来搜索所需要的图
片(集)。也可以根据分类来进行索引和搜索。
6. 其它：提供由站点上的照片制作贺卡，加上背景、音乐、相关文
字(有字体可选，特别是对中文来说)，以及一些方便实现的动画---
包括给图片加上雪、雨等等；把自己的照片生成网上slide show，并
且允许用户把这个引到自己的其它主页上---可以扩大宣传。
唯一没有把握的还是网路流量问题，以上全部功能需要多大的带宽来
支持？这需要有经验的来把关了。
Address book
地址簿需要的就是存放他人的contact information：包括人名、地
址(邮件地址、各种电话BP机和电子邮件地址、主页)、工作单位和其
它信息(如生日，共同渡过的人生大事等等)。
所有的地址信息还能够组成不同的组，如大学好友、中学好友、工作
同仁等等，以便方便处理：比如把自己拍的照片制作成贺卡然后发送
给所有的大学好友等等。
另外可能是比较有用的就是提醒功能：在某人生日前一周，能够自动
发送电子邮件给自己，提醒开始准备礼物；或者是婚礼多少年纪念日
一周前，让自己开始准备。
提供从现有的比较流通的地址文件格式中转入地址信息，这应该包括
MS Outlook、MS Outlook Express和Netscape的相关产品的支持。
总体上地址簿是和其它，如free email、送贺卡和后面的日历组织活
动相结合的附助品。
Calendar
记录自己的工作和生活中能够安排的部分。每个事件都有时间、地点
、参与人(可以是地址簿中的一个组)，及相关内容。
同样，我们需要提供电子邮件提醒功能，特别是能够提醒所有参与的
人。
更扩展的功能，可以有论坛或是chat room让参与的人在事前事中事
后直接交流；或者可以给每个事件加个memo文件什么的。
进一步的扩展就是加入project管理，把不同的事件能够串起来成为
项目的一部分。
其它
随便想到的几点：
ü 安全特性：发文章的用户可以选择隐去自己的ip地址
ü 真正的www论坛：www方式的文章按thread而不是如telnet那样以
发表顺序来组织，这样便于user选择参与什么样的讨论话题。没有必
要把www的BBS按telnet的思路做。
ü 精华区同样应该提供和版面一样的，按标题内容和作者名来查文
章；更重要的是能够从当前位置查所有的子目标下的文章。
ü www方式提供telnet方式。小托看到的是http://www.first.gmd.d
e/persons/leo/java/Telnet 的Java
Telnet。也是当年清华做成的telnet的出处，只是需要进行汉化。
ü BBS许可贴图是不错，但是是否能够把URL隐藏或者要显示的话，
控制长度。否则就会造成阅读的不便。
ü 提供中文转成中文图片服务---能够很快地扩大知名度，但是对服
务器要求比较高。

--
\=/, _-===-_-====-_-===-_-==========-_-====-_
| @___oo ( )
/\ /\ / (___,,,}_--= 落难的时候应该一个人慢慢走出困境 )
) /^\) ^\/ _) =__ 成功的时候应该不忘帮助过自己的人！ )
) /^\/ _) (_ 年轻的时候最怕的就是因为过分执着 )
) _ / / _) ( 在意而伤害了别人。 )

※ 来源:．The unknown SPACE bbs.mit.edu．[FROM: ac8d2455.ipt.ao]