Re: [Tuxcmd-dev-vfs] Koncepce VFS - cast 2.

[Radek C. <rad...@ce...>]

>>/No jdes na to trochu zhurta./
>>
> No vsak jo, jenom jsem to sepsal jake funkce potrebuju...

OK

>>/Jen nejdulezitejsi informace:
>>1)
>>****
>>Kopirovani bude stylem
>>a) rekni modulu ze chces soubor a kam ho chces (z kama apod)
>>nebo
>>b) chci prvnich 4kb ze souboru, pak dalsi atd.
>>
>>Podle mne se priklanis k za b). Proc? Podle mne je to zalezitosti
>>modulu. Nehlede ze nektere soubory (virtualni) nemusi mit
>>descriptory atd.
>>Fakt si myslim za trochu abstrakce nezaskodi. Nac to tak pitvat?/
>>
> Hm... ja mam v programu v podstate obe dve koncepce, ale pro kopirovani 
> pouzivam a). Proto ta implementace sendfile, coz je na lokalnim FS 
> volani libc. Nechtel bych, aby se soubor zkopiroval cely na jedno volani 
> funkce, mel by se taky nekde updatnou nejaky progress bar. Sendfile taky 
> pracuje navic po blocich.

To je lepsi resit callbackem, tj nejakou funkci typu

TCallBack=Function ( iPos:Int64; iMax:Int64):Boolean; //cdecl;

no a tu funkce bude implementovana nekde v hlavnim programu,
a kdyz ten modul uzna za vhodne ze by v ramci kodovani mohl
oznamit nejakej progress tak ji jen zavola.
Asi by se predavalo pri volani.

function VFSCopyOut(pCallBackProgress:TCallback; const sSrcName, 
sDstName:String):TVFSResult;

Navic tim ze je to fce muzu udelat to, ze nastavenim
result na false muzu kopirovani abortnout :).
tj. v moudulu

begin
   while not oef(konec souboru) do
   begin
     kopiruj davku
     if not pCallbackProgress( iZkopirovano, iCelkem) then
     begin
       // sakra uzivatel to abortoval
     end;
   end;

   end;




> Ty funkce co tam byly (read, write, seek, open, close) tam nejsou kvuli 
> kopirovani, ale pro prime cteni dat (nepravidelne; random access). Napr. 
> i pro interni prohlizec by se to dalo pouzit.

Vis jak tezko se to bude implementovat?
Predstav si, ze je to nejaky archiv, ktery ma nejaky tabulky (jako pro 
kompresi), tj. pokud budu chtit dejme tomu  50 byte, tak budu muset mit
ulozen slovnik z predchozich 49 byte (nebo je projit), nebo ho znova vytvorit.
Pak prijde pozadavek na byte 100-150, takze budu muset projit zase 
podelanych prvnich 99 byte. Vysledek > pomale, pomale, zabira to pamet,
bude se to tezko psat (hlavne u sekvencnich archivu aka rar, kde pro
x soubor musis projit x-1 predchozich).


> Dalsi problem vidim v tom, pokud se bude kopirovat z jednoho pluginu do 
> druhyho. V takovym pripade musi zdrojovy plugin dekodovat data, vratit 
> ukazatel na pamet s urcitym blokem dat a pak cilovy plugin by mel ty 
> data enkodovat a zapsat podle sveho. Jinak to asi nepude (doufam).

no porozmyslej. ja bych to udelal pres nejaky temp (kdyz uz uzivatel chce 
takovou prasarnu) :)


>>/>     function VFSRun(const sName:String):TVFSResult;
>>
>>no treba jsem mel pro nektere moduly i virtualni soubory
>>(treba pro RPM, kde jich bylo nekolik a mezi nimi i
>>spustitelny install a unistall:),
>>no a ono se hodi vubec nekdy treba spustit neco  z archivu
>>(pokud to ma clovek asociovane))/
>>
> Spoustet primo nejake aplikace bez predchoziho ulozeni na disk asi nejde 
> (nebo mozna jo, ale nevim o tom), 


> Total Commander to taky dela tak, ze 
> si prvni rozbali ten soubor (prip. cely archiv) nekam do tmp a pak to 
> pusti. Vpodstate staci operace kopirovani, spusteni si uz ohlida 
> filemanager (aspon tak to mam teda namysleno), takze neni potreba zadne 
> funkce VFSRun.

nepochopil, nepochopil :)

Takze znovu. Nejlepe na RPM (coz jak jiste vis, jsou balicky pro redhat, 
MDK, Suse atd). Ekvivalentem je DEB pro Debian. (promin ze tak obsirne, vim 
ze to vis, ale presto).

plugin pro rpm vylistuje obsah RPM a pridaval tam virtualne nekolik souboru
- jeden obsahoval seznam souboru, dalsi info o baliku, dalsi a ted pozor
pridal virtualni soubory (tedy neexistujici) install a unistall (a oznacil 
je jako spustitelne).
Protoze je uzivatel liny a nechce se mu psat rpm -ibalik.rpm, tak
po klepnuti na install se zavolalo VFSRun s parametrem install
a plugin toto zjistit a provedl odpovidajici akci, tedy
rpm -ibalik.rpm.

Kdybys to vykopiroval tak ti houby pomuze, neb ten soubor je ciste 
virtualni a VFS ho virtualizuje.


Da se to vyuzit jen v nekolika malo pripadech, ale ty jsou veskrze cool.
Jsem vsemi 10 pro to aby to tam bylo. Vetsina modulu to nemusi podporovat
(a pro to je tam to VFSCaps nebo jak se to jmenuje).


>>/>     function VFSList(const sDir:String; iItemID:Integer; var VFSItem:TVFSItem ):TVFSResult;
>>
>>no to je kombinace tech tvych tri volani v jednom/
>>
> OK a to iItemID je tam na co?

no to by mel byt ten index, tedy pro prvni zaznam je to 0, pro druhy je to
1., to sDir melo puvodne myslenku, ale uz si ji nejsem tak jist.

tedy:
VFSList vrati celej obsah archivu (A), nebo jen pro jeden level (B) (bez 
podaresaru). Ja jsem puvodne myslel tu variantu (B) a proto tam bylo to sDir.

Obe maji sve pro a proti.
varianta (B) je jednudussi pro hlavni program
varianta (A) je jednodussi a ruchlejsi pro plugin.
Problem u A je ze ho nemusi celej znat (napr. pro FTP)

Takze jsem pro B.

> Kvuli tomu je to potreba dukladne promyslet...
No ja kdyz jsem to navrhoval tak uz jsem par jinych
programu vytvoril (a treba s tim tread safe to byla bolestna zkusenost).
Kdysi jsem o tom psal na root.cz celej clanek.

Jeste mne napadlo:

Opet situace: uzivatel chce vykopirovat nekolik souboru z archivu.

Stavajici navrh by postupne pro jednotlive soubory volal treba CopyOut
nebo neco jineho, kazdopadne to znamena ze by se archiv prochazel vzdy 
znovu (coz jak jsem rekl u seqvencnich archivu je docela otrava).

Lepsi by bylo nasypat pozadovane soubory a pak rict: ted je vykopiruj,
vymaz, vkopiruj atd.

To jen tak :).

Radek