WinFS 2006 == BFS '96
27 Jul 2004
bfs winfs
Apple przy okazji prezentacji swojego Tigera pokazało "nowy" sposób na wyszkukiwanie i kojarzenie informacji: Spotlight. Jest to silnik wyszukujący słowa kluczowe w metadanych. Poza zastosowaniem metadanych różnica względem klasycznych wyszukiwarek polega na tym, że działa on na bieżąco, a nie wyłącznie w chwili szukania.
WinFS, następny, o którym mówi się, że będzie to potrafił, to w rzeczywistości NTFS-owy backend do MS-SQL Servera w wersji Lite. Rozliczne głosy ludzi z wewnątrz dev-teamu i testerów donoszą, że działa on na razie koszmarnie wolno, ale jest jeszcze za wcześnie by wyżywać się "a nie mówiłem", bo do premiery Longhorna dużo może się jeszcze zmienić.
Gnomowy projekt Dashboard prezentuje inne podejście do problemu zarządzania informacją. Dashboard używa XML-owych wrapperów na dane (stąd też pomysł, by wpisy .desktop zastąpić definicjami RDF) w warstwie VFS, a nie surowego systemu plików. Ponad to, Dashboard wydaje się być bardziej dostosowany do klejenia wielu aplikacji działających na podobnych danych niż Windows Future Storage. Ale ale. Dalsze domysły nie mają sensu, bo zarówno Dash i WinFS to ledwo-co-działające bety.
The problems are:
- Metadane muszą być w miarę jednorodne i dobrze napisane. Cóż z tego, że mailer będzie zapisywał w polu From adres w postaci "Edek z Kredek <ed@z.kred>", gdy newsreader zapisze "ed@z.kred". Różnice w samej obsłudze metadanych mogą położyć ideę ich wykorzystania. By do tego nie doszło devele muszą przyswoić jakieś wspólne zasady zawartości konkretnych pól, co pewnie stanie się w kilka lat po epoce totalnego chaosu i niezgodności pomiędzy aplikacjami.
- Źle wprowadzone lub niewprowadzone metadane mogą mylić. Od razu przypomina mi się szukanie muzyki na Audiogalaxy, do bólu: po wykonawcy, po tytule, po pierwszych słowach utworu, po pierwszych słowach + wszystkie możliwe błędy ortograficzne i literówki.
- Metadane nie przenoszą się przez sieć. Czy to w postaci osobnych plików towarzyszących jak RDF czy zaszyte w filesystem. Dzisiejsze protokoły nie radzą sobie z transportem dodatkowego opisu kontentu. No, może wyłączając jakiś nowy pomysł Microsoftu na SMB, o którym jednak jeszcze cicho.
- Metadane nie zawsze są potrzebne. Nie każda fotka na pulpicie musi mieć dokładną metkę ją opisującą, zwłaszcza, że istnieje standard EXIF, który daleko lepiej radzi sobie z zachowaniem szczegółowej informacji niż jakieś protezowane metadane. Podobnie ID3 tag. Oczywiście metadane sprzyjają unifikacji sposobów wyciągania dodatkowej informacji, ale bez przesady - nie ma ich znów tak wiele, by nie można ich było wbudować w VFS. Z resztą, policzmy: EXIF, ID3, fiszki dokumentów "ofisopodobnych", nagłówki e-mail, html <meta/>, czyli na szybko wychodzi mi 5. Powiedzmy, że będzie ich z 15. To nie tak dużo.
BFS, system plików BeOSa, nie Boot File System SCO UnixWare, pozwalał na składowanie dowolnej ilości, typu i objętości atrybutów plików, co realizowało funkcję opisu metedanymi. W przypadku tego systemu rozwiązanie to było o tyle silnie zintegrowane z resztą aplikacji, że był to pierwszy i jedyny natywny system plików BeOSa. Niektóre rozwiązania budziły zachwyt, jak np. książka adresowa, zawierająca pełen opis adresatów w atrybutach, przez co kontent pliku był zawsze pusty, czy pliki e-mail, doskonale poindeksowane przez BeMail, przez co najfajniejszym czytnikiem poczty był filemanager (sic!) zwany Trackerem, umożliwiający utworzenie widoku listy z dowolnymi polami (np. From, Subject, Date, Status, etc.). Dodatkowo Live Querries, czyli "żyjące" wyniki wyszukiwania, zapisywane jako pliki, przedstawiające po ponownym otwarciu aktualną listę znalezionych obiektów bez konieczności ponawiania wyszukiwania (w późniejszych wersjach BeOSa, z uwagi na kiepską wydajność node monitowa w kernelu Live Querries zostały zastąpione zwykłymi zapytaniami odświeżającymi szukanie automatyczne po otwarciu). Co do samego języka wyszukiwarki - były to 3 alternatywne sposoby: 1. klasik - po nazwach plików, 2. język operatorów logicznych i atrybutów, 3. język naturalny za pomocą wizarda, np. "all unread e-mails from Ziuta Zatruta recieved between last sunday and yesterday". Lovely. Zatem, WinFS 2006 == BFS '96. Najs. Tylko dziesięć lat spóźnienia. No cóż, i tak nieźle, skoro nadgonienie X-ów RDP-em zajęło im lat 20..
Hmm, ciekawi mnie, czy mojej dziewczynie spodoba się live cd BeOSa. Szkoda, że ten system nie ma przed sobą szans..
I to tyle tytułem komentarza do coraz-bardziej-offtopicznej dyskusji na 7thGuard.
Update (08 września 2009): O tym samym tylko inaczej piszę również na pcoa w wątku "Historia jak widać się powtarza". Oj powtarza.
- zdzichuBG
No prawie. Spotlight jest odpowiednikiem Beagle, ktory z kolei ma troche wspolnego z GNOME Storage. Dashboard jest tylko aplikacja wyswietlajaca informacje zwiazane z tym, co robimy w danej chwili.
- str()
Ożeszzz, no masz. Oczywiście chodziło mi o Beagle. Dashboard to tylko ilustracja wykorzystania silnika Beagle.
- forges
Dashboard nawiasem mowiac korzysta z protokolu tcp/ip za pomoca którego rederer(gui) komunikuje sie z backend-s(rozne pluginy, np. wspomniany beagle (oparty na nlucene), gaim, xchat, evolution, epiphany itd) przy wykorzystaniu cluepackets (xml).
Sam beagle zbudowany jest w sposób modularny i umożliwia używanie pluginów do indeksowania różnych typów dokumentów (na razie jest to bardzo mała liczba typów), zatem możliwe jest nie tylko przeszukiwanie samych metadanych ale również zawartości plików- str()
Owszem, opis Dashboarda jest całkiem miły i wiele tłumaczy. Jednakże sama koncepcja metadanych już była przerabiana, a ich zastosowanie okazało się conajwyżej sporadycznie przydatne. To, jak wiąże Dashboard informacje dla Gaima, Evolution i jeszcze paru innych programów jest przyjemne, ale środki użyte do osiągnięcia celu są zdecydowanie przesadzone. Wystarczyłoby podrasować GnomeVFS. Tym bardziej przesadzony jest pomysł Microsoftu.