Google Lively

Bez większego entuzjazmu zainstalowałem sobie Google Lively. Bo obawiałem się że mi to nie pójdzie. Po drugie dość już naoglądałem się czatów 3D. W tej sytuacji postanowiłem śledzić jak mi to wszystko pójdzie. Plik instalacyjny wylądował mi w C:\Program Files\Google\Update\Download\{635EAF17-43BA-4D5A-A1C9-87C580F6AA02}
a instalacja przebiegała tak cicho, że dopiero potem zreflektowałem się że mam już to zainstalowane w
C:\Program Files\Google\Lively Zajrzałem do tego folderu
Był tam katalog flex z plikami *.swf odpowiedzialnymi za interfejs użytkownika. Folder datafiles zawierał tajemnicze pliki *.nif (są to pliki z silnika Gamebryo).
Zauważyłem, że Google Lively wymaga obsługi DirectX na co wskazywała obecność pliku d3dx9_27.dll Za GUI we Lively odpowiadała biblioteka f_in_box.dll firmy Softanic. Ta biblioteka ma własną stronę. W tej sytuacji zajrzałem do API tej biblioteki. Zrozumiałem że komunikacja ze stroną WWW może odbywać się tak kod JS -> API Plugina -> API F-in-Box.
Najciekawsze jest to, że do Lively dodano silnik pozwalający na obsługę gadgetów Google GadgetEngineRedist.dll

Gdy wybrałem pierwszy lepszy pokój, pomyślałem że sprawdzę logi i pojawiło się coś takiego
User-Agent: Fiji Client (gzip)
A natomiast serwery Google przedstawiały sie jako "GFE/1.3" lub po zalogowaniu "3dweb storage server". I zauważyłem, że większość operacji na Lively dokonuje sie z poziomu REST (a pliki SWF ładowane są ukrywane przed użytkownikiem, to taka cecha biblioteki f-in-box.dll)

Po zalogowaniu zauważyłem, że sporo danych leci ode mnie nawet podanie hasła na loginie nie jest bezpieczne, bo nie jest wysyłane przez HTTPS. Ilość danych jakie leciała do mnie przekroczyła ponad 2000 żądań i przesłała mi same skompresowane pliki, aż zablokowało mi przeglądarkę.

Wszedłem do swojego pustego pokoju. Zobaczyłem w logach: http://clients3.google.com/lively/s/gp?id=-8618462218026787199&obj_ed=0 i zrozumiałem że pobrałem plik binarny mojego pustego pokoju. Jeden z kolejnych logów był taki:
http://clients3.google.com/lively/s/gpmd?id=-9193953186449112932&obj_ed=0 co prawdopodobnie były pliki binarne przedmiotów w pokoju.
Ale to co mnie zaskoczyło to fakt że gdzieś informacja o moim awatarze jest zapisana lokalnie o czym świadczył mały plik http://clients3.google.com/lively/s/ga. Następnie zacząłem przeglądać swoje ustawienia. A rzeczy do ustawień ładują się spod takiego adresu:
http://clients3.google.com/lively/s/gpss?id=9214425981265137557&obj_ed=0.

Na koniec kliknąłem prawym przyciskiem na awatara i wybrałem sobie animację, którą ma awatar zrobić, Warto protestować sobie animacje takie jak rofl czy tada. Jak wyczułem w tym produkcie to że "duchem" bardziej przemawia to na rynek azjatycki. Nie ma co się dziwić jak za tym projektem stoi uzdolniona programistka Niniane Wang Byłem już pod wrażeniem tej Chinki, że nie miałem ochoty już sprawdzać co jest w tych plikach SWF.

Indeksowanie SWF w wyszukiwarkach

Interesujący temat ostatnio, czyli sezon ogórkowy. Adobe ogłosiło że razem z Google i Yahoo pozwoli na indeksowanie zawartości tekstowej plików SWF9 (wcześniejsze formaty były indeksowane). Myślę, że tworzenie plików SWF podlegających indeksowaniu to temat rzadko poruszany. Mam własne przemyślenia na ten temat:

• Od umieszczania zawartości tekstowej były metatagi w formacie SWF, a takze zawartość testowa osadzana w polu tekstowym. Jest to jedyny sposób na trafienie w wynikach Google
• Obecne zawartość tekstowa w plikach SWF to śmieci. - wystarczy dopisać filetype:swf
  

Jak sprawić żeby zawartość plików SWF nie była "koszmarem"? Należy zrobić pliki SWF z pełna zawartością tekstową bez formatowania. A formatowanie zawartości pozostawić skryptom Action Script i plikom CSS. W ten sposób unikniemy indeksowania takiej zawartości typu: font face="Tahoma" size="12" color="#ffffff" letterSpacing="-0.100000" kerning="0"

W przypadku gdy mamy na stronie zawartość pliku SWF tworzonego przy pomocy Flex/Haxe to trzeba dodać bardzo dokładnie opisujące. A nawet jest to jest opisane w dokumentacji

Kolejna sprawa to pewien paradoks tkwiący w tym że, Adobe powinno było stworzyć rozwiązanie dzięki któremu wyszukiwarki "odsiewały" plewy od ziarna. Ta technologia już była: nazywa się FlashPaper. Nawet można już ładnie wyszukać pliki z dokumentami FlashPaper

Pozostaje teraz dość interesująca sytuacja dzięki temu że powstają konwertery online na format SWF w takich usługach jak Media Convert, ale to nie ułatwia sprawy, jeżeli chodzi o indeksowanie plików SWF , bo aplikacje RIA coraz bardziej przypominają aplikacje Ajax. A te wymagają stworzenia właściwej interakcji pomiędzy treścią na stronie WWW, a nawigacją w aplikacji AJAX/RIA.

Idealna sytuacja to taka w której serwis został tak zaprojektowany że na każdy "widok" aplikacji odpowiada odpowiedni dokument FlashPaper, który zresztą może zostać załadowany "wewnątrz" aplikacji RIA. W ten sposób załatwiamy prawie wszystkie bolączki aplikacji RIA:

• Google ładnie indeksuje pliki SWF z FlashPapera
• Użytkownik otrzymuje dokument SWF przystosowany do druku
• Prawie wszędzie można odczytać dokumenty FlashPapera (nawet w FlashLite)
• Pliki z FlashPaper są przyjazne screenreaderom
• po "shackowaniu" API FlashPaper jest możliwa komunikacja z innymi aplikacjami RIA/Ajax