tuxcmd-dev-vfs

[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

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

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

On Sun, 2004-02-15 at 08:45, Radek Cervinka wrote:

> jaky je z pohledu programu rozdil mezi vylistovanim archivu a vylistova=
nim
> adresare na ftp? Podle mne se to schovat pod jedno rozhrani



Rozdil tam nebude skoro zadny, bude se pouzivat stejne VFS API, ale
rozdil bude v tom, jak se to bude volat (nekde z menu/tlacitka/klavesove
zkratky - pricemz by se mel objevit asi nejakej Site Manager), taky v
tom, ze asi budou vyskakovat nejake okynka (treba s heslem) a taky bych
chtel, aby u FTP byl videt nekde log (idealne zadokovany v hlavnim okne
nad/pod panelama). Tyhle veci u archivu pravdepodobne nebudou.


> > Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaven=
i -=20
> > dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit=20
> > chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru)=
.=20
> 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=
.

Tohle bych zatim neresil, dodelat se to da vzdycky, ale to predavani
parametru do pluginu bude asi nejlepsi...


> > Moje predstava o implementaci do programu je skrz menu Plugins, kde b=
y=20
> > kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about =
a=20
> > svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to=
=20
> > mrknout, pod linxuem to nejede :(
>=20
> To je snad zalezitosti toho programu a ne VFS?



To bylo jen pro inspiraci :)
Ale zas bych chtel, aby v programu nebyly prebytecne kusy kodu patrici k
pluginum, pokud tam nebudou - proto jsem chtel ty formulare nacpat do
pluginu. Jak jsem jiz psal, tohle bych zatim neresil, v prvni fazi
stejne musime zprovoznit zakladni archivy.


> ja nekdy pozivam call back funkci, kde se pri inicializaci predava poin=
ter=20
> na logovaci funkci, a pak se vola jen tato, a co si s tim hlavni progra=
m=20
> udela, to uz je jedno


Logovani ja zatim resim vypsanim textu primo na konzoli (writeln), ale
tohle je dobrej napad, to bysme mohli udelat (pokud uz to neni primo v
tom tvym VFS API).


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



Jo, u rpm se to docela hodi, mc to ma taky tak reseni, ale v tar-gz/bz2
nic takoveho neni, jenom jeden soubor.
Nevim jak je na tom deb, asi podobne, ja pouzivam gentoo takze vsechny
tyhle problemy se mne netykaji ;-)


> Za tim to vcelku odpovida VFS Seksi commanderu :), jen neco pridat, nec=
o=20
> ubrat :)

No, a to jsme jeste nezacali probirat primo definice funkci - to bude
druhy krok az s timhle budeme vsihni souhlasit.


----
Tom=E1=B9 B=BEatek

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

[<bla...@se...>]

Omouvam se za zpozdeni, nebot jsem byl tri dny v praci :-(

> 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

Nejlepe asi pres writeln()

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

To by bylo moudre, nicmene v tomto jsem jeste dost veci
neprekousl. Nepodarilo se mi rozchodit ani mount() pres libc. Budto
to nefunguje nebo jsem to nepochopil, tak jsem zvolil cestu
nejmensiho odporu pres externi prikaz(docasne).

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

Ja bych to vynechal uplne a nastaveni resil nejako pres API. Grafickeho 
by tam podle me nemelo byt nic, prave kvuli teto rozdilnosti pouzitych
toolkitu.

>
> 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 :(
>
Implementaci do programu bych nechal na kazdem, at si to udela po svem. 
User vubec nemusi vedet, ze tam nejaky plugin ma a podle
me ho to ani moc nezajima. Hlavne ze tam ta funkce je....
Informace o pluginu bych pak vypisoval pres prikaz 
program --help-nazev_pluginu.

> Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste 
> dohodnout presne na tom API.
> Ocekavam od vas komentare :)

taky uff... Jdu si koupit tlusty knihy....

> ----
> Tomáš Bžatek
>
Jiri Blahovsky

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

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

On Tue, 2004-02-17 at 08:53, Ji=F8=ED Blahovsk=FD wrote:

> Omouvam se za zpozdeni, nebot jsem byl tri dny v praci :-(

OK, kazdy dela neco, ma ruzne cas; me ted treba vyhodili ze skoly...


> > Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka=20
> > .so), napsany s presne definovanym API. Pluginy by se mely natahovat=20
> > pri startu programu, kazdy plugin by mel obsahovat funkce, ktere=20
> > nejakym zpusobem vrati moznosti pluginu
>=20
> Nejlepe asi pres writeln()



? Trochu se vytratil smysl, ale jestli to je k tomu logovani, tak by
bylo asi nejlepsi pres nejakou funkci ktera se preda pluginu jako
parametr pri inicializaci - jak uz tady bylo receno. Kazdy si pak tu
logovaci funkci implementuje sam, treba ten writeln;


> To by bylo moudre, nicmene v tomto jsem jeste dost veci
> neprekousl. Nepodarilo se mi rozchodit ani mount() pres libc. Budto
> to nefunguje nebo jsem to nepochopil, tak jsem zvolil cestu
> nejmensiho odporu pres externi prikaz(docasne).



K tomu mountovani: man 2 mount: "Only the super-user may mount and
unmount filesystems."
Ja uz jsem svuj mounter taky vyresil volanim externiho prikazu...


> Ja bych to vynechal uplne a nastaveni resil nejako pres API. Grafickeho=
=20
> by tam podle me nemelo byt nic, prave kvuli teto rozdilnosti pouzitych
> toolkitu.


OK, domluveno.


> Implementaci do programu bych nechal na kazdem, at si to udela po svem.=
=20
> User vubec nemusi vedet, ze tam nejaky plugin ma a podle
> me ho to ani moc nezajima. Hlavne ze tam ta funkce je....
> Informace o pluginu bych pak vypisoval pres prikaz=20
> program --help-nazev_pluginu.


To je docela zajimave, kazdopadne bych tam asi dal nejakou funkci ktera
bude vracet retezec, aby se daly z kazdeho pluginu zobrazit nejaky
informace - about a tak... ;)


Takze tim padem pokud uz nikdo nic nema k tehle zevrubne strukture, asi
zacnu psat cast 2. primo s navrhem API.

----
Tom=E1=B9 B=BEatek