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
|
