群品前台部分需求概述讨论版

[photon]

结合今天qq群里的讨论、madawei的er图以及我对用户行为的想象，对前台部分的用户场景做了简单的描述，功能点上，可能会有遗漏或想的还不清楚的地方，供大家讨论和补充。另有些地方没有写的特别细，是因为觉得需要前端、设计以及开发人员自己发挥自己想象的地方，太细有可能会限制思维。具体需要细化到什么程度，需要再和相关人员进行讨论。

群品前台部分用户场景：
用户登录
用户转入群品首页或者图书列表页
在首页或图书列表页，用户选择一本电子看
用户可以查询电子书，查询方式可以是关键字，书名，ISBN，作者，出版社，出版日期，关键字（tag）等中的字符串
用户可以翻阅电子书
用户对阅读的电子书的特定部分进行编辑
用户保存自己编辑的部分
前台对电子书进行版本控制
用户下载感兴趣的电子书
用户添加自己感兴趣的电子书
       系统识别电子书的格式并自动提取电子书的各种属性
       用户添加系统可能无法提取的图书属性
               书名
               书号
               封面
               版本
               ISBN号
               作者
               出版日期
               出版商
               图书类型
               tag                
       前台对用户输入进行校验(非法、重复等问题)
       管理员审核用户添加的电子书
       前台把新添加的电子书传给后台，需要确定传输方式
       前台拿到后台返回的html文件xhtml文件，保存到硬盘中
       前台得到云存储路径
用户删除自己添加过的电子书

参考：
github后台的用户使用场景
群品数据库设计初版
群品前台部分需求概述

[madawei]

1、用户需要登录才可以编辑、下载、上传电子书，但用户不需要登录即可在线阅读一本电子书，在线阅读的方式可参照好读、掌上书苑的方式。

2、用户搜索只支持电子书名的搜索，不支持其他方式搜索，简化程序复杂度，或者可以考虑好读的方式，用Google CSE来自定义搜索，但如果那样的话，一部分网友可能由于不能访问Google的服务而无法搜索，所以搜索我们尽量自己做。

3、我们将一本电子书以章节为分割，每章可单独编辑，就像mediawiki一样，可以每章编辑，编辑器可以选择开源的程序来实现，尽量简单易编辑，因为我们面对的是一些技术小白用户，最好能可视化编辑，可以套用epub模板，可以编辑样式，可以排版，这样可以产生排版精美的无错字精品电子书。

4、当一本书被上传后，即产生了这本书的第一个版本，每被编辑一次即产生一个新版本的EPUB的电子书，管理员可以在后台查看该本书的所有历史版本，并可以选择回退到特定的历史版本，后台管理系统也可以删除特定历史版本，后台系统中管理员可以审核用户新上传的电子书，每个新上传的电子书都要被审核，审核不通过的不能上架。如果发现用户多次上传不符合的电子书，管理员可以选择将该用户锁定，此用户暂时不能登录系统，除非通过邮件说明，从而解封。

5、后台程序复杂将用户上传的epub转化成html文件，以供前台在线阅读，用过编辑过的html被前台保持在服务器后台，通过调用后台接口，使后台转化htl为epub与mobi。然后后台程序将epub与mobi上传至第三方网盘，将网盘下载路径保持在数据库相关字段里，前台系统通过查询数据库，显示下载按钮，用户可以下载相关格式的文件。

6、用户在上传epub电子书时，需要添加meta数据，如isbn，出版社，作者等，前台将这些数据保存在数据库里，通过查询数据库从而可以显示该书的详细信息。

7、关于后台程序的定时任务，服务器中不保存电子书文件，只保存电子书最新的html文件，用来在线阅读电子书，所以的电子书文件都存储在第三方网盘中，每天晚上凌晨1:00-5:00，服务器将上一天（5:00-1:00）产生的所有电子书的历史版本及最新版都转移到第三方网盘，后台程序负责第三方网盘的管理。

在 2012年10月3日星期三UTC+8上午12时11分28秒，photon写道：

[Yang Fan]

1，每次编辑一个页面完成并保存后，web端需要通知后台服务某页面被修改，后台服务会将该页面保存到版本控制系统中（初步设定为svn，并且该svn是公开的独立服务器上，比如bitbucket，这样以后如果有必须从html合成epub/mobi/pdf电子书的任务可以放在其他VPS上进行，云存储同步任务也可以在其他机器上进行，减轻web服务器所在VPS的CPU压力和带宽压力）
2，电子书应该只保留一个最近最新版本，如果需要历史版本，可以从VCS中取出html历史版本再合成
3，要保证用户每次下载的都是最新版本的电子书，所以用户下载时，如果html文件比电子书要新，则立即合成一个最新版本以供下载

2012/10/3 madawei <madaw...@gmail.com>:

> --
> 感谢您为群品，为简体中文电子书作出的每一分贡献！
> ---
> 您收到此邮件是因为您订阅了 Google 网上论坛的“群品「群英荟萃，品书真味」”论坛。
> 要向此网上论坛发帖，请发送电子邮件至 qun...@googlegroups.com。
> 要取消订阅此网上论坛，请发送电子邮件至 qunpin+un...@googlegroups.com。
> 通过以下网址访问此论坛：http://groups.google.com/group/qunpin?hl=zh-CN。
>
>

--
Regards,
Fan Yang

[madawei]

1、这个想法很好，但这样会不会加大服务器的流量部分，因为需要不停的上传至网盘，历史版本多的话，流量也增大了，这是我们需要考虑的。如果所有的历史版本都放在云端，那我们并不知道这几个版本的具体差异，如果要对比这几个版本的差异的话，就需要全部下载下并转成html，然后才能知道差异，这样代价也不低，不过我们必须要求用户这块要严厉点，因为破坏行为越大，需要管理员的操作就越多，流量与服务器的资源被消耗的也越多。我们后台服务在做历史版本控制的时候也应该将相近的两个版本的差异变成一个文本文件保存，同时存入云端，这样后台管理员在操作的时候可以查看到这两个版本的差异，代价会小点。同时我们还得建一个表用来存放历史版本差异的URL，供后台管理人员使用。

2、为了节省服务器资源，我们可以不即时生成用户修改后的最新版，而是在这一天晚上进行生成，第二天用户就可以下载了，这样也可以减少用户的破坏行为。

3、你们后台的数据库有什么特殊需求都可以提出来，昨天设计的数据库问题肯定是有的，希望大家提出来。

在 2012年10月3日星期三UTC+8上午9时31分51秒，Fan Yang写道：

[Yang Fan]

要澄清些分歧：
1，只有分解后的xhtml文件会被版本控制，而且我建议版本控制使用现成的VCS工具，比如svn，这类工具会自己diff并只记录变化，不需求我们干预；
2，电子书不一定每个历史版本都会生成，一般说来，只有到了定时任务触发，或者用户请求最新版本时（用户请求的频率需要控制，不能他改了一个字一个标点然后请求，就给生成），才会生成电子书；
3，数据库中不用保存diff的URL，因为有现成的VCS工具可以随时得到任意两个版本的diff，随时生成并反馈给用户即可；
4，用户查看两个电子书版本差异时，实际上我们程序是查看该电子书分解为xhtml后的所有xhtml文件的差异，如果svn有个本地copy的话，直接在本地就可以对某个目录下的所有文件diff得到结果，不占用流量；
5，数据库中现在还不清楚到底需要哪些字段，现在能知道的只有需要一个保存下载URL的字段；
6，可以考虑做一个独立的客户端给有编辑需求的用户使用，这样可以绕开VPS直接在用户本地把xhtml传到svn服务器并合成电子书传到云存储中。

2012/10/3 madawei <madaw...@gmail.com>:

[Lin Nan]

关于后台接口的问题，不知道书记有什么意见不？

--Life Without Danger Is A Waste of Oxygen

[madawei]

逐条回应（@Photon 有什么问题，你现在最好理解清楚，因为我们几个人可能都有不同的理解，现在最好统一这种理解，然后写需求文档）：

1、历史版本我开始理解的是用户每编辑一次产生一个新的Html文件。现在采用你意见，即只对中间文件xhtml进行版本控制，同时使用VCS工具（具体采用什么工具，你到时写出来，具体的部署以后讨论），这样就不需要我们进行版本控制了，同时也不使用数据库里的历史表（历史表里主要存放一个电子书的所有历史版本，版本的创建时间，创建者，文件存放路径等信息，但这样有个问题，我们到底应该不应该保存这些历史版本的信息，如创建用户，时间等信息，VCS工具有没有这个功能？存放这些信息的好处在于后续的外围扩展，你可以知道那些用户的编辑有价值，方便我们把系统做成一个类SNS的系统，加强用户间的交流。）。

2、这个理由我赞同，即：不需要用户每次编辑我们都给他生成，如果这样的话，有人破坏影响会不可控。所有我们要做一个定时任务，可以选择每周，或者每月，或者几天产生一次，并且选择在午夜处理这些任务。同时当用户请求最新版时（这个可以在界面上做一个投票按钮，一个用户只能每天投票一次，当票数超过一定程度时【如5次】，我们就调用后台系统产生最新版的所有格式的电子书【EPUB与MOBI】，并且在页面的下载按钮下显示电子书的版本为最新版并加一个生成时间戳，这样就可以控制用户的行为了。）

3、这个我之前在数据库中加了一个diff表（存放电子书编号，两个相近历史版本的电子书编号，差异文件的存放地址，主要是用来给后台管理人员管理电子书用的，这样管理员就可以清楚的知道每个电子书的变化历史），如果采用VCS工具，我后台管理员怎么才能调用出两个历史版本的差异？就是说你不在数据库存放这些信息，我前台系统怎么调用出VCS的这些信息并且反馈给管理员（普通用户需要不需要知道这些差异，如果需要，怎么在界面里像mediawiki一样在每个文章后面显示出各个版本的差异？我认为我们应该在每个电子书页面的一个区域把这些历史版本的差异显示出来，方便普通用户编辑。）？这个是我们要讨论清楚的。

4、你所说的SVN服务是不是和我们的系统在同一个Server上？SVN的搭建谁来做？如果不和系统在一个Server上，那么把SVN部署到哪里？SVN有个本地copy是不是指SVN里存放这所有电子书所有版本的xhtml？如果SVN不和系统在一个Server上，还的占用流量，你得把这个差异文件发送给系统Server，Server在发送给用户，如果SVN和系统在一个Server上，那么就需要很大的存储来存放本地copy了。

5、数据库里已经在电子书表里有下载路径了，现在字段的长度设置在100个字符，不知道各个网盘的存放路径有多长，如果很长的话，需要把这个字段调正大一些，所以我们要确定这个字段的长度。

6、独立的客户端开发可以放到后续开发里，如果后台程序开发快的话，你们就去开发个客户端（支持那些平台？什么语言开发？），绕开VPS的话，还是那个问题，我们的SVN放在哪？

PS：你们后台采用什么语言来开发？开发平台与OS是什么？（前台我们统一成Linux，VPS上是ArchLinux x86_64）

在 2012年10月3日星期三UTC+8下午1时56分30秒，Fan Yang写道：

[madawei]

@Peter! 你和张经纬有时间的话，可以考虑做过原型出来，线框图也行。做过界面出来，可以让大家对整个用户使用的场景有个大体了解。界面你们可以看下好读与掌上书苑、万卷书等网站，大体和他们差不多，但是区别在于我们要使用在线编辑器，这个编辑器你们去定吧，最好简单，能排版的（可以套用你正在做的EPUB样式）。而且如上面所说，需要偶申请按钮等，有什么问题都可以发出来跟大家讨论。谢谢！

在 2012年10月3日星期三UTC+8下午3时11分12秒，madawei写道：

[madawei]

@书记 接口的问题，最好能写出个文档来，这样大家都能知道怎么调用后台，可以写到wiki去供大家查看。

在 2012年10月3日星期三UTC+8下午2时27分24秒，photon写道：

[Yang Fan]

1，任何主流VCS工具，包括svn都提供所有这些功能，我们只需要调用它就可以获取这些信息；
2，再议；
3，后台服务提供接口，web端调用接口就可以获取diff；
4，svn服务器放在其他服务器上，比如免费的bitbucket。这个矛盾是不可避免的，无论用不用svn，VPS上必定需要保存所有内容和变更的copy，使用svn服务器除了提供版本控制功能外，更是一个备份；相较于同步整本电子书来说，只传输某些xhtml文件的diff这点流量压力已经极小了；
5，100个字符长度足够了，我们可以使用短网址服务把所有云存储链接都缩短；
6，svn放在独立服务器上，比如bitbucket，这样才能绕开web服务器所在VPS；
7，后台服务开发不限开发语言，每个功能独立开发，互不影响，而且会保证强制要求程序实现源代码级跨平台（Win/Linux/Mac），目前看来因人员技能限制以Python/C++为主，但不限于此。

web端需要后台服务提供什么样的接口什么样的通信协议，请尽快定下来。总之，后台服务将只暴露接口给web端使用，至于具体怎么实现，web端可以不予关心。

2012/10/3 madawei <madaw...@gmail.com>:

[madawei]

1、那就使用VCS工具来对xhtml文件进行版本控制。那你们后台是不是需要写这个历史表啊，用来存放版本创建者，时间，书编号等信息，这样前台可以查询数据库得到版本信息么。（解决）

2、再议（未解决）。

3、后台的接口部分需要个文档出来，到时你们提供给前台。（需要文档）

4、SVN服务器的存放服务商留待以后再议（解决）

5、使用短网址服务。（解决）

6、SVN放在独立服务器，服务商再议。（解决）

7、后台开发语言是源码级跨平台的，多种语言开发。（解决）

8、接口的事，请@书记 尽快去定，并写出个文档来提供给后台。

在 2012年10月3日星期三UTC+8下午3时47分49秒，Fan Yang写道：

[Yang Fan]

1，不写数据库，web端调用后台服务来得到相关信息。
3，web端需要什么接口，后台才提供什么接口啊。

2012/10/3 madawei <madaw...@gmail.com>:

[madawei]

1、那就不使用历史表，所有的历史版本的信息均调用后台服务接口来获取信息。（解决）

3、前台需要的接口，@书记 正在写文档，到时会提供给你们的，里面有具体的需求。（解决）

在 2012年10月3日星期三UTC+8下午4时35分10秒，Fan Yang写道：

[Peiwen Lu]

我已经开始写了一部分了，只是我这里没有假期，等周末再拿出来跟大家讨论一下，不好意思呢

2012/10/3 madawei <madaw...@gmail.com>

[madawei]

好的，那就等周末讨论了。

在 2012年10月4日星期四UTC+8上午6时25分23秒，lvpeiwen写道：