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

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

Byla spatne nastavena hlavicka Reply-To v mailing listu, ted uz by to
melo byt vporadku, omlouvam se, takze preposilam mail od Radka ktery by
mel byt spravne v mailinglistu.

-----Forwarded Message-----

From: Radek Cervinka <rad...@ce...>
To: sou...@bz...
Subject: Re: [Tuxcmd-dev-vfs] Koncepce VFS - cast 1.
Date: Sun, 15 Feb 2004 08:45:12 +0100

Tomas Bzatek wrote:
> 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
>   - tedy hlavne co to je za typ pluginu (jestli archivovy, nebo nejaky 
> browser - treba FTP, SMB atd...)
jaky je z pohledu programu rozdil mezi vylistovanim archivu a vylistovanim
adresare na ftp? Podle mne se to schovat pod jedno rozhrani

>   - registrovane pripony (pokud je to archivovy)
Ja
>   - ktere operace se s nim daji provadet/ktere jsou implementovany 
> (vetsina pluginu bude zpocatku read-only, nebudou mit nektere funkce).

Ja

> 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.

souhlasim, i kdyz sem na to nenarazil

> 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). 
Ja si nemylim, ze by ta konfigurace byla nezbytna, kazdopadne by se to dalo
resit v ramci programu a pak vysledek predat pouze pres API do plugginu.


> 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.
Ja bych fakt GUI do totho netahal, ve vysledku by to melo spoustu problemu.

> 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 :(

To je snad zalezitosti toho programu a ne VFS?

> 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.

a naopak

> - 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).

ja nekdy pozivam call back funkci, kde se pri inicializaci predava pointer 
na logovaci funkci, a pak se vola jen tato, a co si s tim hlavni program 
udela, to uz je jedno

> - 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)

me se treba u rpm libi, kdyz se muzu podivat jen "dovnitr" tj. na informace
nebo kdyz si muzu rozbalit jen jeden soubor

> 
> Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste dohodnout 
> presne na tom API.
Za tim to vcelku odpovida VFS Seksi commanderu :), jen neco pridat, neco 
ubrat :)

Radek