Unfortunately, to put it mildly, Safari’s <object> support sucks. It doesn’t handle <object> fallbacks, it doesn’t know when not to handle <object> mime types that it doesn’t support, it doesn’t support display:inline on <object>, and it doesn’t do proper intrinsic sizing of <object> replaced elements.
Personally, as I’ve fired up an increasing number of native apps on the iPhone 2.0 software, I’ve been increasingly frustrated and annoyed at how many of them want my username and password, and how few of them support this kind of delegated authorization flow. (Chris Messina)
…wird Zeit dass ich mir doch mal ein iPhone zulege.
Seesmic scheint in nächster Zeit ne ganze Menge vor zu haben.
Auf dem Screenshot ist übrigens Mr. Topf zu sehen…
Der erste Schritt war wohl die Umstellung von reinem Flash zu mehr HTML, wahrscheinlich um Seesmic semantischer gestalten zu können (die ersten implementierten Formate sind XFN und hCards).
Aber das ist noch lange nicht alles, geplante sind unter anderem folgende Formate und offene Standards:
Open data formats: – RDF as the foundation, and exporters to microformats, HTML, RDFa… – We already use existing open metadata vocabularies – FOAF (for friend management) – SIOC (for community description) – Dublin Core for description of resources – In the process of using a subset of MPEG-7 ontology for video metadata.
Open identifiers: – Public URL scheme, and standardized authentication system. Considering the use of OpenID
Open source technologies: – Use Open Source projects wherever it’s possible. – Open Source critical pieces of the architecture, to allow for greater long term maintainability of complex pieces of software that are not core to the business and can benefit from the community.
Einfach dem dopplr-Vogel eine Freundschaftsanfrage schicken, dann eine Authentifizierungsnummer (bekommt man hier) schicken und warten bis dopplr bescheid gibt.
Danach kann man seinen neuen Standort bequem per d dopplr <Standort> oder @doppler <Standort> aktualisieren.
Das wäre ja schon schick genug, aber dopplr zeigt liebe zum Detail… Wird eine Location nicht gleich erkannt, wird sie archiviert, man bekommt per E-Mail bescheid:
Thanks for sending us a message by twitter.
Sorry, we weren’t able to extract enough information from your twitter to make a trip. We’ve archived it at http://www.dopplr.com/traveller/pfefferle/message/ne_lange_nummer
where you can create a trip by hand if you like.
Yours sincerely, The Dopplr Team.
…und man kann sie jederzeit (über dopplr) verbessern:
Wie schon im Lifestreamerwähnt, habe ich mir (um das Template nicht ändern zu müssen) ein simples six groups – Livecommunity WordPress-Plugin gebaut und vielleicht findet ja auch noch jemand anders Verwendung dafür… 🙂
EMAIL to ID ist ein Service, der eine E-Mail – Adresse zu OpenIDs macht.
Emailtoid is a simple mapping service that enables the use of email addresses as OpenID identifiers.
EMAIL to ID will kein neuer Provider sein, sondern sieht sich selbst nur als Übergangslösung bis E-Mail Services (z.B. GMX oder GMail) selbst diesen Dienst anbieten.
Der Login-Prozess soll folgendermaßen ablaufen:
When a user enters in an email address, there is an xrds discovery made on the top level domain (eg, gmail.com). If the XRDS document contains an Emailtoid mapper or email transformation template, use that. If not, then you make the same request on emailtoid.net to get the mapper document and send the email to there. Emailtoid is a fallback.
Wie genau das Mapping oder das XRDS-Dokument aussehen soll ist noch nicht spezifiziert, wird aber demnächst hier zu finden sein.
Macht eine E-Mail – Adresse als OpenID Sinn?
In Zukunft steht sicherlich die URL im Zentrum des Authentifizierungsprozesses, da sich über sie einfach mehr Informationen transportieren lassen (seien es Meta-Information oder Semantisches HTML). Auch das Semantische Web basiert auf URIs, um verschiedene Informationen zu vernetzen. Aus diesen Gründen sollte man den User mal so langsam an diese neuen Umstände gewöhnen 😉
Mit EMAIL to ID kann der Nutzer seine bestehenden Gewohnheiten (Anmelden per E-Mail – Adresse) beibehalten und trotzdem die Vorteile von OpenID nutzen (Simple Lösung für ein scheinbar schwieriges Problem… hat was vom Ei des Kolumbus).
Warum kein eigener Standard?
Ein neuer OpenID Standard auf Basis von E-Mail – Adressen (wie hier angedacht) würde zusätzlichen und unnötigen Implementierungsaufwand bedeuten (nimmt man an, die URLs sind die Zukunft), den man sich bei EMAIL to ID sparen kann. EMAIL to ID mappt eigentlich nur eine E-Mail – Adresse auf eine URL http://emailtoid.net/mapper?email=jane@example.com und entspricht somit einer vollwertigen OpenID (keine Anpassungen am bisherigen Standard nötig).
The momentum began building for ‚data portability‘ last year, and we are now at a point where there is strong support for the principle that users should be in control of their data and have the freedom to access it from across the web.
[…]
The goal of Portable Contacts is to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web.
[…]
…we’re using existing standards wherever possible, including vCard, OpenSocial, XRDS-Simple, OAuth, etc.
Da spricht man von einheitlichen Standards und Portabilität, schafft es aber nicht, gemeinsam an einem Projekt zu arbeiten… Ich sehe kaum Erleichterung darin, statt verschiedener proprietärer APIs (z.B. Google’s GData Contacts API oder Microsoft’s Live Contacts API) wahrscheinlich mind. genauso viele unterschiedliche standard APIs (Data Portability oder Portable Contacts) implementieren zu müssen!
