系统的建设一个日历服务
will-ww opened this issue · 34 comments
以下这个流程应该可以~
- 制作(导出)ics格式的日历
- 把ics文件放到oss上
- 各个日历app订阅对应的url即可
ics resource: http://icalshare.com
Originally posted by @tyn1998 in X-lab2017/open-research#4 (comment)
我将前面的讨论,转换到此处的 issue,希望能够系统的建设一下实验室的日历服务。
对于时间管理而言,日历服务是个非常重要的工具,请@tyn1998 来系统的帮忙考虑下,如何建设起来。
一些典型的场景包括:
- 上课
- 组会
- 各类社区活动
- 论文会议投稿
- 等等
没问题~
方案一
此方案不需要部署任何服务,而是充分利用已有主流日历App,进行了流程上的整合。
前置知识
.ics
文件是遵循iCalendar标准的开放格式文件。简单的说,.ics
文件按照一定的格式记录了日历中所有日程的信息,支持.ics
格式的日历应用将其导入便可呈现在应用界面中(只读不可编辑)。导入.ics
文件是一次性的,我们想要的是“订阅”日历,这样一旦日历发布者更新了日历,订阅者也能保持同步。在这种订阅机制中,发布者给出一个URL,订阅者添加该URL到支持该机制的日历应用中,于是应用每隔一段时间会访问该URL获取最新的.ics
文件,从而保持同步。
CalDAV是WebDAV的扩展。简单的说,如果两个不同的日历应用,叫它们A和B,都支持WebDAV,那么就可以在B上将A添加为一个CalDAV账户,这样在B上就能管理A中的日历,即实现了双向同步。
如果你是日历发布者
推荐在Google Calendar和Outlook Calendar选一个。下面的表格展示了两者的features:
Google Calendar | Outlook Calendar | |
---|---|---|
有Web版应用? | Y | Y |
界面交互棒? | Y | Y |
支持时区? | Y | Y |
支持日历发布为订阅地址? | Y | Y |
支持日历发布为公开页面? | Y | Y |
支持日历发布为iframe? | Y | N |
支持二次发布日历? | Y | N |
支持CalDAV? | Y | N |
不使用代理也能用? | N | Y |
要不是Google Calendar在国内市场有硬伤——必须使用代理才能访问,我只会推荐它一个。微软由于推自家的Exchange协议,甚至都不支持CalDAV。我来解释一下其中的一些features:“支持日历发布为公开页面”的意思是,任何人可以通过该网址直接访问该日历;“支持日历发布为iframe”的意思是,支持将日历嵌入到自己的网站中,可以很方便地做集成;“支持二次发布日历”的意思是,可以将订阅的第三方日历二次发布出去。
选择好平台后,你只要正常创建日程,然后发布为订阅地址即可。对于不同类型的日程,请创建不同的日历来管理它们!如果有多名日历管理者,可以共用一个号,或是采取CalDAV的方式;如果他们使用同一品牌的日历应用,那将某个日历的编辑权开放给指定管理者是个更好的方式。对于X-lab来说,将已发布日历的订阅地址放在X-lab2017/open-calendar/README.md中也许是个不错的宣传方式~
如果你是日历订阅者
你只需要确保你使用的日历应用支持订阅日历即可。各日历应用订阅第三方日历的操作各不相同,这没什么问题。但是,各日历应用更新订阅的机制(频率)有很大的差别。
举个例子,苹果日历在订阅日历时就能设置更新频率为5min~1周不等,甚至还可以手动刷新;但是Google Calendar的订阅更新频率在8h~12h,还没法修改,也没法手动更新,除非重新订阅一次!如果你订阅的是诸如“**节日”这样的日历,更新频率是多少完全无所谓;但如果你订阅的是诸如“X-lab会议”这种动态性比较强的第三方日历,那更新频率自然是越高越能做到“up to date”。
PS:如果你是苹果用户,使用自带的日历是最好的!你甚至可以在订阅日历时选择将日历放在icloud中,这样同账户下的其他设备就不需要单独订阅了。
暂时还没有方案二、方案三。搜索了挺多东西,一开始设想过使用GitHub管理并涉及编程和部署服务的方式,但是这对日历发布者来说成本太高了,不利于日历的及时更新。方案一充分利用了已有的成熟的日历应用,整合了一套流程,唯一需要额外做的就是宣传一下日历的订阅地址,比如开个仓库把订阅地址写到README中~
- 作为订阅者,功能方便、准确的使用最为重要,比如说我是一个Windows 用户,可能使用本身自带的Calendar 是最方便的,Google Calendar 不是开箱即用又需要额外翻墙,日历的最大的作用应该是提醒功能,我每次打开电脑,自动提醒,如果能做到这个我觉得才有价值,如果用户打开电脑还要手动另外打开一个额外的工具,可能就会带来忘记使用到最后不用。
- 作为发布者,使用的频率可能并没有那么高,但是如果通常发布者也会是订阅者,两者统一工具的话可能效果最好,避免相同事情不同的入口。 其次,安全性的保证也需要考虑,私密calendar 是否有存在的可能,那么如何保证这些calendar的存在是否现在的方案有一定的考虑?
- 如果能够做到移动端就更好了,现在很多华为系统的日历他可以自动读取其他第三方app 订阅的会议,然后在华为手机或者手表上日历上自动添加和同步进去,然后自动提醒用户,这一点做得非常好。
4.还有一点,发布日历的时候能否查询参与人员的日历来确定冲突的发生? 比如说我要定一个会议,需要喊几个人来一起参加,我在定这个会议的时候,可能需要知道参与人员在该时间段是否有其他会议或者活动冲突
上述几点供工具选型和设计的时候参考使用
谢谢张老师的建议!我来回复下~
对于1,如果考虑到不是经常挂着代理的用户,发布者的确不应该用Google Calendar,因为更新订阅需要走代理。而对于订阅者,正是鼓励Ta用自己习惯的日历应用,只要这个日历应用支持订阅即可。
对于2,发布者选用什么日历应用必须考虑到该日历应用是否支持发布日历为订阅地址。如果因此造成了“多入口”,只要两者支持CalDAV,也能变成“单入口”管理。张老师说的私密calendar应该是指团队日历吧,对于这种情况,我觉得应该是用飞书、钉钉这种团队协作的工具;方案一对应的场景其实更偏向于公开和开放。
对于3,只要使用的日历App支持将日历发布为订阅地址,且那些会议App自动添加日程到这本日历中,那就没问题的。
对于4,我觉得这个需求还是使用正统的团队协作应用来搞定比较合适哈哈。
总的来说,这个日历服务中的日历更偏向于更新频率较低的,比如“感兴趣的学术期刊的征稿期”、“X-lab实验室秋季学期固定会议”、“2022年开源活动”等。如果是用于团队协作的话,应该用正统的应用更好。此外,对个人来说,如果你在多个日历应用上都有日程(分散在各日历应用中),可以使用CalDAV将它们在一个日历应用中管理(见“前置知识”)。
我觉得,我们可以考虑 follow TODO 的模式来建立日历信息共享服务:https://todogroup.org/community/
大家有啥建议? @tyn1998 @AliceCodeZhang
支持日历发布为iframe? Y N
王老师,TODO的这个就是前面提到的Google日历的iframe功能~
有后续不?我们是否可以尝试着落地下~
start working on this~
支持日历发布为iframe? Y N
王老师,TODO的这个就是前面提到的Google日历的iframe功能~
有后续不?我们是否可以尝试着落地下~
start working on this~
好咧,那我们就先按这个模式搞起来,先把我们的组会运营起来,然后不断加入 event~
我先用Google Calendar探索一下~
实验室公共Gmail账号目前定为:xlab2017.ecnu@gmail.com
创建多个日历不仅利于分类维护,还能让用户选择性地订阅其中的若干个日历。这里需要王老师 @will-ww 拿个主意:
- 要创建几个日历?
- 每个日历的“名称”和“简介”是什么?
我觉得从实验室的角度看,至少应该有这几个视角:
- 内部团队(@will-ww ):主要包括我们自己的几个组会、活动等
- 学院学校(@bifenglin ):学校、学院层面的活动、大家的课程安排等
- 外部社区(@xiaoya-Esther ):外部所有我们关心的活动,ONES Group、TODO、CHAOSS、标准院等
我们可以约个时间,和几个日历的负责同学,做个简单的共识与培训,然后把这个日历体系用起来~
@tyn1998 麻烦添加下协作者,bifenglin1017@gmail.com
@tyn1998 麻烦添加下协作者,bifenglin1017@gmail.com
@tyn1998
我的Gmail: willtongji@gmail.com
目前一共有四个日历(内部团队、期刊会议、外部社区、学校学院),都给王老师加上了~
这个日历内容我加完了,是不是需要进行在实验室内推广一下。
毕博现在加的内容是不是大家课程的集合?
这个日历内容我加完了,是不是需要进行在实验室内推广一下。
可以的,我们稍微Review优化下,写个使用文档,然后就可以推广了。
毕博现在加的内容是不是大家课程的集合?
是的。
毕博现在加的内容是不是大家课程的集合?
是的。
我记得前几天
暂时还没有方案二、方案三。搜索了挺多东西,一开始设想过使用GitHub管理并涉及编程和部署服务的方式,但是这对日历发布者来说成本太高了,不利于日历的及时更新。方案一充分利用了已有的成熟的日历应用,整合了一套流程,唯一需要额外做的就是宣传一下日历的订阅地址,比如开个仓库把订阅地址写到README中~
我记得哪天上课哪位老师说过一个方案,大概就是每个人都可以把自己的日历做好,然后快速会议可以根据每个人这个时间段有没有时间来拉人,但是具体是哪个平台我忘记了 @tyn1998
毕博现在加的内容是不是大家课程的集合?
是的。
我记得前几天
暂时还没有方案二、方案三。搜索了挺多东西,一开始设想过使用GitHub管理并涉及编程和部署服务的方式,但是这对日历发布者来说成本太高了,不利于日历的及时更新。方案一充分利用了已有的成熟的日历应用,整合了一套流程,唯一需要额外做的就是宣传一下日历的订阅地址,比如开个仓库把订阅地址写到README中~
我记得哪天上课哪位老师说过一个方案,大概就是每个人都可以把自己的日历做好,然后快速会议可以根据每个人这个时间段有没有时间来拉人,但是具体是哪个平台我忘记了 @tyn1998
zhangyanbin老师
毕博现在加的内容是不是大家课程的集合?
是的。
我记得前几天
暂时还没有方案二、方案三。搜索了挺多东西,一开始设想过使用GitHub管理并涉及编程和部署服务的方式,但是这对日历发布者来说成本太高了,不利于日历的及时更新。方案一充分利用了已有的成熟的日历应用,整合了一套流程,唯一需要额外做的就是宣传一下日历的订阅地址,比如开个仓库把订阅地址写到README中~
我记得哪天上课哪位老师说过一个方案,大概就是每个人都可以把自己的日历做好,然后快速会议可以根据每个人这个时间段有没有时间来拉人,但是具体是哪个平台我忘记了 @tyn1998
zhangyanbin老师
好像当时上课讲的是飞书是嘛,google calendar可以实现嘛