OnceDB是OnceDoc企业内容(网盘)管理系统的底层数据存储机制。它将Redis扩展增强成为一个分布式模式定义内存数据库,它将Redis从一个简单的健/值存储数据库,增强为支持索引和关系查询的模式(schema)数据库。在OnceDB中,数据模式将由具体应用而不是数据库来决定。通过OnceDB您可以自由动态定义数据库模式,或者在扩展模块中修改或扩展展已有的数据库存储模式。OnceDB即拥有内存数据库的强大性能,同时又具备强大的定制和扩展能力。
OnceVI 通过简单的控件拖拉和数据绑定即可显示条形码。基于条形码(Barcode)和二维码(Qrcode),由于其优良的特性在管理信息系统的设计中被广泛使用。目前广泛应用在企业内部管理、生产流程、物流控制系统方面。是报表系统中必不可少的功能特性这一。OnceVI支持直接显示条形码与二维码。只需要简单拖拉即可实现,
before函数提供了一种机制,可以在文件接收之前根据req.headers对文件进行验证(如大小、类型),return true 表示验证通并开始接收文件。在这里 before 中的回调函数会根据 req.headers 中的 content-length 判断上传的文件是否超出了尺寸限制(开发人员可以通过修改 if 语句中的常数改变文件上传尺寸上限,content-length 单位为 byte,1024 * 1024 即代表 1 MB),如果超出了,文件不会被上传,服务器返回错误信息;如果没有超出,函数返回值为 true,服务器继续执行 app.file 中的回调函数,将文件从临时地址转移到指定存储地址,文件上传到这里就完成了。
我们对OnceDoc网页版进行了更新。OnceDoc网页版现具有文档管理、知识管理、流程管理、邮件系统、云端开发、书签收藏、微信办公等多种功能。我们诚恳地邀请您体验试用。
如果您在使用OnceDoc时遇到问题,或者对我们有任何意见建议,欢迎直接回复此邮件。 OnceDoc将用心倾听您的建议。
单线程的 Node.js 为了充分利用 CPU 的多核特性,采用了 cluster 模块,利用主从模式,生成与 CPU 核心数量相当的子进程,主进程捕获请求随机分配给子进程处理,并负责子进程的崩溃重启。进程与进程之间是不能共享数据的,如果把 Session 存储在内存里,存储在不同进程的内存中的 Session 将无法共享,Session 认证机制会出现问题。例如,用户 A 认证的过程是由进程 1 处理的,那么维持会话的 Session 将保存在进程 1 的内存数据中;用户 A 接下来的请求被分配给进程 2 处理,因为进程 2 没有处理过用户 A 的认证,没有维持这个会话的 Session,所以进程 2 会判断用户 A 并没有授权。这样用户 A 需要多次重复认证访问才能继续下去。
OnceIO 是一个自身功能极简,完全由路由、中间件和Handler构成的 web 开发框架:一个 OnceIO 应用本质上就是在调用各种中间件和Handler。
中间件是一个函数,它可以访问请求对象(request object (req)), 响应对象(response object (res)),并将应用的请求-响应循环传向下一个中间件。
一个应用的请求-响应循环如下图所示,由请求对象、响应对象、中间件和 handler 构成。
OnceDoc是一个高性能的、高度独立的企业内容(网盘)管理系统,底层技术完全自主实现。你仅需预先安装好NodeJS的运行环境,无需配置例如IIS、Tomcat、MySQL/SQLServer、环境变量之类的复杂依赖,解压即用。不需要您具备任何IT知识,,30秒即可完成安装,打造专属于您自己的网盘和在线文档编辑工具。
Github在去年7月刚刚完成了一轮2.5亿美元的融资。然而据TechCrunch报道,Github正在寻求第二轮融,或是为了投资者或员工的清算做准备。
此传言有两点,此轮融资可能低于之前的20亿美元的估值。消息来源方透露此轮估值可能在15亿美元左右,目前还不能透露具体数额。然而另外也有传闻称此轮融资或为普通股。所以这一轮的估值可能可能比较模糊,或者不是传统意义上的下一轮融资。
HTTP 是一种无状态的协议,服务器单从网络连接上无从知道客户身份,这给交互式 Web 应用程序的实现带来了阻碍。Session 和 Cookie 一样,也是用来绕开 HTTP 的无状态性的手段之一,但与 Cookie 在客户端保存状态信息不同,Session 将用户的状态信息保存在服务器端。
当应用程序需要为某个客户端的请求创建一个 Session 的时候,服务器会首先检查这个客户端的请求里是否已包含了一个 Session 标识,即 SessionID。如果已包含一个 SessionID,则说明服务器为此客户端创建过 Session,服务器就会把这个 SessionID 对应的 Session 检索出来使用(如果检索不到,可能会新建一个);如果客户端请求不包含 SessionID,服务器就会为此客户端创建一个新的 Session 并且生成一个与此 Session 相关联的 SessionID。SessionID 的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串。这个 SessionID 将在本次响应中被返回给客户端保存(常放在 Cookie 中返回,客户端 Cookie 禁用时也可放在 URL 中)。