berkeley je bohužel nepoužitelná kvůli licenci (komerční aplikace)
mozna by si to mohl zvladnout cele s berkeley db, ktera je imho uplne vsude (ale velke imho, vim o tom vice/mene prd)
tak se zdá, že na takovou věc potřebuju KD-tree.
nechci to SQL, protože mi to přijde jako moc overkill. A protože to poběží na nějakém obskurním AIXu, tak nechci vnášet další závislosti na externích knihovnách.
Potřebuju prostě indexovat a vyhledávat v tabulce pomocí více klíčů/položek + něco jako wildcard.
To mimo SQL je nějak zásadní požadavek? A myslíš tím, že chceš non SQL DB a nebo úhyb před nějakou nejmenovanou konkrétní DB?
Hlavně pro všechny svaté sám nic nepiš a použij něco existujícího.
DB má být perzistentní? Vadí single point of failure? Rychlost? Další typy dotazů na data? Embeded, standalone? Atd.
Možností je velmi mnoho, z takto položeného dotazu není možné odpovědět jasně a jednoznačně. Zkus redis, sqllite, berkeley db, ale co já vím, zda ti budou vyhovovat.
embedovane sqllite? pripadne neco dle povahy dat? tokyo cabinet, mongo?
dotaz, c++
pokud byste potřebovali mít v programu databázi a vyhledávat v ní podle více/různých klíčů, co byste použili, mimo SQL?
vysvětlím: mám tabulku
record_id | object1_id | object2_id | action_id
kde record_id je unikátní, object1_id > object2_id, action_id je libovolné
a chci v ní vyhledávat pomocí různých vzájemných kombinací klíčů. Zatím to mám udělané tak, že mám udělané indexy pomocí map/set a různých relací mezi uloženými klíči.
ovšem více by se mi líbilo mít možnost vyhledávat nějakým wildcardem: list.search('*', '*', '*', ACTION_8) → vrátí všechny záznamy, které mají action_id == ACTION_8
(Nakonec když tak o tom uvažuji, není on nakonec vlastně komplet celý JavaScript případ, kdy jeden něco navrhl a ostatní to prostě opsali, protože jim to přišlo jako docela dobrý nápad?)
Aniž bych naznačoval, že bych nad něčím takovým jásal, je to pořád tak nějak
zcela zásadně lepší než vůbec nic (nebo se otravovat s aplety a javským schweinerei).
Nemluvě ani o tom, že případů, kdy jeden něco navrhl a ostatní to prostě opsali, protože jim to přišlo jako docela dobrý nápad, vůbec není málo, a šance, že by toto bylo mezi nimi, je slušná.
Mně se transparentně dešifruje, a to ani nejsem BFU.
pokud rozsiris implementaci, bez predchozi specifikace, kazdy prohlizec si tu udela podle sebe, a tak v jednom prohlizec budes pouzivat WKCertificateStore.ShowSelector, v jinem mozDlgCreate.CertificateSelection, a v ie se zustane u activex (nebo funkcnihop javaapleti). diky nemam zajem.
Nikoliv. Rozsirovat specifikaci je naprosto nepodstatne. Uplne by stacilo rozsirit implementaci. Jednoduse pridat jednu tridu. Opakuji, ze v souvislosti s extensions se trid pridavali MRAKY a nikomu nevadilo, ze ve specifikacich o nich neni ani tuk - proc taky? Jako by nejaky prohlizec jel javascript presne podle specifikace ...
Javascript je jazyk, ktery ma garbage collecting, funkci jako objekt a uzavery. Krome objektoveho programovani podporuje i funkcionalni. Jeste PHP 5.2 muze jenom blednout zavisti. Kdyz k tomu pripoctes spoustu prace kterou predevsim Chrome odvadi na runtime optimalizaci, tak je spis skoda na jak jednoduche ulohy se obvykle pouziva. Ano, javascript neni strongly-typed, coz nektere puristy svadi k nazoru, ze je jednoduchy, protoze jim jeste nedocvaklo, ze kdyz se jazyk nekompiluje (resp. kompiluje se tesne pred spustenim), je zbytecne snazit se na chybu prijit pri kompilaci ...
Jo, meli. Jenze dokud se neprosadi, aby se BFU pri pouziti BFU klienta email transparentne desifroval, tak to nema smysl. A s tim, jak ma kdekdo schranku na gmailu, seznamu a podobnych, to jde spis obracenym smerem ...
k tomu aby js mohl/umel hrabat do uloziste certifikatu by nejdriv nekdo musel tu specifikaci js rozsirit, to ze to mohli udelat uz davno, o tom se nikdo nehada.
js je simple z hlediska funkcionality, coz samozrejme neni na skodu, ale prave proto se nehodi pro slozitejsi a hlavne dost specificke ulohy.
Jo, kolik let tvrdím, že by všechny e-maily měly být šifrované, a kolik let se mi za to smějí nejen BFUs, ale i všelijací MaLérové, co by měli mít mnohem víc rozumu :(
Javascript je nejen turing kompletni jazyk, ale v mnoha ohledech lepsi nez treba PHP. Nejen ze nic nebrani tomu, aby se API browseru pro pristup k certifikatum zpristupnilo pro javascript, dokonce bych se nedivil kdyby zpristupnene BYLO - ovsem nikoliv pro stranky ale pro extension/add-ony (namatkou
tohle vypada, ze se hrabe nekde kolem). Hlavni problemem s tvym pozadavkem tedy neni technicky, ale jednoduse to, ze nikomu se nepovedlo presvedcit vyvojare hlavnich prohlizecu, ze by byl dobry napad se na necem takovem dohodnout.
... ale to prece nejde, to by si treba lidi zacali sifrovat maily a smiraci by meli utrum ...
kdyby nebyl, tak se volaji api browseru pro spravu certifikatu primo z js a nepouzivaji se java applety (nebudes tomu verit, ale kazdy dostupny browser ma nejake api pro pristup k certifikatum a jejich spravu). jenze on se nikdo nerozhodl to api browseru pro js zpristupnit. ostatne, kolik funkci z api browseru muzes v js volat? minimum.
Není, JS je pouze API browseru, a browser to klidně dělat může.