In a modern distributed company in order to communicate, businesses use tools like teleconferences (urgh), email, instant messaging (which one?) and more integrated packages like campfire.
Or you can be a little old school and use existing platforms for real time chat like Inter Relay Chat (IRC). IRC does exhibit quite a learning curve, though if your company are engineers, it shouldn't be too much a problem to learn how to use IRC.
Here is a guide to setting up your company with a private channel on Freenode. Whilst running your company on Freenode is not strictly on topic, it certainly isn't off topic.
I think Freenode should definitely discreetly host company channels, since it will only encourage companies to contribute to open source software projects down the line.
NickServ - user authentication
First you need to register with nickserv, /msg nickserv help register
Then you need to configure your IRC client to authenticate (identify) to the nickserv on startup. Ideally all your employees need to do this, though you can restrict your channel to IPs instead.
ChanServ - restricting your channel to your employees
Setup a dialog with chanserv and then begin like so:
help
help register
Which provides help how to register your channel. For the purposes of this tutorial, I'll use #example.
register #example
Then (providing your registered and identified with NickServ), you will become the founder of this channel.
So lets assume all your employees come in from the IP nat.example.com, you
can now restrict the channel to those personnel, like so:
FLAGS #example *!*@nat.example.com +V
set #example RESTRICTED ON
So FLAGS sets up the access control list. To see who is on the list:
access #example list
To add an additional admin user:
FLAGS #example ircusername +votsriRfAF
If a user tried to join your restricted channel, the user will be immediately kick banned. So if that user is for example later added on the access list, you need to unban that user for that user to rejoin the channel.
To see the current bans in place for the channel:
/mode #example +b
To remove a ban for say 8.8.8.8:
/mode #example -b *!*@8.8.8.8
Transcripts
What about transcripts? If you run a decent IRC client like
irssi, with screen and Apache httpd vhost on /web it's as
painless as:
/SET log_create_mode 755
/LOG OPEN -targets #example /web/irc.example.com/%Y-%m-%d
Then if we to refer to our chat yesterday I would simply say check out
http://irc.example.com/2010-06-14. To password protect the site, simply use an .htaccess like so:
irc.example.com$ cat .htaccess
Order deny,allow
Deny from all
AuthType Digest
AuthName "acme"
AuthUserFile /web/digest-password
Require valid-user
Satisfy Any
To me the W3C DAP calendar is a reworked BONDI calendar, which simply misses the mark for me. Nevermind the proposed added complexity and the "god knows how" the two APIs are going to converge, lets start at the beginning.
- A web application would like to access the device calendar
- A user would like to create/modify/delete a Calendar appointment
- A user would like to enter a birthday of his friend with a recurrence event
- A user would like to set a reminder for upcoming events.
Lets distil what we are trying to do. Because I for one don't care about the calendar of my mobile device (who does?). I care about the calendar on my Web service http://calendar.google.com. I find out about friends' birthdays on http://facebook.com. What I want my personal mobile device to do, is to remind me about those events in my calendar.
How does one get reminded? The way I have been doing it for years is setting alarms on my personal mobile device.
Alarms to wake up. Alarms to go to my dentist appointment. Alarms reminding me about my Mother's birthday. The most basic alarm just sounds or vibrates the phone at the start of the appointment. More advanced alarms could notify you (in advance) in a variety of ways.
So what I am saying we don't need a calendar API, we need a reminder API. A good clean native API implementation on an Android smartphone looks like:
The dreaded repeating UI is very simple and it just works for most cases. I've done this before.
The easiest way to implement this natively is to leverage cron, for example:
# m h dom mon dow command
35 7 * * sun alarm
30 6 * * mon alarm
5 7 * * tue,thu,fri alarm
40 6 * * wed alarm+vibrate
0 8 * * sat alarm
The "Alarmed" Calendar WebIDL
interface Alarm {
attribute DOMString name;
attribute DOMString m;
attribute DOMString h;
attribute DOMString dom;
attribute DOMString mon;
attribute DOMString dow;
attribute DOMString action;
};
interface AlarmFilter : Alarm {};
typedef sequence<Alarm> AlarmArray;
typedef sequence<DOMString> StringArray;
interface Callback {
void call(Object ob);
};
interface AlarmManager {
void set(Callback c, AlarmArray alarms);
void get(Callback c, [Optional] AlarmFilter filter);
void del(Callback c, [Optional] AlarmFilter filter);
};
Using man 5 crontab as a guide, lets set an alarm for getting up for work:
navigator.alarm.set(
function(ob) {
if (ob instanceof Error) { alert(ob); }
else { alert("Alarm(s) set " + ob); }
}, [{ name:"wakey wakey", h : "7", dow: "1,2,3,4,5", action: "sound"}]);
Lets sync our alarms with our service in the cloud, like so:
$.getJSON("http://calendar.example.com/?auth=" + auth + "&callback=?",
function(data){
navigator.alarm.set(
function(ob) {
if (ob instanceof Error) { alert(ob); }
else { alert("Alarm(s) set " + ob); }
}, data);
}
If I leave out the filter, I mean all:
navigator.alarm.del(
function(ob) {
if (ob instanceof Error) { alert(ob); }
else { alert("All alarm(s) deleted " + ob); }
});
navigator.alarm.get(
function(ob) {
if (ob instanceof Error) { alert(ob); }
else { alert("Active alarm(s)" + ob); }
});
Hell, you could implement this cron in Javascript if you had HTML5 audio and some UI vibrate and flash goodies at your disposal.
I also think it's important to have a mapping to a RestFUL API, for example:
POST /set
Req: {{ m: "*", h: "*", dom: "*", mon: "*", dow: "*", action: "sound+vibrate+flash" }}
Res: [ 1 ] // affected ids or name
POST /get
Req: { m: "*", h: "*" }
Res: [
{ m: "*", h: "*", dom: "*", mon: "*", dow: "*", action: "sound+vibrate+flash" },
{ m: "*", h: "*", dom: "*", mon: "5", dow: "*", action: "sound+vibrate" }
]
POST /del
Req: { "1", "wakey wakey" }
Res: [ "1", "wakey wakey" ] // affected reminder ids/names/labels
That way I could send an alarm set request (with some auth magic) on my mobile's httpd endpoint at for example http://192.168.1.10/alarm/set without even touching my mobile device.
Please let me know what you think.
Cons:
- The Android "clock" interface I said was great can't actually describe a cron job accurately. However, the repeating UI could be extended for simple representations of 'm,h,dom,mon'
- Cron has issues like not knowing holidays and stuff like that. I guess a clever implementation could mark this.
