Intel e AMD davanti alla Corte Suprema

Le due rivali di vecchia data si sono fronteggiate ieri davanti ai massimi giudici americani per dirimere una questione vitale, soprattutto perché tocca i problemi europei di Intel


Washington (USA) – Ieri Intel e AMD si sono affrontate di fronte alla Corte Suprema degli Stati Uniti in merito ad una vecchia questione che le contrappone. AMD vorrebbe che si obbligasse l’avversaria a rilasciare della documentazione ritenuta di fondamentale importanza per l’inchiesta antitrust che, dal 2000, l’Unione Europea sta conducendo sul gigante dei chip.

Questo documenti, circa 60.000 pagine, sono stati già esibiti da Intel in una precedente causa con Intergraph ( accomodata proprio di recente ). Per rendere disponibili tali carteggi all’antitrust europeo, AMD chiama in causa una vecchia legge che consente ad un tribunale statunitense di trasmettere la documentazione di un processo ad una corte straniera.

“Vogliamo essere sicuri che gli inquirenti della UE possano accedere ai dati che dovrebbero esser resi loro disponibili”, ha detto Michael Simonoff, portavoce di AMD.

Il chipmaker di Sunnyvale sostiene che tale documentazione potrebbe fornire informazioni preziose circa le pratiche di mercato di Intel e, in modo particolare, sulle presunte ritorsioni che questa avrebbe minacciato nei confronti di alcuni produttori di computer che adottano i chip di AMD. Ed è qui, evidentemente, l’interesse principale di AMD nella vicenda.

Intel ha fatto ricorso alla Corte Superiore dopo che AMD, lo scorso ottobre, ha vinto la causa in un tribunale distrettuale. In sua difesa il chipmaker di Santa Clara reclama il fatto che l’inchidesta antitrust dell’UE non è ancora sfociata in una causa legale e, pertanto, la legge tirata in ballo AMD sarebbe in questo caso inapplicabile.

Va notato che la UE, pur interessata ai documenti, è d’accordo con gli avvocati di Intel. La Commissione teme infatti che la vittoria di AMD apra un rischioso precedente, e dia l’avvio ad un’incontrollata condivisione di documenti fra corti americane ed europee: condivisione che, secondo alcuni avvocati, dovrebbe invece avvenire solo in rare e particolari circostanze.

Sebbene la decisione della Corte Suprema potrebbe avere un ruolo determinante sul proseguimento dell’indagine antitrust europea, gli analisti sostengono che il caso non dovrebbe avere un impatto immediato sul valore azionario del big di Santa Clara.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • logitech scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    Se vantarti in un forum come quello di
    PI fa

    aumentare la tua autostima, fa pure, ma
    ti

    dà un'aria da sfigato...

    Sei tu che ti vanti attaccando gli altri... Riporta precisamente dove mi vanto attacando gli altri: io dico ciò che faccio notare a chi si sopravvaluta dove sbaglia.
    e questo ti dà un'aria da sfigato
    invidioso...Quando mi ridurrò ad essere invidioso di una persona come te, sarà l'ora di suicidarmi!
    A parte l'ortografia, solo per i commerciali
    i clienti sono lo scopo della vita...A parte che dovresti farmi notare *quale* errore di ortografia ho commesso, noto che ritorni continuamente con questa storia dei "commerciali". Mi sa tanto che sono l'incubo della tua piccola vita!

    Essere ingegneri e fare ricerca allo
    stato

    dell'arte permette di scegliersi i

    clienti...

    Stato dell'arte della ricerca i web
    services? :) ROTFL!Hai problemi di comprensione, adesso non mi stupiscono più tutte le cavolate che spari. Io ho affermato che faccio ricerca allo stato dell'arte sui WS (infatti qui in dipartimento circolano perlopiù RFP), non che i WS sono lo stato dell'arte della ricerca!!!!

    Ah sì? Sono io quello che ha
    sparato

    a zero sugli autori del WSDL? O sei
    stato

    tu? E' questo il tuo concetto di
    rispetto?

    Io sparare a zero sugli autori del WSDL? Ma
    hai mai imparato a leggere? Io ho soloAllora, nel tuo intervento iniziale parti citando le affermazioni dell'OASIS, dopodichè affermi "I web services sono l'esatto contrario". Ogni altro commento mi sembra superfluo.
    Mai detto questo. Ma a leggere quello che
    hai scritto manie di grandezza le hai solo
    tu.Sì, bravo. Torno al tuo lavoro e pensa al tuo nemico giurato: "il commerciale"!!!
  • ldsandon scrive:
    Re: Non basterà un browser...

    Se vantarti in un forum come quello di PI fa
    aumentare la tua autostima, fa pure, ma ti
    dà un'aria da sfigato...Sei tu che ti vanti attaccando gli altri... e questo ti dà un'aria da sfigato invidioso...
    Io i clienti li ho già, solo che non
    sono "lo scopo della mia vita", ma
    semplicemente un modo per raccimolare
    qualche soldo.A parte l'ortografia, solo per i commerciali i clienti sono lo scopo della vita...
    Essere ingegneri e fare ricerca allo stato
    dell'arte permette di scegliersi i
    clienti...Stato dell'arte della ricerca i web services? :-) ROTFL!
    Ah sì? Sono io quello che ha sparato
    a zero sugli autori del WSDL? O sei stato
    tu? E' questo il tuo concetto di rispetto?Io sparare a zero sugli autori del WSDL? Ma hai mai imparato a leggere? Io ho solo sottolineato che l'affermazione riportata nel testo dell'articolo era esagerata. Poi sei tu che hai cominciato a sparare a zero su di me... come ogni zelota novellino.
    Ah, ma ho capito: tu tieni corsi di
    programmazione, sei molto meglo di quelli
    dell'WSDL!!!!Mai detto questo. Ma a leggere quello che hai scritto manie di grandezza le hai solo tu.
  • logitech scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon
    No, al massimo i corsi di programmazione io
    li tengo.Se vantarti in un forum come quello di PI fa aumentare la tua autostima, fa pure, ma ti dà un'aria da sfigato...
    Invidioso di un pivello? Suvvia, aspetta tu
    di trovarne dei clienti... con questoIo i clienti li ho già, solo che non sono "lo scopo della mia vita", ma semplicemente un modo per raccimolare qualche soldo.Essere ingegneri e fare ricerca allo stato dell'arte permette di scegliersi i clienti...
    atteggiamento non so quanta strada farai.
    Impara a rispettare il tuo prossimo e le sue
    idee. Ti aiuterà nella vita.Ah sì? Sono io quello che ha sparato a zero sugli autori del WSDL? O sei stato tu? E' questo il tuo concetto di rispetto?Ah, ma ho capito: tu tieni corsi di programmazione, sei molto meglo di quelli dell'WSDL!!!!
  • Anonimo scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    appunto, sei tu che dicevi che i WS sono

    *solo* RPC ;)

    Io ho detto che sono un metodo di
    "remoting". Che sia basato su chiamate
    sincrone o messaggi asincroni sempre
    remoting è, IMHO ;)

    Altrimenti sarebbero un semplice protocollo
    di trasporto, nulla di più.
    vabbe' non stiamo qui a scornarci sulle definizioni, gia' ognuno (sun, ibm, ms etc) da' quella che preferisce, chi li considera una architettura a se' stante, chi una interfaccia per creare una architettura orientata ai servizi, chi li vede come un'estensione delle pagine web, senza contare le sono decine e decine di protocolli solo parzialmente sviluppati che non sappiamo neanche se verranno mai usati :)ciao,Ecio
  • ldsandon scrive:
    Re: Non basterà un browser...

    appunto, sei tu che dicevi che i WS sono
    *solo* RPC ;)Io ho detto che sono un metodo di "remoting". Che sia basato su chiamate sincrone o messaggi asincroni sempre remoting è, IMHO ;)Altrimenti sarebbero un semplice protocollo di trasporto, nulla di più.
  • Anonimo scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    Poi vi è la modalità,
    diciamo,

    message-based: Compilo un messaggio, lo

    riempio di header di
    sicurezza,transazioni,

    routing, reliability ecc e lo lascio
    andare

    per la sua strada.

    Ok, message queue invece di remoting. Ma
    sono due cose diverse - con campi di
    applicazione diversi.appunto, sei tu che dicevi che i WS sono *solo* RPC ;)

    Questa seconda modalità è

    quella consigliata, la prima è

    deprecata.

    Consigliata da chi? Se la comunicazione
    è asincrona mi va bene la seconda,
    altrimenti no.ho letto anchio da qualche parte che si consiglia l'approccio doc/literal invece di quello rpc/encoded, teoricamente la cosa dovrebbe prendere piede con wsdl 2.0....

    Lavoro con gli strumenti di oggi per
    risolvere i problemi di domani, per quelli
    di dopodomani devo aspettare il rilascio di
    specifiche e strumenti...Da questo punto di vista hai ragione, tutte le maggiori implementazioni sono basate su wsdl1.2 e non su 2.0
  • Anonimo scrive:
    Re: Non basterà un browser...

    Se lavori con l'attuale implementazione M$
    cestina tutto. La visione corretta dei WS
    è quella Service-Oriented e non RPC.veramente e' il contrario, .NET utilizza come approccio di default quello doc/literal mentre axis usa rpc/encodedEcio
  • ldsandon scrive:
    Re: Non basterà un browser...

    Poi vi è la modalità, diciamo,
    message-based: Compilo un messaggio, lo
    riempio di header di sicurezza,transazioni,
    routing, reliability ecc e lo lascio andare
    per la sua strada.Ok, message queue invece di remoting. Ma sono due cose diverse - con campi di applicazione diversi.
    Questa seconda modalità è
    quella consigliata, la prima è
    deprecata.Consigliata da chi? Se la comunicazione è asincrona mi va bene la seconda, altrimenti no.
    Evidentemente tu ci lavori, ma non studi
    molto. Con rispetto... 8)Lavoro con gli strumenti di oggi per risolvere i problemi di domani, per quelli di dopodomani devo aspettare il rilascio di specifiche e strumenti...
  • ldsandon scrive:
    Re: Non basterà un browser...
    Ok, giocate pure con le buzzwords... ai clienti piacciono, ai commerciali IBM e MS pure, poi gratta gratta trovi sempre le stesse cose.http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.htmGuarda caso parla di DCOM e CORBA, che non sono altro che modelli di RPC object-oriented.Se mi parlate di architettura "service oriented" per il partizionamento di una applicazione distribuita è una cosa, i "web services" sono un'altra. Potete implementare un'architettura service oriented con qualsiasi tecnologia di remoting. Che i web services siano comodi se i servizi devono essere raggiungibili via internet e attraverso firewall è vero, che siano l'architettura non è vero.
  • Anonimo scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    E questa definizione dove l'hai
    trovata, su

    "Web Service for dummies"???

    No, non leggo i libri che leggi tu...



    Ma hai mai sentito parlare di binding?
    Tutti

    i linguaggi creati per i WS hanno dei

    biniding per l'HTML (molti hanno binding

    _solo_ per html).

    Sono solo un modo di utilizzare i WS, e non
    quello principale.


    Io non devo vendere prorpio niente, i WS

    sono solo l'argomento della mia tesi...

    Io ci lavoro con i WS... quando avrai
    imparato qualcosa di serio ripassa....Se lavori con l'attuale implementazione M$ cestina tutto. La visione corretta dei WS è quella Service-Oriented e non RPC.Far l'early adopter di M$ è un grande rischio.
  • Anonimo scrive:
    Re: Non basterà un browser...

    Cambia l'encoding della chiamata, ma sempre
    di chiamata procedura remota si tratta,
    cioè Remote Procedure Call aka RPC. Vi sono due modalità di chiamate nei WS.RPC come la intendi tu: faccio una domanda in SOAP e ricevo una risposta.Poi vi è la modalità, diciamo, message-based: Compilo un messaggio, lo riempio di header di sicurezza,transazioni, routing, reliability ecc e lo lascio andare per la sua strada.Questa seconda modalità è quella consigliata, la prima è deprecata.Evidentemente tu ci lavori, ma non studi molto. Con rispetto... 8)
  • Anonimo scrive:
    Re: E WS-Transaction quando?
    - Scritto da: Anonimo
    Confermo.

    Inoltre come per tutte le applicazioni ed i
    componenti del mondo, bisognerà
    aspettare che questi web-services siano
    utilizzati da una massa critica di
    programmatori e di utenti, e infine vedere
    quanto resistono agli attacchi hacker.

    Farsi i propri componenti o scegliersi le
    proprie tecnologie aumenta la sicurezza,
    disorientando chi vuole attaccare un
    servizio. Affidarsi tutti a componenti
    standard, che poi magari vengono "bucati",
    cosa provocherebbe?WS-X sono protocolli (in forma XML). Tu stai parlando di buchi sulle implementazioni degli stack di protocolli. E' un'altra cosa.Quello che dicevo io (sono l'autore del primo post) è che finchè non ho anche la specifica di WS-Transaction e le correlate a posto, neanche ci penso a progettare qualcosina.....
  • Anonimo scrive:
    Re: E WS-Transaction quando?
    - Scritto da: Anonimo
    Confermo.
    Farsi i propri componenti o scegliersi le
    proprie tecnologie aumenta la sicurezza,
    disorientando chi vuole attaccare un
    servizio. Affidarsi tutti a componenti
    standard, che poi magari vengono "bucati",
    cosa provocherebbe?DA quando una specifica proprietaria e' piu' affidabile di una standard pubblica?Non c'e' nessuna correlazione.Le dimostrazioni si sprecano.
  • ldsandon scrive:
    Re: Non basterà un browser...

    c'e' da dire xo' che ne hai una visione
    limitata,Cioè? Dimmi cos'è un WS più di una chiamata remota.
    i WS non sono *solo* RPC (non per altro in
    SOAP l'rpc/encoded e' sulla strada del
    deprecated e si consiglia gia' da ora
    l'utilizzo del doc/literal ovvero dello
    scambio di documenti XML non encodati come
    chiamata a procedura remota)Cambia l'encoding della chiamata, ma sempre di chiamata procedura remota si tratta, cioè Remote Procedure Call aka RPC.
  • ldsandon scrive:
    Re: Non basterà un browser...

    Dei libri che leggo io non riusciresti a
    capire nemmeno il titolo...Leggi libri in cinese antico? Sì, lì ho dei problemi.
    Hai fatto un corso di due settimane su "Cosa
    sono i WS?" finanziato da qualche fondo
    sociale, poi hai iniziato a lavorareNo, al massimo i corsi di programmazione io li tengo.
    Se sei invidioso di che fa ricerca, sfogati
    sui tuoi clienti.Invidioso di un pivello? Suvvia, aspetta tu di trovarne dei clienti... con questo atteggiamento non so quanta strada farai. Impara a rispettare il tuo prossimo e le sue idee. Ti aiuterà nella vita.
  • Anonimo scrive:
    Re: Non basterà un browser...
    dimenticavo,alla domanda "quale browser capisce SOAP",se non erro l'XPCom di Mozilla lo supporta...Ecio
  • Anonimo scrive:
    Re: Non basterà un browser...

    Io ci lavoro con i WS... quando avrai
    imparato qualcosa di serio ripassa....c'e' da dire xo' che ne hai una visione limitata,i WS non sono *solo* RPC (non per altro in SOAP l'rpc/encoded e' sulla strada del deprecated e si consiglia gia' da ora l'utilizzo del doc/literal ovvero dello scambio di documenti XML non encodati come chiamata a procedura remota)Ecio
  • logitech scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    E questa definizione dove l'hai
    trovata, su

    "Web Service for dummies"???

    No, non leggo i libri che leggi tu...Dei libri che leggo io non riusciresti a capire nemmeno il titolo...

    Io non devo vendere prorpio niente, i WS

    sono solo l'argomento della mia tesi...

    Io ci lavoro con i WS... quando avrai
    imparato qualcosa di serio ripassa....Fammi capire...Hai fatto un corso di due settimane su "Cosa sono i WS?" finanziato da qualche fondo sociale, poi hai iniziato a lavorare ripetendo le tre cose tre che ti avevano spiegato ai clienti, su cui facevi una buona impressione, perchè per loro è già difficile configurare la posta elettronica.A quel punto hai pensato di sapere tutto di informatica...Caro mio, le cose serie le impari nei dipartimenti. Noi stiamo lavorando su delle implementazioni di WS usando specifiche che sono ancora degli RFP, perchè bisogna portarsi avanti.Ci sono un sacco di problematiche dietro alle interfacce grafiche che i cosidetti "programmatori" amano usare.Se sei invidioso di che fa ricerca, sfogati sui tuoi clienti.
  • ldsandon scrive:
    Re: Non basterà un browser...

    E questa definizione dove l'hai trovata, su
    "Web Service for dummies"???No, non leggo i libri che leggi tu...
    Ma hai mai sentito parlare di binding? Tutti
    i linguaggi creati per i WS hanno dei
    biniding per l'HTML (molti hanno binding
    _solo_ per html).Sono solo un modo di utilizzare i WS, e non quello principale.
    Io non devo vendere prorpio niente, i WS
    sono solo l'argomento della mia tesi...Io ci lavoro con i WS... quando avrai imparato qualcosa di serio ripassa....
  • Anonimo scrive:
    Re: Non basterà un browser...
    - Scritto da: logitech

    Ma hai mai sentito parlare di binding? Tutti
    i linguaggi creati per i WS hanno dei
    biniding per l'HTML (molti hanno binding
    _solo_ per html).Casomai sarà HTTP. Comunque consiglio a tutti di vedere cosa stanno facendo MS e IBM con Indigo e l'Enterprise Bus.
  • logitech scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon

    Ti sfugge il concetto di web-service: un

    Sfugge a te: un web services è una
    classe che espone una interfaccia invocabile
    da remoto. Non è nient'altro che una
    forma di RPC con la sua serie di protocolli
    - niente di più, niente di meno.E questa definizione dove l'hai trovata, su "Web Service for dummies"???Prova a leggere qualcosa del w3c, per esempio: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/

    ??? Da quando?

    Quale browser capisce SOAP? O è inMa hai mai sentito parlare di binding? Tutti i linguaggi creati per i WS hanno dei biniding per l'HTML (molti hanno binding _solo_ per html).

    Hai una visione un po' riduttiva dei

    web-services.

    Tu ne hai una visione da commerciale, direi,
    i web services che salvano il mondo fino
    alla prossima idea da vendere.Io non devo vendere prorpio niente, i WS sono solo l'argomento della mia tesi...
  • ldsandon scrive:
    Re: Non basterà un browser...

    Ti sfugge il concetto di web-service: unSfugge a te: un web services è una classe che espone una interfaccia invocabile da remoto. Non è nient'altro che una forma di RPC con la sua serie di protocolli - niente di più, niente di meno.
    ??? Da quando?Quale browser capisce SOAP? O è in grado di creare da solo un'interfaccia per un WS? Un browser non è in grado di essere un consumer, è costruito per parsare HTML e eseguire Javascript, più di questo non fa. Casomai il web server può usare un web service per creare una pagina HTML per il client, ma questa è un'altra storia.
    Hai una visione un po' riduttiva dei
    web-services.Tu ne hai una visione da commerciale, direi, i web services che salvano il mondo fino alla prossima idea da vendere.
  • logitech scrive:
    Re: Non basterà un browser...
    - Scritto da: ldsandon
    I web services sono l'esatto contrario: sono
    un meccanismo di "remoting" (invocazione
    remota di codice) e non una "interfaccia"
    come HTML. L'unico punto in comune èTi sfugge il concetto di web-service: un web-service *NON* è l'applicazione in sè (e.g. il cgi-bin che "esegue" il servizio), ma è l'insieme *astratto* delle sue componenti (protocollo, bussiness-logic, registro etc.).
    che usano HTTP per la comunicazione
    client/server (e per questo sono poco
    performanti, per ora).
    Sono perfettamente utilizzabili senza un
    browser, anzi un browser non serve a nulla
    perché non è in grado di
    utilizzarli.??? Da quando?
    Il vantaggio di SOAP è di essere uno
    standard indipendente dalla piattaforma (i
    metodi di un web services scritto in java
    sono facilmente invocabili da
    un'applicazione nativa Windows o Linux, e
    viceversa) e di usare HTTP come trasporto eUsare _anche_ l'http. Ti manca il concetto di binding.
    quindi di passare agevolmente attraverso i
    firewall. Potrebbero permettere di costruire
    agevolmente applicazioni distribuite che
    sfruttino servizi disponibili in rete, ma
    potrebbero anche segnare la fine del browser
    così come lo conosciamo. Invece di
    richiamare pagine HTML si chiameranno
    servizi. Ad esempio invece di ottenere una
    pagina HTML con lo stato del mio conto
    corrente potrei ricevere un file XML con gli
    stessi dati, che a quel punto potrei
    processare con qualsiasi programma in
    grado di leggere quel formato, programma che
    potrebbe benissimo non essere un browser. Lo
    stesso programma potrebbe invocare un metodo
    del servizio per effettuare un bonifico, di
    nuovo senza dover passare per un browsers e
    HTML. Con i web services è finalmente
    possibile separare i dati dall'interfaccia.Hai una visione un po' riduttiva dei web-services.==================================Modificato dall'autore il 21/04/2004 10.48.50
  • Anonimo scrive:
    Re: E WS-Transaction quando?
    concordo in pienomassimo
  • ldsandon scrive:
    Non basterà un browser...
    "In prospettiva, affermano, quando basterà un browser e una connessione a larga banda per accedere ad applicativi e giochi, i sistemi operativi potrebbero perdere parte della loro attuale importanza, divenendo - soprattutto per gli utenti desktop - una sorta di interfaccia tuttofare al "sistema operativo globale": il Web."I web services sono l'esatto contrario: sono un meccanismo di "remoting" (invocazione remota di codice) e non una "interfaccia" come HTML. L'unico punto in comune è che usano HTTP per la comunicazione client/server (e per questo sono poco performanti, per ora).Sono perfettamente utilizzabili senza un browser, anzi un browser non serve a nulla perché non è in grado di utilizzarli.Il vantaggio di SOAP è di essere uno standard indipendente dalla piattaforma (i metodi di un web services scritto in java sono facilmente invocabili da un'applicazione nativa Windows o Linux, e viceversa) e di usare HTTP come trasporto e quindi di passare agevolmente attraverso i firewall. Potrebbero permettere di costruire agevolmente applicazioni distribuite che sfruttino servizi disponibili in rete, ma potrebbero anche segnare la fine del browser così come lo conosciamo. Invece di richiamare pagine HTML si chiameranno servizi. Ad esempio invece di ottenere una pagina HTML con lo stato del mio conto corrente potrei ricevere un file XML con gli stessi dati, che a quel punto potrei processare con qualsiasi programma in grado di leggere quel formato, programma che potrebbe benissimo non essere un browser. Lo stesso programma potrebbe invocare un metodo del servizio per effettuare un bonifico, di nuovo senza dover passare per un browsers e HTML. Con i web services è finalmente possibile separare i dati dall'interfaccia.
  • Anonimo scrive:
    Re: E WS-Transaction quando?
    Confermo.Inoltre come per tutte le applicazioni ed i componenti del mondo, bisognerà aspettare che questi web-services siano utilizzati da una massa critica di programmatori e di utenti, e infine vedere quanto resistono agli attacchi hacker.Farsi i propri componenti o scegliersi le proprie tecnologie aumenta la sicurezza, disorientando chi vuole attaccare un servizio. Affidarsi tutti a componenti standard, che poi magari vengono "bucati", cosa provocherebbe?Romeo- Scritto da: Anonimo
    Finchè non ho WS-Transaction
    standardizzaro e un framework (+ server) che
    mi permetta di implementarlo, io non scrivo
    applicazioni con WS. Sia in Java che in
    .NET.

    Più di qualche RPC autenticata, senza
    le transazioni, non si può fare.
    Mi sembra chiaro.

    We're waiting...
  • Anonimo scrive:
    E WS-Transaction quando?
    Finchè non ho WS-Transaction standardizzaro e un framework (+ server) che mi permetta di implementarlo, io non scrivo applicazioni con WS. Sia in Java che in .NET.Più di qualche RPC autenticata, senza le transazioni, non si può fare.Mi sembra chiaro.We're waiting...
Chiudi i commenti