h a l f b a k e r yThese statements have not been evaluated by the Food and Drug Administration.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Imagine I've subscribed to some online calendar. Imagine also that I've gone to some site
and just bought tickets for some movie tonight. It would be
awesome if there were some way for distributed web-app sites to
transfer information from one to the other such that I could
immediately go back to
my calendar online and see that it now
shows an entry for that date and time - even though the
calendar and ticket site are separate companies.
Component Service Provider
http://www.halfbake...nt Service Provider
Jim's Flanagan's coinage of this term is apt. XML-RPC (and SOAP) is a reasonable protocol. Furthermore, it's working: Jim added discussion to his weblog using Take It Offline's XML-RPC interface. With similar published interfaces, sites should be able to easily add services provided by other sites. [syost, Mar 28 2000, last modified Oct 04 2004]
iCalendar
http://www.oasis-op...cover/xml.html#iCal
The iCalendar XML DTD could be of use here. Note that it expired as an Internet-Draft last week (http://www.imc.org/draft-many-ical-xmldoc). iCalendar seems to be about general calendar sharing. More is probably needed to define an interface for updating an individual calendar. I haven't read the full draft. Maybe a quick answer could be gotten from Frank Dawson. [syost, Mar 28 2000, last modified Oct 04 2004]
XML Protocol Comparison at W3C
http://www.w3.org/2...XML-protocol-matrix
Compares protocols with various levels of generality and gives their current status [syost, Mar 28 2000, last modified Oct 04 2004]
Calendaring and Scheduling IETF Working Group
http://www.ietf.org...calsch-charter.html
"This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access protocols between systems and between clients and servers..." [egnor, Mar 28 2000, last modified Oct 04 2004]
[link]
|
| |
Perhaps, though XML-RPC has issues. |
|
| |
But Triptych's scenario requires
something more. Ideally, the ticket
vendor wouldn't just hook up with one
particular calendar vendor, but
instead send a general "calendaring
event" through the user's browser to
*any* Web site the user has elected
to use for calendaring. |
|
| |
It's unclear whether this would
happen immediately, or whether the
event would wait, cookie-like, until
the user next visited the calendar
site. |
|
| |
(Of course, the protocol should be
fully general, not restricted to
calendaring per se.) |
|
| |
It would be a Cool Thing, when
combined with standard schemas
for things like calendar events.
Security and privacy options abound;
it would have to be constructed
carefully. |
|
| |
Sending "events" through a browser from one site to another is fraught with security problems and of course requires new browsers. I would like, however for a ticket site to give me a choice of calendaring sites -- that list being the ones that support the defined interface. |
|
| |
The fully general protocol is at the level of XML-RPC or SOAP. The calendaring instance would be, for example, a specific XML-RPC/SOAP interface that's agreed upon by calendaring vendors. |
|
| |
RSS is another XML-based description that's enabling lots of interesting sites like my.netscape.com, my.userland.com, http://www.oreillynet.com/meerkat/, and others. It's just another example of inter-site coordination that's enabled by agreeing on a spec. |
|
| |
What are the issues with XML-RPC? Post here or send me email: syost at takitoffline dot com |
|
| |
Thanks to [syost] for drawing my attention to this discussion. I posted a rant at Edge City (http://edgecity.convey.com/index.cvy?a=page&sec_id=7492&page_id=20656) on a similar topic. Here's a quote:
"There is no interoperability (or next to none) between the various services. I cannot maintain more than one calendar(or maybe two, at great personal and manual involvement). |
|
| |
What would be cool would be to have the equivalent of POP3 access to calendar information, so that one calendar system could suck information from another. This is an obvious opportunity for the syncronization people, like Intellisync and Starfish. (Instead, Starfish has created yet another not very good web PIM, www.truesync.com... I never could figure out how to a/ contact customer support, or b/ how to created shared calendars.) " |
|
| |
stoweboyd, could use you use "link" to enter a URL, instead of "annotate"? That way it's clickable. |
|
| |