[Tuxcmd-dev-vfs] Koncepce VFS - cast 1.

[Tomas B. <sou...@bz...>]

Vazeni, ted vam tady napisu moji predstavu o tom, jak by VFS melo
vypadat. Asi to rozdelim do vic casti, prvni spis obecne a pak teprve do
detailu. Rad bych abyste se k tomu vyjadrili, abysme to mohli vsechno
poradne probrat a teprve pak zacali implemntovat.

Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka .so),
napsany s presne definovanym API. Pluginy by se mely natahovat pri
startu programu, kazdy plugin by mel obsahovat funkce, ktere nejakym
zpusobem vrati moznosti pluginu=20
  - tedy hlavne co to je za typ pluginu (jestli archivovy, nebo nejaky
browser - treba FTP, SMB atd...)
  - registrovane pripony (pokud je to archivovy)
  - ktere operace se s nim daji provadet/ktere jsou implementovany
(vetsina pluginu bude zpocatku read-only, nebudou mit nektere funkce).

Bylo by asi nejlepsi, kdyby vsechny funkce v pluginu byly implementovane
primo pomoci kodu nebo volanim nejakych funkci externich knihoven,
rozhodne bych nechtel postavit celej plugin na volani nejakeho programu
(treba tar) - kvuli problemum s tuhnutim forku na ktere jsme uz skoro
kazdy nejakym zpusobem narazili.

Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaveni -
dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit
chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru).
Tady nastava jeden problem a sice nekompatibilita s window toolkitama
(GTK vs. QT) - bud by se to muselo resit nejak abstraktneji nebo
dvojitym kodem (to by bylo pak ale spatne z hlediska udrzby). Tohle bych
prozatim odlozil.

Moje predstava o implementaci do programu je skrz menu Plugins, kde by
kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about a
svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to
mrknout, pod linxuem to nejede :(


Problemy:
 - musi se zajistit API a ABI kompatibilita mezi ruznymi programovacimi
jazyky, takze nepouzivat zadne specialni datove typy a vsechny funkce
oznacovat jako cdecl (to bude asi nejlepsi). Pak muze nekdo vyvijet
plugin v Cecku a normalne ho pouzit v Pascalovskem programu.
 - pokud bude plugin slinkovan (dynamicky) s nejakou dalsi externi
knihovnou, ktera nebude v okamziku natahovani dostupna, tak by bylo
dobre kdyby se nekde vypsalo co tomu presne chybi (soubor). I kdyz tohle
se da vyresit zavolanim ldd... (chcu to hlavne kvuli ladeni).
 - zajimalo by mne, jak se budou resit problemy s dvojitym balenim -
myslim tim tar+gz/tar+bz2 - zpocatku asi nijak, pozdeji by se pri
otevirani archivu provedlo rovnou dvoji rozpakovani - nejlepe bez
zadneho pomocneho souboru (prip. by se to dalo nejak nastavit nebo brat
nejaky limit velikosti archivu)


Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste dohodnout
presne na tom API.
Ocekavam od vas komentare :)
----
Tom=E1=B9 B=BEatek