I would like to point out that the iCalendar spec most certainly does provide the necessary transport bindings to match all the functionality of Exchange group calendaring. Beyond rfc2445 -- the base iCal object spec -- you will quickly find rfc2446 and rfc2447, the iTIP (iCalendar Transport-Independent Interoperability Protocol) specification for "Scheduling Events, BusyTime, To-dos and Journal Entries," and its email-transport binding, iMIP (iCalendar Message-Based Interoperability Protocol), respectively.
Together, these protocols provide all of the communications functionality necessary to implement all of Exchange's non-pure-messaging features -- email meeting, rescheduling, and relocation requests, etc., etc. All that remains is a central store for the distributed calendar, itself, and Apple's confusingly-named iCal product uses a clever solution to this: using WebDAV as a central store supporting distributed editing.
Further, through simple offline folders support, such a solution can quite easily provide offline operation atop a small set of existing and well-established, straightforward and powerful standards.
Perhaps someone should look into building an just such a solution as an OSS project. The simple metaphor for the WebDAV store is simply that each directory represents a Calendar, and is populated with iCal files. This exported interface could just as easily be backed by a database as by a filesystem, using further OSS like Catacomb, and such a system could similarly offer integrated shared file storage, all running through Apache atop either a conventional filesystem or a relational database, and exported through a simple, well-understood, and well-supported filesystem abstraction (WebDAV).
One of the most significant points made by the author of this article is the lack of pointers in Cg. While his reason for including pointers seems to be focussed on higher-level constructs such as scene description mechanisms (scene graphs, etc.) which are handled in the rendering pipeline entirely outside the likes of Cg (and very efficiently, I might add), this point is fundamentally untrue to begin with:
Dependent texture operations ARE pointer operations, and they have been in Cg from the start.
Slashdot Mirror
I would like to point out that the iCalendar spec most certainly does provide the necessary transport bindings to match all the functionality of Exchange group calendaring. Beyond rfc2445 -- the base iCal object spec -- you will quickly find rfc2446 and rfc2447, the iTIP (iCalendar Transport-Independent Interoperability Protocol) specification for "Scheduling Events, BusyTime, To-dos and Journal Entries," and its email-transport binding, iMIP (iCalendar Message-Based Interoperability Protocol), respectively.
Together, these protocols provide all of the communications functionality necessary to implement all of Exchange's non-pure-messaging features -- email meeting, rescheduling, and relocation requests, etc., etc. All that remains is a central store for the distributed calendar, itself, and Apple's confusingly-named iCal product uses a clever solution to this: using WebDAV as a central store supporting distributed editing.
Further, through simple offline folders support, such a solution can quite easily provide offline operation atop a small set of existing and well-established, straightforward and powerful standards.
Perhaps someone should look into building an just such a solution as an OSS project. The simple metaphor for the WebDAV store is simply that each directory represents a Calendar, and is populated with iCal files. This exported interface could just as easily be backed by a database as by a filesystem, using further OSS like Catacomb, and such a system could similarly offer integrated shared file storage, all running through Apache atop either a conventional filesystem or a relational database, and exported through a simple, well-understood, and well-supported filesystem abstraction (WebDAV).
-JRK
Does anyone else notice how much that looks like an FPGA at the center of the board?
One of the most significant points made by the author of this article is the lack of pointers in Cg. While his reason for including pointers seems to be focussed on higher-level constructs such as scene description mechanisms (scene graphs, etc.) which are handled in the rendering pipeline entirely outside the likes of Cg (and very efficiently, I might add), this point is fundamentally untrue to begin with:
Dependent texture operations ARE pointer operations, and they have been in Cg from the start.