![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I just put out the latest release of CommYou. This has various improvements and bugfixes in the IM interface, but probably the most important enhancement is the "!off" and "!on" commands. These were requested by a few people, who really needed to be able to make the system go away during work hours. So this is now decently easy to do -- see this page in the wiki for full details of how to do it...
Aug. 21st, 2008
I just put out the latest release of CommYou. This has various improvements and bugfixes in the IM interface, but probably the most important enhancement is the "!off" and "!on" commands. These were requested by a few people, who really needed to be able to make the system go away during work hours. So this is now decently easy to do -- see this page in the wiki for full details of how to do it...
Related to the new changes in CommYou -- I've just added commands that let you turn CommYou off and on, on an ad hoc basis. This should hopefully be good enough for the time being. But I know what the next request is going to be: full-scale scheduling of that function. Certainly, if I really *needed* it to be consistently gone during work hours, that's what I would want.
That's on the story list, but I'm not going to deal with it for the time being, for the simple reason that it is *hard*. Really Hard. Those of you who haven't written scheduling apps don't appreciate what a pain in the ass they quickly become.
Yes, it looks straightforward enough: what's so hard about saying "turn off at 9am and on at 5pm"? The problem is, that's never really good enough. I mean, first you discover that you only want that schedule on weekdays, not weekends. (Or you are using this for work, so you only want it *on* during work hours.) Then there the consultants, whose definition of the workday is different. Then there are holidays. Then you find that you really need multiple schedules per day, because you want it *on* during the lunch hour so you can check in with folks. And of course, it's deathly important to turn it off next Sunday afternoon, because your grandmother will be visiting and god forbid that conversation about the bachelor party should come across while she's in the room. Etc -- before long, you're writing a complete scheduling app, and those really are a bloody pain.
(We spent a lot of time fighting these particular fires at Convoq, and never did manage to really get it right in any of the cases.)
What I find that I really want is a standard way for you to be able to say, "Here's my calendar, and this category of appointments are for CommYou". CommYou contacts it via some sort of API occasionally, or maybe even gets control signals *from* the calendaring app. You do all your scheduling through an app that's designed for the purpose; you therefore can manage all your schedules in one place; and I don't have to get into the hassle of building calendaring into an application that isn't *about* calendaring.
I'm sure that this could be done with Google Calendar, which is pretty open, but I dislike coding to proprietary APIs unless I must. What I want is a *standard* for this, so that you can be using Google, Microsoft, Zoho or Whatever, and just point CommYou at a URL, or point the calendaring app at CommYou, or something like that. CommYou and the calendar app talk, and you don't need to hassle further about it.
It's a standard the world really needs. And AFAIK, it doesn't really exist yet. There are standards for exchanging calendar data, but not really this kind of command-and-control API for *non*-calendar apps. There should be. I may yet build the CommYou side of this, and see about building one or two generalized plugins for the calendar apps to get the ball rolling...
That's on the story list, but I'm not going to deal with it for the time being, for the simple reason that it is *hard*. Really Hard. Those of you who haven't written scheduling apps don't appreciate what a pain in the ass they quickly become.
Yes, it looks straightforward enough: what's so hard about saying "turn off at 9am and on at 5pm"? The problem is, that's never really good enough. I mean, first you discover that you only want that schedule on weekdays, not weekends. (Or you are using this for work, so you only want it *on* during work hours.) Then there the consultants, whose definition of the workday is different. Then there are holidays. Then you find that you really need multiple schedules per day, because you want it *on* during the lunch hour so you can check in with folks. And of course, it's deathly important to turn it off next Sunday afternoon, because your grandmother will be visiting and god forbid that conversation about the bachelor party should come across while she's in the room. Etc -- before long, you're writing a complete scheduling app, and those really are a bloody pain.
(We spent a lot of time fighting these particular fires at Convoq, and never did manage to really get it right in any of the cases.)
What I find that I really want is a standard way for you to be able to say, "Here's my calendar, and this category of appointments are for CommYou". CommYou contacts it via some sort of API occasionally, or maybe even gets control signals *from* the calendaring app. You do all your scheduling through an app that's designed for the purpose; you therefore can manage all your schedules in one place; and I don't have to get into the hassle of building calendaring into an application that isn't *about* calendaring.
I'm sure that this could be done with Google Calendar, which is pretty open, but I dislike coding to proprietary APIs unless I must. What I want is a *standard* for this, so that you can be using Google, Microsoft, Zoho or Whatever, and just point CommYou at a URL, or point the calendaring app at CommYou, or something like that. CommYou and the calendar app talk, and you don't need to hassle further about it.
It's a standard the world really needs. And AFAIK, it doesn't really exist yet. There are standards for exchanging calendar data, but not really this kind of command-and-control API for *non*-calendar apps. There should be. I may yet build the CommYou side of this, and see about building one or two generalized plugins for the calendar apps to get the ball rolling...
Related to the new changes in CommYou -- I've just added commands that let you turn CommYou off and on, on an ad hoc basis. This should hopefully be good enough for the time being. But I know what the next request is going to be: full-scale scheduling of that function. Certainly, if I really *needed* it to be consistently gone during work hours, that's what I would want.
That's on the story list, but I'm not going to deal with it for the time being, for the simple reason that it is *hard*. Really Hard. Those of you who haven't written scheduling apps don't appreciate what a pain in the ass they quickly become.
Yes, it looks straightforward enough: what's so hard about saying "turn off at 9am and on at 5pm"? The problem is, that's never really good enough. I mean, first you discover that you only want that schedule on weekdays, not weekends. (Or you are using this for work, so you only want it *on* during work hours.) Then there the consultants, whose definition of the workday is different. Then there are holidays. Then you find that you really need multiple schedules per day, because you want it *on* during the lunch hour so you can check in with folks. And of course, it's deathly important to turn it off next Sunday afternoon, because your grandmother will be visiting and god forbid that conversation about the bachelor party should come across while she's in the room. Etc -- before long, you're writing a complete scheduling app, and those really are a bloody pain.
(We spent a lot of time fighting these particular fires at Convoq, and never did manage to really get it right in any of the cases.)
What I find that I really want is a standard way for you to be able to say, "Here's my calendar, and this category of appointments are for CommYou". CommYou contacts it via some sort of API occasionally, or maybe even gets control signals *from* the calendaring app. You do all your scheduling through an app that's designed for the purpose; you therefore can manage all your schedules in one place; and I don't have to get into the hassle of building calendaring into an application that isn't *about* calendaring.
I'm sure that this could be done with Google Calendar, which is pretty open, but I dislike coding to proprietary APIs unless I must. What I want is a *standard* for this, so that you can be using Google, Microsoft, Zoho or Whatever, and just point CommYou at a URL, or point the calendaring app at CommYou, or something like that. CommYou and the calendar app talk, and you don't need to hassle further about it.
It's a standard the world really needs. And AFAIK, it doesn't really exist yet. There are standards for exchanging calendar data, but not really this kind of command-and-control API for *non*-calendar apps. There should be. I may yet build the CommYou side of this, and see about building one or two generalized plugins for the calendar apps to get the ball rolling...
That's on the story list, but I'm not going to deal with it for the time being, for the simple reason that it is *hard*. Really Hard. Those of you who haven't written scheduling apps don't appreciate what a pain in the ass they quickly become.
Yes, it looks straightforward enough: what's so hard about saying "turn off at 9am and on at 5pm"? The problem is, that's never really good enough. I mean, first you discover that you only want that schedule on weekdays, not weekends. (Or you are using this for work, so you only want it *on* during work hours.) Then there the consultants, whose definition of the workday is different. Then there are holidays. Then you find that you really need multiple schedules per day, because you want it *on* during the lunch hour so you can check in with folks. And of course, it's deathly important to turn it off next Sunday afternoon, because your grandmother will be visiting and god forbid that conversation about the bachelor party should come across while she's in the room. Etc -- before long, you're writing a complete scheduling app, and those really are a bloody pain.
(We spent a lot of time fighting these particular fires at Convoq, and never did manage to really get it right in any of the cases.)
What I find that I really want is a standard way for you to be able to say, "Here's my calendar, and this category of appointments are for CommYou". CommYou contacts it via some sort of API occasionally, or maybe even gets control signals *from* the calendaring app. You do all your scheduling through an app that's designed for the purpose; you therefore can manage all your schedules in one place; and I don't have to get into the hassle of building calendaring into an application that isn't *about* calendaring.
I'm sure that this could be done with Google Calendar, which is pretty open, but I dislike coding to proprietary APIs unless I must. What I want is a *standard* for this, so that you can be using Google, Microsoft, Zoho or Whatever, and just point CommYou at a URL, or point the calendaring app at CommYou, or something like that. CommYou and the calendar app talk, and you don't need to hassle further about it.
It's a standard the world really needs. And AFAIK, it doesn't really exist yet. There are standards for exchanging calendar data, but not really this kind of command-and-control API for *non*-calendar apps. There should be. I may yet build the CommYou side of this, and see about building one or two generalized plugins for the calendar apps to get the ball rolling...
Just came across SCA Today's article about a new movie coming out called "Faintheart", described as "a romantic comedy set in the world of Viking re-enactment". Trailer is available online -- not horrifying, but I'm bracing myself for strange questions to start flowing in...
Just came across SCA Today's article about a new movie coming out called "Faintheart", described as "a romantic comedy set in the world of Viking re-enactment". Trailer is available online -- not horrifying, but I'm bracing myself for strange questions to start flowing in...