Getting microformats working with web services

Hey Google, Yahoo! and 30 Boxes (and others).

PLEASE create places where I can simply POST vCards or iCals or microformats or JSON or something else to your services to add contacts and calendar entries. I’m not a web app, so I can’t get an API key. And I shouldn’t have to maintain login state when the browser is doing it for me. All I want is an easy way to add stuff to a logged in users account. Is that too much to ask?

With Yahoo! calendars and contact, as well as Google Calendar, I have to resort to undocumented URL syntax. Google Contacts I can’t do anything. 30 Boxes requires that the ics file be physically located on a server, although they have a URL syntax that kind of works.

It doesn’t even have to be a POST. If you could come up with some straightforward URL syntax, that would be great. Trying to figure out the stuff you guys have put together so far is incredibly painful.

So please. Help a guy out.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

8 thoughts on “Getting microformats working with web services

  1. To get to the common ground, it should be fairly straightforward to map VCARD and VCALENDAR to application/x-www-form-urlencoded:


    Why hasn’t anyone done this before?

  2. I’ve been thinking that an openactions.xml format maybe useful here, similar to opensearch.xml. This way sites that want to be microformat consumers could 1. ‘create a post url’ 2. ‘create an openactions.xml’ file. auto-discovery etc. can happen similar to opensearch (i.e. a entry).

    This way in addition to reverse engineering what other sites are doing, providing sites a mechanism to integrate with FF/operator easily should go a longways to getting them to give users tools to unlock the value of their microformatted pages.

  3. hi mike,

    i’m the guy who explained the brilliance of “operator”, to a fellow a while back. this is prob stupid, but why not just make a little tool for site folks to grab a contact from an onscreen list and make a really simple page, and then jiggle IP er ator to look for that page.

    it’s ugly, but i s the issue maybe the implementation of contacts and human lazyness collidibg. everyone has their own contact info in a list, so make sure you can drill into the biggest ones, and let site operators just stuff a 20 line page with the info. then you just gotta get your software to recurse looking for some little character no_one uses, which your WIGGET puts in a age at the top. now you can make all sorts of fun stuff come aft er, since it’s only used by you, make it do whatever you want. Like i said, kinda dumb, but check this out:

    No lie… i worked for a software company and they used a fake ini file to prove registered vs trial, by looking for an “r” in the first line, placed before the authors birthday in binary. so dumb it was brilliant. i never came across a single stolen copy I NM 5yrs…

    just an idea.

  4. sorry for all the hookey typing last post. keyboard is predicting…:) i meant operator looking for a page with a character, the idea is lazy is the problem. just get to existibg contacts, build a simple text page and throw it a.nywhere it could even be non listed I MN a dir, as you can tell the tool how to store it, so finding it should be nonproblematic. if its brain NB dead simple, website creators would use it, why not?