care credeti ca e viitorul programarii (cu cine ati vota?)

[Adi[CG]]

Originally Posted by KLAMATH

Ori discutam de SOA ori despre web services !!
SOA != ws. SOA ar vrea sa fie un "superset"
al webservicesurilor. Daca wsurile au adus interop
intre "sisteme" folosind wsdl, http si soap, SOA ar trebui
sa faca acest lucru la o scara mai mare permitindu-ti sa
alegi tu "protocolul de transport" si modul in care
datele sint "transmise".Insa..well..ideea e... CU CE ajuta discutiei
despre SOA exemplul tau cu webserviceurile ?
Ar ajuta daca as scrie si eu din amintirile mele....
cind foloseam DCOM (yeah...Windows DNA ) in
distributed apps ?

Nu ajuta, pentru ca in timp ce exemplul meu este un caz particular desigur limitat si "pervers" (daca vrei) de SOA, DCOM nu numai ca nu este SOA dar va fi kiluit de MSFT in viitorul apropiat. Sigur, ca prezinta un interes istoric, arheologic poate.

Originally Posted by KLAMATH

Dar sa zicem ca avem o implementare care foloseste UDP sockets.
In acest caz ce inseamna pentru tine "context de autorizare" ?
Si, tinind seama ca ai putea avea SOAP over *whatever* si ca,
in cazul in care *whatever* nu are context (udp sockets),
cum rezolvi tu problema fara a face totul stateless ?
Exemplu concret...ai un web service la care trebuie sa existe autentification.
WSul urmeaza sa fie folosit de un numar FOARTE mare de utilizatori asa ca RBS
e exclus. Cum faci autentificarea ?

Este vorba de context _la nivel de aplicatie_. Cu riscul de a ma repeta, web services nu inseamna doar o metoda speriata care asteapta infrigurata s-o apeleze utilizatorul X. Web services poate sa insemne o mare haita de astfel de metode PESTE o aplicatie legacy stateful pana in maduva oaselor, metode care trebuie apelate intr-o anume ordine si cu o anume logica in spate daca vrei sa obtii ceva coerent. Sunt multe cazuri in care visul cu serviciul monolitic, marea metoda stateless care face tot este - da - doar un vis Nu stiu la ce te referi prin "RBS" ... dar depinzand de ce inseamna FOARTE mare si de nivelul de securitate urmarit, se pot aplica diferite strategii. Dar, ce pot sa-ti spun este ca daca astepti milioane de useri ori esti foarte optimist, ori esti Microsoft .

Originally Posted by KLAMATH

Deci toata discutia era despre SOA/viitor (btw legat de Indigo si alpha...mda..macar in .NET exista Indigo care va face SOA o realitate. In J2EE ce exista ?). In mijlocul acestei discutii , repet...despre SOA si viitor, tu te apuci sa dansezi cu tehnologiile (din prezent...yeah..ws rulezz..right ?!)

Acu' pe bune nu stiu cum sa-ti explic eu mai bine : eu nu dansez, imi castig painea. Iar "viitorul" Indigo vs Indigo mi se pare nu foarte apropiat, poate ca nu am fost foarte clar. In rest sigur ca J2EE fiind conceput la o data anterioara (cum zic fetele de la administrativ) nu beneficiaza de o viziune unitara si o implementare nativa SOA. Dar exista implementari Java proprietar SOA-compliant (cele mai notabile BEA si IBM) bazate pe web services (SOAP si dynamic discovery cu WSDL), intarite cu MQM-ul de rigoare pentru aplicatiile complexe cu volumetrie mare de mesaje. In J2EE 1.4 implementarea de referinta de la Sun contine JAX-RPC 1.1 pentru creare si consum de web services si suport pentru WS-I Basic Profile 1.0.

Originally Posted by KLAMATH

Folosesti Shadowfax AZI ?

Clar ca nu.

Originally Posted by KLAMATH

Ai luat din context chestia cu "stupid toolkits that nobody
heard of.."(SPUNE-MI ca ai inteles la ce ma refeream cind am scris asta !!!!) si
apoi refulezi cu Longhorn. Congratz dude...ce sa zic. M-ai spart.

Asa e, incerc sa te destabilizez cu argumente perverse. N-ar trebui sa te mire daca ai citit threadul de fata. Be afraid, be very afraid

Hai bafta

[Adi[CG]]

Originally Posted by KLAMATH

1. Atita timp cit are....
2. Addins, addins, addins. Si pe deasupra si macrouri. Tot cu gheara din dotare.
3. Eh...atita timp cit e "payware".

Argumentatia ta e recursiva. Raspunsul la punctul 3 se incaleca la punctul 1. So ?

Originally Posted by KLAMATH

"Rich Client Platform care nu prea are echivalent in lumea MSFT (poate si pentru ca nu a existat o nevoie pregnanta, but anyway) "
Muhahha...ai nevoie de o denumire penibila ca sa "demonstrezi" superioritatea unui IDE ? Nu ma pot lasa mai prejos asa ca-ti arunc si eu un "Smart Client. Evident ca astea n-au nici o legatura cu ideul in sine....dar daca trebuie....trebuie.

You are bullshitting me, right ? Sunt totusi doua chestii diferite...

Originally Posted by KLAMATH

"suportul serios pentru AOP (altfel, concept inventat de un ex-Microsoftist) si faptul ca este intr-adevar un IDE nascut din necesitatile dezvoltatorilor. Si nu e bullshit."
Fii sincer....de cite ori ai folosit tu dude AOP in proiectele tale ?

Eu personal nu dar un baiat (mai destept) cu care lucrez acu in echipa foloseste AOP pentru a crea dinamic tranzactii pe niste apeluri de servicii. Adica, unele servicii doar citesc datele si-atunci nu merita sa te pozitionezi intr-o tranzactie (tranzactie Hibernate), altele le mai si modifica si-atunci e frumos sa faci un "begin" la inceput si un "commit" sau "rollback" la sfarsit. Pentru a declansa tranzactia se foloseste un tag xdoclet in documentatia clasei care se scrie undeva intr-o lista de atribute citita la runtime. Deci, da, se poate spune ca am folosit (via proxy ).

Originally Posted by KLAMATH

Java zealot in plina desfasurare a fortelor. Poti sa trimiti bug reports, sa sugerezi features/improuvments daca esti MSFT client.

Compara USER Eclipse <-> CLIENT Microsoft. Compara FREE <-> MSDN $$$. Sesizezi vreo diferenta ?

Originally Posted by KLAMATH

Citi programatori C++, C#, Perl, Python, Eiffel ai vazut ca folosesc porcaria aia ?!!

Perl si Python 1 : eu si sunt foarte multumit In rest nu ma pot pronunta...

Originally Posted by KLAMATH

Uita-te la VS.NET : VC++, VC#, VB.NET, Perl.NET, Eiffel.NET etc. Toate cu suport out of the box, debugger cu suport pt cod nativ + tsql, + managed code, gui builders. etc.

Ce sa spun, ma uimesti ca vs net ofera suport pentru cod nativ, tsql, managed code si windows gui builder ? Wheew... dar ia stai, nu e oarecum firesc ? In afara de managed code, nu cumva am mai vazut asta si acum un numar de anisori ? Inovatie, cineva ? Alo, Redmond, se aude acolo jos ? [Desigur o sa fiu pleznit nemilos cu Whidbey, Whitehorse & co ]

Originally Posted by KLAMATH

Poti sa folosesti COM components fara nici o pb din .NET . Incluzind COM+ ES. In acceasi ordine de idei...SUN mai suporta JVM 1.1 ?

Fake. Te asigur ca portarea din VB in VB.net e un ordin de magnitudine mai complicata decat din 1.1 in 1.4. Dar stiai asta, ma asteptam la un argument mai suculent In ceea ce priveste viitorul COM, ca ACUM poti inca folosi COM din .Net stiu. Intrebarea e ce surprize ne rezerva nenea Wronghorn, daca tot vorbeam de viitor ...

[aaroman]

Exact...si in CLR/JVM de asta se ocupa GCul. Nu ai sesizat asta pina acum ?

In unele cazuri se ocupa prea tarziu E ca si cum nu s-ar ocupa.

Evident ca le face. Ideea era, de ex daca deschizi o conexiune de o baza de date sau un stream,
sa nu astepti, in acest caz, sa-ti inchida GCul conexiunea ci sa o faci chiar tu. Closeul il pui in finally.

1. Evident ca le face, dar prea tarziu, in multe cazuri. Daca trebuie s-o faci tu explicit, degeaba o face.
2. Close il pui in finally, deci trebuie sa ai niste instructiuni in plus pe acolo, nu-i asa? Si close, si try/finally...

Hehehe...si daca obj nu e declarat la nivelul clasei.Daca, de ex, ai Clasa X cu metoda Y. In metoda Y deschizi un stream. Nu trebuie sa chemi close ianinte
de return ?

Nu!
void method(){
fstream o("out.txt");
o<<"bla";
}

Sau vrei asa:
void method(){
SmartPtr<fstream> s(new fstream("out.txt"));
*s << "bla";
}

Sau poate preferi ceva la nivel mai coborat:
void method()
{
shared_ptr<FILE> p(fopen("out.txt","a+"),fclose);
//and so on
}

Dude aici e vorba de tot UI APIul Windowsului. De ce, de ex, Swingul nu extinde AWTului ? Sau SWTul Swingul ?!

Intrebarea asta s-o pui alora care au dezvoltat Java

E vorba de 2 chestii distincte cu mari diferente intre ele care au acelasi scop.

Citeste cu atentie ce-ai scris

DE CE ai vrea
ca al 2 sa fie on top la primul ?

De ce nu?

Bloat blaot bloat bloat...

Te referi aici la chestiile Microsoft & Sun? Ai dreptate in acest caz

Ai nevoie de WinForms...folosesti win forms.
Ai nevoie de Longhorn only UI folosesti Avalon. "It's that simple."

Si daca n-ai nevoie de nici una?

Dar, desigur, nu ma indoiesc ca tu stii mai bine decit tipii de la MS care au luat hotarirea asta...

Apelul la autoritate?

OK...atunci....ce nu iti place la modul in care au evoluat ADO/ADO.NET din RDO/DAO?

Ai uitat oledb
Prea multe nivele intermediare. Prea multe schimbari intr-un interval foarte mic de timp. Portabilitate 0. Overhead 1000% Standarde nestandard Timp de viata mult prea redus pentru aplicatii cat de cat serioase. Mai vrei?

[Adi[CG]]

haha !

"* The magnitude of this hack compares favorably with that of the national debt."
citat din private\ntos\w32\ntuser\client\nt6\user.h, programator Microsoft anonim

Ref http://www.kuro5hin.org/story/2004/2/15/71552/7795

[Zircon]

Pe de alta parte MS a iesit atat de bine din furcile caudine ale respectivului articol incat incep sa ma intreb daca nu cumva ei au fost cei care au scapat "din greseala" sursele respective

[Bass-ty]

alexb: intuitia ta ar putea fi corecta in cazul asta......dar nu cred ca se va mediatiza foarte tare cazul in continuare.....deci e greu de aflat!

[Adi[CG]]

Totusi nu sunt numai tampiti la msft... Cunosc personal 3 angajati acolo cu care am fost coleg pe la various gigs. Culmea e ca omul care in '94 mi-a explicat cum se instaleaza Linux si cum se configureaza si compileaza un kernel (eu fiind la vremea respectiva un electronist "sapator de santuri" cf. Aaroman) e acum angajat la msft
Ca sa rezum, nu ma mira ca se produce la ei si destul cod de calitate. Problema mare a msft e strategia de produse & marketing (worse is better, extend&embrace, vendor lock, standarde inchise & co). Ca sa nu mai vorbim ca o firma care are 80% profit operational pe 2 divizii (os & office) pute a overpriced de la mare distanta. Iar cand miliardele cu pricina sunt folosite ca sa strangi concurenta de bile, sa cumperi startup-uri promitatoare pe care sa le bagi in frigider si sa investesti in dezvoltarea unor standarde cu specificatii inchise ...

[aaroman]

nu ma mira ca se produce la ei si destul cod de calitate

E suficient sa arunci o privire peste ATL si-o sa-ti dai seama de asta. Nici mfc, asa hulit cum e, nu e chiar asa de catastrofal, tinand cont de vechimea lui (ideea e suficient de buna sa fie adoptata si de cei care au creat wxWindows, de unde similitudinile evidente intre cele doua).
Insa sincer sa fiu, am vazut si cod Microsoft scris ca porcu', de obicei in sample-uri. Probabil acolo pun programatori mai putin talentati, ca au fost cazuri in care a trebuit sa modific codul numai ca sa poata fi compilat Ce sa mai vorbim de erori care nu sunt prinse la compilare

[Adi[CG]]

Sample-uri
Ce, ai vrea sa nu mai vanda suport, training & stuff ?
Sunt f rare produsele cu sample-uri decente ...

[KLAMATH]

"Nu ajuta, pentru ca in timp ce exemplul meu este un caz particular desigur limitat si "pervers"
(daca vrei) de SOA, DCOM nu numai ca nu este SOA dar va fi kiluit de MSFT in viitorul apropiat.
Sigur, ca prezinta un interes istoric, arheologic poate."

Mdea...dupa cum am spus deja poti sa folosesti ES din .NET. Deci poti
migra DCOM in .NET. Si apoi, fara modificari, in Indigo. Deci nu
e chiar interes arheologic.


"Este vorba de context _la nivel de aplicatie_."
I give up. Chiar nu-mi dau seama la ce te referi.
Ai pomenit de treaba cu orchestrarea. Asta e specifica
fiecarui proiect..Stii ca virgula ca sa obtii treaba X
folosesti metoda Z a clasei Y . Rezultatul il pasezi
metodei N al clasei C. Apoi mai departe metoda G a clasei E. Getting dizzy..ha ?
Dar aici era vorba de conceptele SOA. Iar orchestrarea
NU e un concept SOA. Orchestrarea o poate face
orcine care e familiarizat cu proiectul respectiv.

" Cu riscul de a ma repeta, web services nu inseamna doar o metoda speriata care asteapta infrigurata s-o apeleze utilizatorul X."
Din pct de vedere al celui care consuma serviciul (sau care il expune) TOCMAI asta inseamna. Vezi tu dude...e doar RPC over HTTP. Nu e EJB, RMI, .NET Remoting , [insert distibuted obj arhitecture here].
E doar o metoda pe care tu O APELEZI. ATIT !!

" Web services poate sa insemne o mare haita de astfel de metode PESTE o aplicatie legacy stateful pana in maduva oaselor,
metode care trebuie apelate intr-o anume ordine si cu o anume logica in spate daca vrei sa obtii ceva coerent. Sunt multe cazuri in care visul cu serviciul monolitic,
marea metoda stateless care face tot este - da - doar un vis"

Da...si ? La fel de bine poate sa fie un select in db care returneaza direct rezultatul. Daca
ai tu o tona de legacy crap peste care infigi wsul....DE CE M-AR interesa asta ? In marea
majoritate a cazurilor e doar unul/mai multe calluri in BL. Vezi servicul X ? Apelezi metoda X. Vrei
serviciul Y ? Apelezi metoda Y. Toate metodele fiind grupate sub denumirea Z.


" Nu stiu la ce te referi prin "RBS" "
Scuze pt acronim. RBS = Role Based Security.

"... dar depinzand de ce inseamna FOARTE mare si de nivelul de securitate urmarit,
se pot aplica diferite strategii. "
Such as...


"Dar, ce pot sa-ti spun este ca daca astepti milioane de useri ori esti foarte optimist,
ori esti Microsoft ."
Sa nu spunem milioane...in jur de 10000, de ex.



"Acu' pe bune nu stiu cum sa-ti explic eu mai bine : eu nu dansez, imi castig painea.
Iar "viitorul" Indigo vs Indigo mi se pare nu foarte apropiat,
poate ca nu am fost foarte clar. In rest sigur ca J2EE fiind conceput la o data anterioara
(cum zic fetele de la administrativ) nu beneficiaza de o viziune unitara si o implementare
nativa SOA. Dar exista implementari Java proprietar SOA-compliant (cele mai notabile BEA si IBM)
bazate pe web services (SOAP si dynamic discovery cu WSDL),
intarite cu MQM-ul de rigoare pentru aplicatiile complexe cu volumetrie mare de mesaje.
In J2EE 1.4 implementarea de referinta de la Sun contine JAX-RPC 1.1 pentru creare si
consum de web services si suport pentru WS-I Basic Profile 1.0."

Nu e de ajuns. Ca sa nu mai vorbim ca ACUM NU exista 100% interop intre wsurile
create cu diferitele implementari J2EE. Yeah....IBM ownz them all...dar ce te faci cu restul ?
Doar WS-I Basic Profile ? Microsoft si IBM implementeaza TOATE standardele WS.
Deci 100 interop poate fi obtinuta DOAR intre .NET si WebSphere. MS publica APIul care
va face SOA o realitate in .NET si cu vii cu...MQM si JAX-RPC 1.1. Muhahhahahhah...


"Argumentatia ta e recursiva. Raspunsul la punctul 3 se incaleca la punctul 1. So ?"
No. Gasesti addinuri VS.NET pentru refractoring gratuite.

"You are bullshitting me, right ? Sunt totusi doua chestii diferite..."
Dar totusi nici una nu are legatura cu IDEul.Intr-o discutie despre IDEuri tu
aduci ca argument chestia cu "Rich Client Platform". So....


"Eu personal nu dar un baiat (mai destept) cu care lucrez acu in echipa foloseste
AOP pentru a crea dinamic tranzactii pe niste apeluri de servicii.
Adica, unele servicii doar citesc datele si-atunci nu merita sa
te pozitionezi intr-o tranzactie (tranzactie Hibernate), altele le mai si modifica
si-atunci e frumos sa faci un "begin" la inceput si un "commit" sau "rollback" la sfarsit.
Pentru a declansa tranzactia se foloseste un tag xdoclet in documentatia clasei care
se scrie undeva intr-o lista de atribute citita la runtime. Deci, da, se poate spune ca
am folosit (via proxy )."
Asta suna mai mult a interception. Anyway...ideea e...cum te ajuta IDEul cu asta ca
sa poata fi considerata un + ?


"Compara USER Eclipse <-> CLIENT Microsoft. Compara FREE <-> MSDN $$$. Sesizezi vreo diferenta ?"
Comparam IDEurile pe merite tehnice sau Eclipse e mai bun doar pt ca e free ?


"Perl si Python 1 : eu si sunt foarte multumit In rest nu ma pot pronunta..."
Genial argument. Me myself and I...


"Ce sa spun, ma uimesti ca vs net ofera suport pentru cod nativ, tsql,
managed code si windows gui builder ? Wheew... dar ia stai, nu e oarecum firesc ?
In afara de managed code, nu cumva am mai vazut asta si acum un numar de anisori
? Inovatie, cineva ? Alo, Redmond, se aude acolo jos ? [Desigur o sa fiu pleznit
nemilos cu Whidbey, Whitehorse & co ]"

Evident ca e firesc. E nefirec ca Eclipse sa aiba un amarit de syntax highlight
pt limbajul X si sa spuna..."suportam limbajul X". De fapt...scuze...asta nu e nefiresc. E penibil..
In plus...lol...inovatia. (cuvintul magic regurgitat de orcine care discuta despre un produs MS).
Ce INOVATII aduce Eclipse !!!! VS.NETul macar are chestiile enumerate
mai sus out of the box. Si, folosind .NET framework, poti sa develop un proiect in mai multe limbaje . In Java....te apuci sa bagi value types in arrays ca sa le poti pasa by reference.
Apoi viteza...muhaha...VS.NET 2K# (VC++,C#,VB.NET, Crystal Reports, Active Reports + o droaie de addinuri) e mult
mai rapid decit Eclipse "highlight java code syntax" IDE. In plus debuggerul.....compara debuggerul VS.NEtului
cu ala din Eclipse !!!! Sau code editorul din VS.NET....


"Fake. Te asigur ca portarea din VB in VB.net e un ordin de magnitudine mai complicata
decat din 1.1 in 1.4. Dar stiai asta, ma asteptam la un argument mai suculent In ceea ce priveste viitorul COM. COM, ca ACUM poti inca folosi COM din .Net stiu"
Life sucks and then you die. Cam asa e si cu VB6....
Despre COM....orice devine deprecated dupa un anumit timp*. (*cough* AWT *cough*) Deh..nothing lasts forever.
Folosesti COM cit ai nevoie si.....move on.


*singura exceptie e COBOL.

[KLAMATH]

"In unele cazuri se ocupa prea tarziu E ca si cum nu s-ar ocupa."
Live and learn. in .NET poti sa invoci GCul. Daca creezi multe obiecte
si vezi sa le "distrugi" imediat nu ai decit sa GC.Collect(); Diferenta
e ca NU stai sa delete dupa fiecare individual. In Java n-am idee daca se poate...



1. Evident ca le face, dar prea tarziu, in multe cazuri. Daca trebuie s-o faci tu explicit, degeaba o face.
LOL...pai daca o faci tu explicit nu o mai face el.

2. Close il pui in finally, deci trebuie sa ai niste instructiuni in plus pe acolo, nu-i asa? Si close, si try/finally...
Try si finally oricum le pui.Nu-mi spune...tu esti atit de meserias incit nici nu mai folosesti exception handling...


"Nu!
void method(){
fstream o("out.txt");
o<<"bla";
}"

Si se inchide singur ? Nice..


"Intrebarea asta s-o pui alora care au dezvoltat Java"
Da un motiv pentru care ar trebui sa faca asta...



"E vorba de 2 chestii distincte cu mari diferente intre ele care au acelasi scop."

"Citeste cu atentie ce-ai scris".
LOOL.

Quote:
DE CE ai vrea
ca al 2 sa fie on top la primul ?

"De ce nu?"
Asta e argument de genul aluia cu Batman si Superman....


Quote:
Ai nevoie de WinForms...folosesti win forms.
Ai nevoie de Longhorn only UI folosesti Avalon. "It's that simple."

"Si daca n-ai nevoie de nici una?"
Recunoaste.....n-ai avut nimic de spus.Dar ai simtit nevoia sa scrii ceva...


"Apelul la autoritate?"
Bull....DA UN ARGUMENT !! Spune-mi DE CE ar fi mai bine ca sa fie unul peste altul ?



Quote:
OK...atunci....ce nu iti place la modul in care au evoluat ADO/ADO.NET din RDO/DAO?

"Ai uitat oledb". Majoritatea nu se incurcau cu interfetele OLDB (de fapt doar din VC++ puteai
sa le folosesti). Asa ca am pus direct ADO.


"Prea multe schimbari intr-un interval foarte mic de timp."
Nu te obliga nimeni sa codezi pt "the latest and greatest". NU te forteaza MS
sa nu mai folosesti DAO.

"Portabilitate 0."
ADO - ADO.NET. APIul seamana (ai conection , command ).
Poti trece destul de usor de la unul la altul.


" Overhead 1000% "
BULLLLLLLLLLLLLLLSHIT !!!!!
Hai sa-l luam pe ultimul...ADO.NET.
De ex, in cazul Sql Server, Oracle, DB2 (sau orice prov nativ).
Providerul comunica DIRECT cu serverul. Overheadul e FIX 0.


"Timp de viata mult prea redus pentru aplicatii cat de cat serioase."
Huh...daca tu incepi un proiect MARE in DAO....si MS face public ADO.
Tu ce faci ? Lasi totul balta si o iei de la 0 cu ADO ?


"Mai vrei?"
N-ai dat nici un argument convingator. Deci.....baga tare.

[Adi[CG]]

Originally Posted by KLAMATH

I give up. Chiar nu-mi dau seama la ce te referi.
...
Din pct de vedere al celui care consuma serviciul (sau care il expune) TOCMAI asta inseamna. Vezi tu dude...e doar RPC over HTTP. Nu e EJB, RMI, .NET Remoting , [insert distibuted obj arhitecture here].
E doar o metoda pe care tu O APELEZI. ATIT !!

Bun, vorbim de chestii diferite. Eu zic s-o lasam balta...

Originally Posted by KLAMATH

"Dar, ce pot sa-ti spun este ca daca astepti milioane de useri ori esti foarte optimist,
ori esti Microsoft ." Sa nu spunem milioane...in jur de 10000, de ex.

Atunci poti foarte bine sa folosesti sesiuni interne si sa folosesti o tehnica similara cu cea descrisa de mine pt logare si creare de sesiune. Daca lucrezi cu PKI si faci la fiecare apel verificare o sa pierzi prea mult timp (criptarea haleste resurse in prostie).

Originally Posted by KLAMATH

Nu e de ajuns. Ca sa nu mai vorbim ca ACUM NU exista 100% interop intre wsurile
create cu diferitele implementari J2EE. Yeah....IBM ownz them all...dar ce te faci cu restul ?
Doar WS-I Basic Profile ? Microsoft si IBM implementeaza TOATE standardele WS.
Deci 100 interop poate fi obtinuta DOAR intre .NET si WebSphere. MS publica APIul care
va face SOA o realitate in .NET si cu vii cu...MQM si JAX-RPC 1.1. Muhahhahahhah...

Ce pot sa-ti spun e ca folosing tehnologiile astea de muahaha eu am facut bani bunisori acu 2 ani si fac si ACUM. Nu peste 2, nu peste 3 ani. Sigur ca a trebuit sa am grija la ce tipuri de date pasez&co pentru a asigura interoperabilitatea cu API-ul SOAP de C++ de la Borland, dar concluzia este ca se poate si se cer aplicatii de genul asta. Altfel, poate sa publice MSFT 70.000 de api-uri in urmatorii 5 ani, le voi studia cu placere daca voi simti nevoia si le voi aplica in conformitate cu necesitatile reale ale pietii.

Originally Posted by KLAMATH

Dar totusi nici una nu are legatura cu IDEul.Intr-o discutie despre IDEuri tu
aduci ca argument chestia cu "Rich Client Platform". So....

Doar ca RCP da, are legatura cu Eclipse vezi pe eclipse.org

Originally Posted by KLAMATH

Asta suna mai mult a interception. Anyway...ideea e...cum te ajuta IDEul cu asta ca sa poata fi considerata un + ?

Highlight si autocompletion de javadoc via plugin de xdoclet. Integrare cu ant-ul ca sa poti lansa taskul cu pricina cu un singur click. 'nuff said

Originally Posted by KLAMATH

Comparam IDEurile pe merite tehnice sau Eclipse e mai bun doar pt ca e free ?

RCP raport calitate/pret Sigur ca pretul conteaza. Pe de alta parte, daca e un jeg pot sa primesc si bani ca tot nu o sa folosesc.

Originally Posted by KLAMATH

Genial argument. Me myself and I...

Asa sunt eu, egoist. Daca mi-e mie bine sunt f multumit si nu vad care e problema.

Originally Posted by KLAMATH

Evident ca e firesc. E nefirec ca Eclipse sa aiba un amarit de syntax highlight
pt limbajul X si sa spuna..."suportam limbajul X". De fapt...scuze...asta nu e nefiresc. E penibil..
In plus...lol...inovatia. (cuvintul magic regurgitat de orcine care discuta despre un produs MS).

Targetul principal al Eclipse este Java, unde bate la fund cu violenta pe vs net : refactoring, debugging local/remote, content assisting, orice vrei tu si te rog sa nu ma contrazici inainte de a aprofunda. Sigur ca .net-ul are suportul nenumaratelor limbaje suportate mai mult sau mai putin nativ dar sincer ? de cate ori ai scris componente .net in python, perl sau dylan ? In ceea ce priveste suportul C++ in Eclipse acesta include :
* C/C++ Editor (basic functionality, syntax highlighting, code completion etc.)
* C/C++ Debugger (APIs & Default implementation, using GDB)
* C/C++ Launcher (APIs & Default implementation, launches and external application)
* Parser
* Search Engine
* Content Assist Provider
* Makefile generator
Suportul de Python are highliting si content assist inca rudimentar, iar debugging-ul e tristut, via jython. Sa vedem urmatorul release. Suportul de groovy e in lucru (ca si groovy dealtfel) dar va fi mapat pe Java adica fabulos. SQL are highlighting, autocompletion ANSI deocamdata si content assist cu nume de tabele (in jfacedbc). Altele nu ma pasioneaza
Cu viteza, am spus deja ca Eclipse e mai lent si gasesc absolut firesc. Vad ca insisti sa ma convingi. Repet : da, Eclipse e mai lent...

[aaroman]

Live and learn. in .NET poti sa invoci GCul. Daca creezi multe obiecte
si vezi sa le "distrugi" imediat nu ai decit sa GC.Collect(); Diferenta
e ca NU stai sa delete dupa fiecare individual. In Java n-am idee daca se poate...

He he. GC.Collect() ia tot atata timp ca si un simplu delete pentru un obiect? Nu-i cam overkill?

LOL...pai daca o faci tu explicit nu o mai face el.

Unde dai si unde crapa. Si ce daca nu o mai face? Ideea e ca tot mai trebuie sa faci inchiderea explicit...

Close il pui in finally, deci trebuie sa ai niste instructiuni in plus pe acolo, nu-i asa? Si close, si try/finally...

Close apelat explicit nu-i o instructiune? Eu spun ca-i in plus

Try si finally oricum le pui.Nu-mi spune...tu esti atit de meserias incit nici nu mai folosesti exception handling...

Bine mai, da' peste tot? Nu ai nevoie de ele in toate metodele. Uneori doresti sa lasi exceptiile sa ajunga la un alt nivel, unde sa fie tratate

Si o se inchise singur ? Nice..

Asa-i? Poate observi si tu intr-un final ca exista avantaje sa ai controlul asupra momentului in care se distruge un obiect.

Bull....DA UN ARGUMENT !! Spune-mi DE CE ar fi mai bine ca sa fie unul peste altul ?

Din acelasi motiv pentru care exista clasele abstracte/interfetele. Pentru a putea folosi magaria fara a face schimbari in program de cate ori se schimba ceva pe la implementare.
Mi se pare stupid ca pentru a afisa o forma cu un text pe ea, doua butoane si un edit box, sa trebuiasca sa schimbi implementarea programului de cate ori ii creste cornu' (longhornu') lui Microsoft. Daca ar fi definit niste interfete clare de la inceput, si eventual pentru a oferi facilitati suplimentare le extindeau, era ok.
Porcaria e ca Microsoftu' nu schimba nucleul, implementarea, atat de mult precum schimba interfetele. Tehnologiile lor de baze de date nu s-au schimbat chiar asa de mult de-a lungul timpului, cat s-au schimbat modalitatile de acces la date (si Jet, si SqlServer/MSDAC sunt cam tot alea, cu bug fixes si extensii). Nucleul Windows NT-ului nu s-a schimbat in mod atat de radical, cat s-au schimbat interfetele pentru a avea acces la serviciile oferite de OS.
Tehnologii vechi in haine noi?

Recunoaste.....n-ai avut nimic de spus.Dar ai simtit nevoia sa scrii ceva...

Am avut ceva, si trebuia sa te si parafrazez: ai nevoie de dao, folosesti dao (si ce daca-i obvsolete/unsupported, and so on), ai nevoie de ado.net, folosesti ado.net. Bineinteles, daca nu programezi sub Unix, unde degeaba ai nevoie de oricare din cele doua, asa ca mai bine ramai la odbc, ala nu se schimba de doua ori pe zi, si in plus exista si pe Windows, si pe Unix.

"Ai uitat oledb". Majoritatea nu se incurcau cu interfetele OLDB (de fapt doar din VC++ puteai
sa le folosesti). Asa ca am pus direct ADO.

Apelul la traditie? Eu m-am incurcat cu interfetele oledb. Am scris si provider oledb, si de cate ori am de-a face cu "standardul" ms, intre ado si oledb pentru a accesa datele, aleg aproape intotdeauna oledb. Exceptia e la programele extrem de simple, sau atunci cand trebuie sa fac teste...

Nu te obliga nimeni sa codezi pt "the latest and greatest". NU te forteaza MS
sa nu mai folosesti DAO.

Nu, ma anunta ca e obsolete si unsupported, si-mi sugereaza subtil ca pe Longhorn s-ar putea sa nici nu mai functioneze, sau sa functioneze defectuos, sau sa aiba probleme de performanta, si nu-i vina lor, ca ei m-au avertizat, nu-i asa?

ADO - ADO.NET. APIul seamana (ai conection , command ).
Poti trece destul de usor de la unul la altul.

Recordseturi/rowseturi/resultseturi similare ai peste tot (chiar si in DAO & RDO), asta nu inseamna ca "se poate trece usor de la unul la altul". A, si nu-i meritul Microsoft pentru ca sunt similare. Se intampla ca structura bazelor de date sa-i oblige la design-uri asemanatoare. Campuri care apar peste tot, nu-i asa?
Da, un programator poate trece usor de la unul la altul, nu asta era problema. Problema apare la codul deja existent, care trebuie rescris, daca vrei sa-ti mai mearga si in viitor

De ex, in cazul Sql Server, Oracle, DB2 (sau orice prov nativ).
Providerul comunica DIRECT cu serverul. Overheadul e FIX 0.

Vrei sa spui ca o sa obtii aceleasi performante cu Ado.net din C# ca si mine cu OCI din C++? LOL As vrea s-o vad si pe asta...

Huh...daca tu incepi un proiect MARE in DAO....si MS face public ADO.
Tu ce faci ? Lasi totul balta si o iei de la 0 cu ADO ?

Nope. O iau de la 0 peste cativa ani, cand nu mai merge DAO pe Windows, ca i-a crescut cornu' prea lung

[jmf]

Total offtopic, apropo de ODBC, dupa ce am dat peste exceptii gen "Feature not yet implemented" sau "Driver not capable" am renuntat definitiv la el...

[aaroman]

Ce simpatic esti tu Si oledb, ado & ado.net nu sufera de asemenea probleme? Te anunt ca nu toate interfetele sunt "mandatory", asa incat o sa te trezesti cu provideri care fac asa:
return DB_E_NOTSUPPORTED;
sau:
return E_NOTIMPL;
sau (o portiune dintr-un provider oledb pentru interbase/firebird):
HRESULT STDMETHODCALLTYPE CInterBaseSession::Abort(
/* [in] */ BOID * pboidReason,
/* [in] */ BOOL fRetaining,
/* [in] */ BOOL fAsync)
{
CSmartLock sm(&m_cs);

DbgFnTrace("CInterBaseSession::Abort()");

BeginMethod(IID_ITransaction);

if( m_iscTransHandle == NULL ||
m_fAutoCommit == true )
{
return XACT_E_NOTRANSACTION;
}

if( fAsync == TRUE )
{
return XACT_E_NOTSUPPORTED;
}

return InternalAbort( ( fRetaining == TRUE ) );
}

[Zircon]

Adi, foarte buna ideea cu AOP si tranzactiile

Btw, AspectJ este OK sau trebuie sa caut altceva ?

[Adi[CG]]

Aspectj are o foarte buna integrare cu eclipse dar n-as garanta ca e cea mai buna implementare de aop la ora actuala In locul tau m-as uita si pe dynaop-ul asta nou http://weblogs.java.net/pub/wlg/1001 al lui Bob Lee (care a contribuit cu ceva cod si la implementarea celor de la jboss).
DAR : daca e vorba doar de un site si vrei sa-ti simplifici transaction in session, am o solutie mai simpla non-AOP insa Tapestry-specific. Continuam pe PM daca esti interesat...

[Zircon]

Thx.

Deocamdata e o webapp dar soon o sa aiba si rich client stuff Tranzactiile sunt doar prima chestie, am ochit mai multe zone unde ar merge AOP. Oricum, n-am nici un chef sa trec pe tapestry, am facut atatea schimbari in ultima vreme ca am ametit de tot