Bártházi András már megírta a saját postját az OpenSocial -ről, de úgy gondolom, van még mit hozzátenni a témához, úgyhogy én is mondanék erről pár dolgot.

Bevezetésképp.

Anno az ischmerősök fejlesztésekor tartottam egy előadást, mely többek közt kitért a Social Network API-k (hosztok) feladataira is. Ezek:

  • Adatgazda - hozzáférést ad a rendszer adatbázisához, opcionálisan üzleti logikai rétegéhez
  • Authentikáció és authorizáció - biztosítja, hogy a felhasználó az, akinek mondja magát, ugyanakkor nem enged jogosulatlan hozzáférést a beépülő alkalmazásnak
  • Megjelenítési felület - megjelenési lehetőséget biztosít az alkalmazásnak

Természetesen egy ilyen rendszernek vannak feladatai, felelősségei a felhasználó felé is (alkalmazásmenedzselés, felületmenedzselés, jogmenedzselés), de mi most ezzel ne foglalkozzunk, az alkalmazásíró szemszögéből nézzük a dolgokat.

A jó

Mondjuk előszőr a jót: Az opensocial relatív tűrhetően ellátja az adatgazdai feladatokat. A következő dolgokhoz ad hozzáférést:

  • Egy felhasználó adatlapjainak elemeihez
  • Egy felhasználó saját hírfolyamához (Activity) - ehhez írást is!
  • Egy felhasználó baráti köréhez
  • Saját privát (kulcs-érték típusú) tárolóhoz

További jó hír: Ezek annyira alapvető dolgok, hogy szinte bármelyik social network tudná őket implementálni. Valószínűleg ezek azok, amikben sikerült megegyezni közös nevezőként, lehetne több is, de a semminél most is több.

Ezzel kb. végeztünk is a jó hírek felsorolásával. Miért?

A rossz

Eleve kezdjük ott, hogy a másik két pontról elég kevés szó esik. Azt minden egyes oldalról megtudhatjuk, hogy hogyan kell orkutra authentikálni - Google Accountsszal, hogy máshogy? - de hogy ezt hogy kéne általánosságban elképzelni, arról néma csend van. Van még szó valami HIGH meg LOW priority -s hírposztolásról a felhasználó nevében, de ezt finoman szólva se nevezném fine tuning megoldásnak. Szóval ennyit az authentikációról és az authorizációról.

A megjelenítés is el lett ott intézve, hogy használj Google Gadget kompatibilis megoldást, és hogy jipijjé, mégcsak hostolnod se kell, merthogy van Gadget Editor (vajon a mashup editorra gondoltak?). Azért egy PHP+Java+Ruby (igények kielégítése végett +ASP.NET+Python) függvénykönyvtárnak jobban tudnék örülni, meggyőzőbb lenne. Értem én, hogy a jó kóder tud kódolni Google Mashup editorral is, meg fejben transzformál imperatív és deklaratív modellek közt odavissza, de azért ez mégiscsak az egyszeri PHP-s szegénylegény igényeit lenne hivatott kielégíteni.

(Aki egy teljes információs rendszer logikáját javascriptben akarja tárolni, cseréltesse le a szuperszámítógépét valami normál tempójú masinára, hátha észhez tér…)

A csúnya

Ezzel aztán el is érkeztünk a csúnya részhez: adnak egy-egy példa-XML-t (pontosabban Atomot), és minden egyes oldalon elmondják, hogy kell authentikálni a Google Accounts-szal (mintha a többi Google rendszernél nem lenne ledokumentálva amúgyis.) A szabványt (formátumot, sémát) viszont odadobják két pre tag közé, már ahol egyáltalán ezt megteszik (lásd: Activities data API) és jobbára csak hivatkoznak más Google adatformátumokra. Ez engem leginkább a Microsoft OOXML-politikájára emlékeztet, persze itt csak simán trehányság.

A másik csúnya rész: bár hagyományosan a code.google.com a Google nyílt forráskódú projektjeit tartalmazza, sehol nem látom a Javascript függvénykönyvtár forráskódját az oldalon. Miért lenne ez fontos? Feltételezve, hogy bármelyik magyar social network csatlakozni akarna a kezdeményezéshez, előbb vissza kéne fejtenie a Google minden bizonnyal tömörített változatát. Arról nem is beszélve, hogy bár a Gadgetek remek módon értik a Google saját kis XML-jét ( <Require feature=”opensocial-0.5″/>), azért ezt a többi widgetplatformtól ne várjuk el.

Egyszóval: Egy trehány módon dokumentált, teljesen a házon belüli technológiákra épülő “szabvánnyal” van dolgunk.

GYIK

Csatlakozzon-e a Facebook?

Természetesen valószínüleg csatlakozni fog. Az API annyira primitív, hogy egy-két héten belül a facebook platformra rá lehet építeni. Bár nekik valószínűleg hetekbe fog kerülni, mert nagy a cég, és a bürokraták sokat fognak okoskodni, de ténylegesen leprogramozni nem túl sok idő.

A továbbiakban érdemes-e Facebook API-ra fejleszteni? Érdemes-e saját API-t kifejleszteni a saját networkünkhöz?

Nagyon is érdemes!!!A különbséget úgy lehet megfogni, mint a Java Swing megjelenésekor nem szűntek meg a desktop alkalmazások, és a Java után megjelent operációs rendszereknek is rendelkeztek saját API-val.

  • Ki lehet használni a social network saját lehetőségeit (pl. fórumrendszerek)
  • A social networkbe jobban illeszkedő lehetőségeket (pl. dizájnhoz passzoló megoldásokat), könnyebb beilleszthetőséget, magasabb szintű támogatást (pl. <mp3> tag az fbml-ben) adhat
  • Facebook esetén van natív code library PHP-hez, .NET-hez, Java-hoz és máshoz is
  • Az OpenSocial-t a közös nevező elv miatt könnyebb implementálni utólag
  • Az OpenSocial API jelenlegi formájában a világ legtrehányabb szabványainak egyike

Amikor kijött a Facebook API, egy ideig csodálkoztam az XML-jein (ami a TechCrunch értesüléseivel ellentétben nem kötelező, csak melegen ajánlott - arrafelé az iframe-et hekkelésnek tartják), aztán amikor mi is elkezdtünk alkalmazásintegrációs felületeken dolgozni, rájöttünk, mennyire elegáns és szép megoldás, csodáltuk is őket érte.

Viszont a kezdetektől ott volt az API-t támogató proxy üzleti logika más platformokhoz - valószínűleg ez a legjobb ötletük volt a szeletelt kenyér óta.

Hogy készítsek API-t?

A facebook-ról úgy láttuk egy-másfél hónap elemzés után, hogy a facebook alkalmazásait eleve FBML-ben írták meg, még az API-nyitás előtt (a saját taglibrary-k használata nem ismeretlen fogalom, főként a Java Enterprise (Java Server Faces), illetve az ASP.NET világában), amivel konzisztens kinézetet tudtak biztosítani az appoknak. Ezután kiválasztották azokat az üzleti rétegben lévő funkciókat, amiket érdemesnek tartottak megnyitásra, és írtak egy authentikációs / authorizációs réteget fölé, amit aztán különböző protokollokon keresztül elérhetővé tettek. Ehhez már csak ráadásként jöttek azok a függvénykönyvtárak, amik ezt a réteget eltakarták, és így gyakorlatilag éppolyan kényelmesen lehetett külső alkalmazásokat fejleszteni, mint belsőket.

Szóval valami ilyesmi. Ehhez persze jól képzett, hozzáértő programozók, információmérnökök kellenek. De vacakkal nehéz lesz ezen a túlzsúfolt piacon megélni.