Tervezzünk API-t (úgyis minden adatbázis alapon)
2003-05-01T21:50:08+02:00
2005-01-15T16:28:59+01:00
2022-07-19T06:44:04+02:00
  • Azt hiszem, tényleg kezd feleslegessé válni ez a vita. Valószínűleg senki sem tudja meggyőzni a másikat, úgyhogy én a következőt ajánlom: vita helyett próbáld meg elkészíteni a "prototípusát" ennek a csodadolognak, lehet, hogy én is megpróbálkozom vele, aztán majd kiderül, működik-e.
    Mutasd a teljes hozzászólást!
  • Gondolkodom magam is eleget a tervem szükségességéről


    Nálam ez (a szükségességről való gondolkodás) jelzi, hogy hamarosan megunom az épp aktuális "projekt"-et, és valami más kezd majd el foglalkoztatni.

    Ez viszont itt egy programozó fórum, ha nem értesz a dologhoz


    Nézd meg a profilomat: sok mindenből egy-egy kicsi. Semmi szakosodás, ami a szakértőket jellemzi, vagy sok mindenből nagy pontszám, ami a polihisztorokat.

    elgondolkodtatni már sokkal kevésbé


    Hát igen, nehéz műfaj az internetes kommunikáció. A néhány sorban jól fogalmazáshoz nagyobb tehetség kell, mint néhány perces beszélgetés során kifejteni gondolatokat.
    Mutasd a teljes hozzászólást!
  • Aham, értem. Nekem nem nagyon jön be ez a stílus. A mókuskerék-dolog, így ismeretlenben, meg sért is. Gondolkodom magam is eleget a tervem szükségességéről (meg más dolgokról is). Ez viszont itt egy programozó fórum, ha nem értesz a dologhoz csak kötekedni tudsz, elgondolkodtatni már sokkal kevésbé.
    Mutasd a teljes hozzászólást!
  • Anti.spam, bocs, de nem látszol hajlandónak (alkalmasnak) arra hogy a valódi kérdésről vitatkozzunk.


    Igen, ez igaz. Vitatkozás helyett a kizökkentést céloztam meg, hátha sikerül valamelyest kizökkentenem téged a láthatólag jól bejáratott (mókus)kerékvágatból.

    Megnyugtatásul annyit, hogy még én se nőttem ki a tiédhez hasonló gondolatokat, én cimkézett gráfokon törtem a fejem, és még nem adtam fel.

    Úgyhogy csak előre, az idealista álmodozók igenis megváltoztathatják a világot! Ha meg nem, akkor is jól érezzük magunkat eközben, nemde?
    Mutasd a teljes hozzászólást!
  • És mi az LDAP és az IMAP szemály-rendszereiben való eltérés?


    Most jutott eszembe: IMAP szerver tetszőleges tartalmú leveleket képes tárolni. Nem gond, ha egy levélbe egy másik levél van beágyazva, aminek mondjuk van egy "application/x-enprogramom" melléklete.

    Egy LDAP szerver azonban csak olyan attribútumokat hajlandó tárolni, amik a sémájában a bejegyzés típusához vannak rendelve, előre le vannak írva. Nem lehet olyat csinálni, hogy akkor én most ide beillesztek egy akármilyen attribútumot vagy albejegyzést.

    IMAP szerverrel nem lehet egy levél részletét módosíttatni, mert akkor az már egy másik levél lenne. LDAP szerverrel viszont minden további nélkül lehet módosíttatni egy bejegyzés attribútumát, mert az attól még ugyan arra az objektumra vonatkozik. Pld ha költözés miatt át kell írni valakinek a lakcímét.
    Mutasd a teljes hozzászólást!
  • Anti.spam, bocs, de nem látszol hajlandónak (alkalmasnak) arra hogy a valódi kérdésről vitatkozzunk. Jól elszórakozhatunk, érdekeseket filozófálgathatunk, csak nekem ez teljesen céltalannak tűnik a témával kapcsolatban. Viszlát.
    Mutasd a teljes hozzászólást!
  • És mi az LDAP és az IMAP szemály-rendszereiben való eltérés? Ezt is kifejthetnéd...


    Mi a különbség a német meg az olasz nyelv között? Végülis minden, mert egymással nem felcserélhetőek anélkül, hogy bárki észre ne venné. Végülis semmi, mert mindkettő "csak" egy természetes nyelv, így ugyan arra a célra alkalmazzák őket.
    Mutasd a teljes hozzászólást!
  • Az IMAP is csak a mondanivalónk
    "bizonyos attribútumait"
    tárolja, magát a mondanivalót nem, mint ahogy az LDAP-ban sem húsvér embereket tárolok. Ha törlök egy levelet, nem törlöm a mondanivalót. De ez inkább filozófiai vita, ami ide magas (máshol jó). Semmi köze a technikai megvalósításhoz.

    Informatikai értelemben tehát szerintem pusztán emiatt nem tér el az IMAP és az LDAP. Az IMAP levél is csak egy objektum az LDAP fáján. A levél tartalma is csak egy atribútum. És mi az LDAP és az IMAP szemály-rendszereiben való eltérés? Ezt is kifejthetnéd...
    Mutasd a teljes hozzászólást!
  • Melyik több több szemantikailag mint táblák/mezők/relációk manipulálása?


    Hát igen, bitek manipulálásán kívül egyetlen számítógép sem képes semmi másra. Vagy mégis? És ha igen, akkor mitől/hogyan? (--> szabályrendszerek, és egyéb korlátozások)
    Mutasd a teljes hozzászólást!
  • az IMAP és az LDAP [...] szemantikailag sem tér el


    Egy LDAP szerver nem objektumokat tárol, hanem csak objektumok bizonyos attribútumait.

    Egy IMAP szerver viszont elektronikus levél objektumok összes attribútumát, ezzel magukat a vonatkozott objektumokat is tárolja.

    Ha kitörlök egy levelet, akkor megsemmisítek egy objektumot. Ha kitörlök egy LDAP bejegyzést, semmi sem történik azokkal az objektumokkal, amikre a bejegyzés vonatkozozott.

    Hiszen ha a szemantika nem része a protokollnak, akkor annak sokfélesége nem is "érinti" a protokollt. Azt azon kívül kell leírni.


    Email-ben mindent le lehet írni, SMTP-vel meg mindent el lehet küldeni. Úgyhogy elég lenne ez az egy, csak legyen elég gyors.
    Mutasd a teljes hozzászólást!
  • ...akkor a szintaktika egységessége elhanyagolható mértékben könnyíti az implementálás folyamatát.
    Ezzel nagyon-nagyon nem értek egyet, tapasztalból is. Itt főleg nem összetett üzleti logikát megvalósító protokollokról van szó, hanem közhasznú, RFC-kben leírtakról. Melyek szemantikája néhol alig-alig eltérő (IMAP/LDAP...).

    Mesélj már egy kicsit az egyes szolgáltatások egyedi előnyeiről - monjuk 20 Internetes protokoll keretében - melyik az mely igazán egyedi. Vagy csak az IMAP/LDAP-on keresztül. Melyik az melynek (valamelyik szolgáltatása) egyedisége igazán szükségessé teszi létét. Melyik több több szemantikailag mint táblák/mezők/relációk manipulálása?

    a SOAP, annál "jobb" egységes protokollt úgysem
    A SOAP-nak van néhány alaphibája, az egyik pld. az egyirányú HTTP-re való utaltság. A kliens-szerver szerepek rég elavultak. Nincs lehetőség a "kliens" megszólítására, események fogadására, stb. A másik tipikus hibája egy külső leírónyelv (WSDL) használata a szolgáltatások leírásához. Pont az alap API hiányzik belőle, hogy az elérhető szolgáltatások külső segítség nélkül megismerhetőek legyenek. Jó is lenne ha egy SQL adatbáziskezelő eléréséhez egy külön fájlban leírt táblaleírásokat kellene használni. És így tovább. Sokkal jobbat lehet alkotni, mégha nem is fog mindent lefedni.
    Mutasd a teljes hozzászólást!
  • Ha elfogadod, hogy a protokollok nem viszik át a szemantikát akkor ezután illogikus következtetés, hogy pont emiatt lenne szükség sokféle protokollra. Hiszen ha a szemantika nem része a protokollnak, akkor annak sokfélesége nem is "érinti" a protokollt. Azt azon kívül kell leírni.

    Ha úgyis a szemantika különböző, tehát külön kell implementálnunk a különböző "szemantikák" feldolgozását, akkor a szintaktika egységessége elhanyagolható mértékben könnyíti az implementálás folyamatát.
    Ha pedig mégis csak valamilyen szintű egységességre vágysz, akkor nem értem, miért nem elég neked a SOAP, annál "jobb" egységes protokollt úgysem tudsz teremteni a különböző szolgáltatások egyedi előnyeiről való lemondás nélkül.
    Mutasd a teljes hozzászólást!
  • A tanulás a tanuló képességének, eddíg megszerzett alaptudásának és munkájának is az eredménye, nemcsak a tanár sikerességének függvénye. Egyébként még mindig érdemes lenne elolvasnod az IMAP és az LDAP dokumentációját, s akkor láthatnád hogy pont ez a kettő szemantikailag sem tér el. (Csak a levél = objektum azonosságot kell elfogadni.) A tanuláshoz tudás is kell.

    Amúgy haladunk: Ha elfogadod, hogy a protokollok nem viszik át a szemantikát akkor ezután illogikus következtetés, hogy pont emiatt lenne szükség sokféle protokollra. Hiszen ha a szemantika nem része a protokollnak, akkor annak sokfélesége nem is "érinti" a protokollt. Azt azon kívül kell leírni.
    Mutasd a teljes hozzászólást!
  • Bocs, de én értek a dologhoz.


    Bocs, de ezt csak akkor fogadom el, ha olyasmit írsz amiből tanulni lehet. Vélemény kinyilvánításból meg ugyabár nem lehet tanulni.

    csak az átvitt adatok sémájában térnek el


    Szerintem a "séma" az egy részletkérdés a szemantikához képest. Mivel a szemantikát semmilyen protokoll sem viszi át, viszont sokféle szemantikára van szükség a gyakorlatban, ezért sokféle különböző protokollal kell a sokféle különböző szemantikát kifejezni. Mert máshogy (egyenlőre?) nem lehet.
    Mutasd a teljes hozzászólást!
  • Bocs, de én értek a dologhoz. Viszont kedvem már nincs győzködni téged. Nézz utána egy kicsit a dolgoknak, mielőtt.

    A semmitmondó általánosságot tényleg jobban kifejthettem volna. A lényeg hogy csak az átvitt adatok sémájában térnek el az egyes alkalmazási területek (protokollok). Mind fejlesztői, mind felhasználói oldalrol sok változna. Jóéjt.
    Mutasd a teljes hozzászólást!
  • Utánanéztem, és ezt találtam:

    SOAP Version 1.2 Part 0: Primer

    SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information.


    SOAP Version 1.2 is a simple messaging framework for transferring information specified in the form of an XML infoset between an initial SOAP sender and an ultimate SOAP receiver.
    Mutasd a teljes hozzászólást!
  • Viszont a nem-járatosság ...


    Nem gond. Legfelljebb jön valaki aki tényleg ért a dologhoz, és elmondja, hogy az adott témakörben ez így-és-így van, nem pedig úgy, ahogy én véltem. Az érvekből tanulhatok. Ha meg nem jön senki, akkor meg úgyis mindegy, nem?

    szerintem nem egységes API, hanem inkább egy infrastruktúra (vagy csak formátum?)


    Szerintem "transzport metódus".

    De már ígyis nagy előrelépés lenne ha ezen az alapon működne a ...


    Felhasználói oldalról nézve nem változna ettől semmi. Vagy igen?

    Programozói oldalról nézve változna valami, de egyáltalán nem világos, hogy az előnyére vagy a hátrányára?

    Az XML-ben legalább az a felismerés megvan hogy minden alkalmazás főképp adatok kommunikációjára épül.


    Semmitmondó általánosság.
    Mutasd a teljes hozzászólást!
  • anti.spam: Viszont a nem-járatosság mondhatnám előrevetíti az irreleváns kritikát, aláássa a hiteledet, főképp egy járatosságra alapozott feltevéssel szemben.

    simi.2: Az XML/SOAP (a web szolgáltatásosdi) szerintem nem egységes API, hanem inkább egy infrastruktúra (vagy csak formátum?), melyen keresztül - már megintcsak - egyedi API-kat (formátumokat?) lehet létrehozni. De már ígyis nagy előrelépés lenne ha ezen az alapon működne a levélfeladás, küldés, címtárazás stb. Az XML-ben legalább az a felismerés megvan hogy minden alkalmazás főképp adatok kommunikációjára épül.
    Mutasd a teljes hozzászólást!
  • Igaziból ha csak egységes API kell, akkor miért nem jó az XML/SOAP? Tök egységes: a kérésben XML formában megy el hogy mit szeretnél csinálni, a válaszban XML formában jön meg az eredmény. Levélre, user directoryra, adatelérésre, mindenre jó.
    Mutasd a teljes hozzászólást!
  • Te tiszta lüke vagy.


    Dícséretnek veszem

    Egyáltalán ismered a két protokollt alaposan?


    Nem, de ez engem nem késztet arra, hogy teljesen egyformának lássam őket. Mint ahogy arra sem, hogy teljesen különbözőknek.

    Mert ez kell ahhoz hogy értelmes véleményt alkothass...


    Nem hiszem. Egy hibás vélekedést nyilván nem az tesz hibássá, hogy a véleményt kinyilvánító mennyire járatos az adott témakörben, hanem a témakör maga. Következésképp a vélemény kritikáját nem a véleményt kinyilvánító személy tulajdonságaira, hanem a témakör tulajdonságaira kell(ene) alapozni.
    Mutasd a teljes hozzászólást!
  • Te tiszta lüke vagy. Mókás kötekedéssel sehová sem jutsz. Nyilván nem a te "egyesítő" megoldásodra gondoltam, ez még messze nem lenne Q.E.D. Egyáltalán ismered a két protokollt alaposan? Mert ez kell ahhoz hogy értelmes véleményt alkothass...
    Mutasd a teljes hozzászólást!
  • Hogy mi az amiért mindenképpen 2 protokoll kell az általuk ellátott két feladatra?


    Végülis is egy protokoll is elég: kliens csatlakozik szerverhez, aztán az első parancs az, hogy "IMAP", vagy "LDAP" innentől kezdve pedig megy minden a régi kerékvágásban. Egy új protokol? Igen. Mindkét feladatra alkalmas? Igen. Q.E.D.
    Mutasd a teljes hozzászólást!
  • Leírnátok mi az alapvető (!) különbség például az IMAP és az LDAP között?


    Úgy rémlik, hogy alapvetően mindkettő szöveges, kérés-válasz kommunikáción alapul. A kliens "aktív", mert a kliens dönti el mikor milyen kérést küld a szervernek; a szerver pedig "passzív" csak akkor küld, ha kértek tőle valamit.

    Az imap azonban lehetőséget ad arra, hogy bizonyos körülmények között a kliens és a szerver "szerepet cseréljen", a kliens váljék "passzívvá", a szerver pedig "aktívvá". Legalábbis eszerint az RFC szerint: ftp://ftp.rfc-editor.org/in-notes/rfc2177.txt

    Nem tudom az LDAP-nál van-e ilyen, hogy a szerver bizonyos változásokról kérés nélkül is értesíti a klienseket. Ha nincs, akkor ez egy alapvető eltérés.

    Más: az IMAP-nál van lehetőség részinformáció lekérésére. Pld megszakad a kapcsolat, és akkor folytatod a kis 10megás leveled letöltését ott, ahol abbamaradt. Az LDAP-nál szerintem ilyen nincs. Pld lekérni egy levélcímet, de a 10. karaktertől kezdődően.

    De a legalapvetőbb különbség közöttük az, hogy más célra tervezték, és fogadták(!) el őket. Mertugyebár mindkettő eléggé elterjedt ahhoz, hogy elfogadottnak nevezhessük őket.
    Mutasd a teljes hozzászólást!
  • Szánj már rá pár percet, gondolkodj el, s válaszolj a kérdésre az IMAP/LDAP ügyben. Hogy mi az amiért mindenképpen 2 protokoll kell az általuk ellátott két feladatra?
    Mutasd a teljes hozzászólást!
  • Inkább meg kell valósítanom azt, amiről papolok itt.


    Nincs ezzel gond, csináld nyugodtan. Lesz egy "1001. egzotikus API", aminek a használata a legrosszabb esetben nem terjed el.
    Mutasd a teljes hozzászólást!
  • Jó jó higgadjunk le. Leírnátok mi az alapvető (!) különbség például az IMAP és az LDAP között? Konkrétan. Miért szükséges az hogy két külön protokoll lássa el ezt a feladatot? Mikor sok programban szerepel együtt a használatuk? Miért ne lenne pölö az LDAP arra képes hogy leveleket (objektumokként) tároljon a fájában? Ugyanazokat a keresési, módosítási, törlési mintákat használják...

    Amúgy vicces érzés lökött és megnemértett tudósnak, Giordano Bruno-nak érezni magam. Inkább meg kell valósítanom azt, amiről papolok itt. Szeptembertől remélem úgyis egyetemista leszek.
    Mutasd a teljes hozzászólást!
  • A protokollok csak azért térnek el, mert minden egyes adatszerkezethez különbőzőt alkottak.


    Vágásra a motoros fűrész a legjobb. Azzal jó sok mindent el lehet vágni. Annyira fura nekem, hogy ez a virágkertészeknek nem esik le...


    Sokféle környezet (feladat, probléma, stb), sokféle megoldás. És ez így van jól.
    Mutasd a teljes hozzászólást!
  • Mindegyik listákba szervezett, tulajdonságokkal rendeklező elemek listáját kezeli (listázza, szűri, törlis, stb. - ala adatbáziskezelés). Ezt kell meglátni. Ilyen szinten általánosíthatóak. Nem mindegy a protokoll szempojntjából hogy egy levél subject-jét egy ember címét, telefonszámát vagy egy fájl tartalmát viszi
    éppen át?

    A protokollok csak azért térnek el, mert minden egyes adatszerkezethez különbőzőt alkottak. Annyira fura nekem, hogy ez sokaknak nem esik le...
    Mutasd a teljes hozzászólást!
  • A felsorolt protokollokat egészen más programok használják, és egészen más adatok nyerhetők ki velünk. Pl. teljesen más a formátuma mondjuk egy HTML dokumentumnak, mint egy e-mailnek, és mindkettő még jobba különbözik az LDAP által visszaadott adatoktól. Nem várható el, hogy egy szoftver kezelje az összeset - ha pedig úgyis külön le kell programozni a szolgáltatások elérését, akkor meg minek egységes API?
    Ezzel nem azt akarom mondani, hogy rossz ötlet az "egységes" API ötlete, csak szvsz egy kissé reálisabb formába kéne önteni.
    Mutasd a teljes hozzászólást!
  • Tudom, és mondták is. Mondanál példákat is? Meg nem is akarok mindent lefedni, csak sokat. Mintaképpen számtalan internetes protokoll (POP, SMTP, IMAP, LDAP, FTP) helyettesíthető egyel. Ez még OK?
    Mutasd a teljes hozzászólást!
abcd