Na to pytanie odpowiedź jest dość mętna i można by ją sformuować tak: „bardzo byśmy chcieli żeby był, ale jeszcze nie w najbliższej przyszłości”. Na osnews jest fajny fragmencik odnoszący się do wywiadu z quentinem clarkiem – managerem projektu WinFS. Wywiad wyrywkowo przeczytałem i wnioski są właśnie takie, że emes chciał za dużo na raz. Technologie wymyślone podczas projektowania WinFS można odnaleźć w SQL2oo8 oraz ADO.NET i te technologie i ich rozwój pozwoli dopiero zbudować fundamenty do dalszego myślenia o rozwoju WinFS. Ciekawe tylko, że winFS zapowiadany był w 2ooo roq … no może 2oo2 a SQL 2k8 prawdziwą premierę będzie miał na jesieni (nie mylę się? chyba jest beta nadal). Niezła obsuwa.
A wszystko imho z dwóch powodów – po pierwsze za dużo na raz, po drugie – system plików jest obiektowy a baza relacyjna (FUJ!). System, który próbowali zrobić był (jest?) relacyjno-obiektowy. Przekoncypowane. Do tego realnie działa to nie na zasadzie standardowego systemu plików a raczej sytemu plików wspieranego do-nieprzytomności-rozbudowaną-usługą indexującą – bo zasada była taka – NTFS+relacje przechowywane w bazie. Nie podoba mi się to już z idei.
Najśmiejszy jest fakt, że w przeszłości już taki system istniał – BFS z BeOsa działał na takiej właśnie zasadzie i najprawdopodobniej na nim oparta była idea WinFS. Polecam lekturę (oj długa, ale w wolnej chwili fajnie sobie przejrzeć) historii systemów operacyjnych (i nie tylko – polecam poczytać kto-z-kim-jak-dla-czego-i-po-co).
A mi wystarczyłyby takie ficzery:
- nagłówek pliq jako oddzielny rekord (plik=nagłówek+data+pola dodatkowe znane z wielu protokołów). To pozowliłoby zrezygnować z jednego z najgłupszych pomysłów jakie powstały wraz z windowsem – czyli utworzenie relacji (TFU!) rozszeżenie pliq->aplikacja. W większości systemów operacyjnych aplikacja jest wyliczana na podstawie typu nagłówka co daje większą elastyczność i bezpieczeństwo (nazwy są wyłącznie wizualizacją dla użytkownika a nie podstawą decyzyjną dla systemu)
- rezygnacja z modelu katalog/plik na rzecz keywords/rekord – to imho dość logiczne. Przy modelu katalog/plik plik jest traktowany jako jedna całość podczas, gdy można go podzielić i traktować jak rekord.. czy też raczej jako obiekt, którego jednym z atrybutów jest np. BODY (binaria). Ciekaw jestem czy dożyje przejścia świata na bazy obiektowe… nie zapowiada się niestety – światek baz danych utknął w średniowieczu przypominając mi SteamFantasy – przyszłość, w której techlonogia zamiast w kierunq elektryczności rozwinęła technologię opartą na silnikach parowych q:
Do każdego pliq można zdefiniować keywordsy – co realizuje wiele opcji nadal – zastępstwo symlinków/junktion, łatwość katalogowania/sortowania – te same dane zależnie od zapytania zostaną zwrócone dla konkretnego słowa kluczowego. - dodajmu do tego indexowawnie po treści (nazw nie ma… może być ew. atrybut 'description’), bo łatwo sobie teraz wyobrazić zapytanie „wyszukaj obiektów typu mail ze słowem 'aaa’ w atrybucie body”. Załączniki trzymane jako oddzielne obiekty (realizacja SIS).. ehhh
niby mało a tak wiele – najwyraźniej nie jest to proste skoro nikt tego nie zrobił, chociaż moja teoria spisq jest taka, że wynika to z przyzwyczajeń myślowych bo nawet w relacyjnych bazach daje się to zrobić q:
Nie rozumiem na czym polega ten problem styq „data conteiner” którymi są od lat bazy danych a obsługą pliq. Przecież wymodelować bazę odpowiadającą np. NTFSowi można choćby w MySQL bo jego budowa jest dość trywialna, a więc problem zawęża się do napisania sterownika, który będzie pobierał dane z bazy…
Może kiedyś zrozumiem…
