head.log

A ja raczej nie jestem zwolennikiem tego poglądu, choć jestem tak jak CoSta leniwy i wygodnicki. Po pierwsze: ten apel to tylko apel. Wąptię, aby ktokolwiek go posłuchał.
Przyczyn jest parę. Oto narzędzia blogowe są to najczęściej Open Source, więc ustalenie konsensusu formatu tych danych będzie zadaniem heroicznym. Osobiście myślę, że nawet nie dojdzie do jakiejś wspólnej dyskusji. Ponadto – tych narzędzi jest sporo: różnice są nie tylko w formacie danych, ale w ich lokalizacji bazodanowej, stronie kodowej etc.

O ile jest sens przenosić dane – czyli głównie treści wpisów – to im głębiej w strukturę, tym gorzej – u mnie w Nucleusie nie ma wątkowania komentarzy, a u Costy są. U mnie odnośniki (trackbacks) są wyświetlane łącznie, a w WordPress są wplatane między komentarze.

Ba – nawet na poziomie samych wpisów mogą być problemy. Nucleus zarządza/wyświetla media (grafiki, pliki etc.) za pomocą komend:
<%image(20060408-tech_0.jpg|500|667|słuchawki Technicsa)%>
więc dlaczego mam oczekiwać, że serendipity ma je rozumieć?
I tak dalej…

Ponadto: istnieją usługi blogowe – seriwsy, które nie są aplikacjami, skryptami. W ich interesie leży raczej to, aby użyszkodnik był mało mobilny.

Zatem osobiście optuję za rozwijaniem konkretnych migratorów (konwerterów) z konkretnej aplikacji A do innej, konkretnej aplikacji B. Tak zresztą się dzieje na codzień. Autorzy Nucleusa oferują importery z WordPress i Movable Type (plus parę innych – nieoficjalnie). Innymi słowy: to autorzy konkrentych systemów blogowych mogą tu cokolwiek zrobić – i robią. Ale nie jest to omnipotentny system importu/eksportu z czegokolwiek do czegokolwiek! Tą tendencję można wspierać właśnie z ich strony: np. publikując jakieś API lub opisując kompletnie struktury baz danych.