Sony prepara il suo antiSkype

Il colosso giapponese sforna un servizio con cui spera di entrare in diretta concorrenza con il più gettonato sistema VoIP. Videochiamate in prima fila


New York – C’è chi il VoIP lo compra chiavi in mano , come eBay , e chi preferisce invece costruirsene uno proprio. E’ il caso di Sony , che ha annunciato la prossima presentazione di un sistema VoIP analogo a Skype , con un particolare accento sulle funzionalità di videocomunicazione.

L’enfasi della novità si spinge fino al nome: il servizio si chiamerà IVE, che sta per “Instant Video Everywhere”, e sarà reso disponibile per il download da internet. L’oculata tattica commerciale di Sony sembra voler abbinare IVE al lancio dei nuovi laptop Vaio BX, che saranno provvidenzialmente dotati di videocamera integrata.

Come Skype, IVE consentirà agli utenti di effettuare chiamate verso le linee telefoniche tradizionali fisse e mobili. Ad un canone mensile di 9,95 dollari (poco più di 8 euro) si otterrà inoltre un numero telefonico di 10 cifre per ricevere chiamate dagli utenti non dotati di sistemi VoIP.

Ma, come detto sopra, è la videocomunicazione la vera novità del servizio, realizzato in collaborazione con GlowPoint , che rappresenta l’ultima evoluzione del concetto di “picture phone” applicato al mercato “consumer”.

La notizia delle intenzioni di Sony cade tempestivamente alcuni giorni dopo l’annuncio, da parte di Skype, dell’ introduzione della videocomunicazione dalla prossima versione 1.5. A scanso di equivoci, Sony tiene a precisare di non avere alcuna velleità da operatore telefonico: “Siamo un’industria di produzione che vende hardware” riferisce Eric Murphy, vicepresidente della divisione videocomunicazione di Sony Electronics. Basta crederci.

Dario Bonacina

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

  • Anonimo scrive:
    Dai che le vitamine fanno bene ....
    Dai che le vitamine fanno bene : rinforzano il codice !   ;)     :D
  • Anonimo scrive:
    SqlServer 2005 lo fa già ed è gratis.
    http://www.dotnethell.it/articles/SQL-Server-2005-XML.aspx
    • Anonimo scrive:
      Re: SqlServer 2005 lo fa già ed è gratis
      Diciamo che è compreso nel prezzo. Anche in DB2 è così comunque.P.S.: mi piace l'articolo linkato (e anche SQL 2005)
      • Anonimo scrive:
        Re: SqlServer 2005 lo fa già ed è gratis
        Con db2 sarà compreso nel prezzo, SqlServer 2005 express è gratuito.- Scritto da: Anonimo

        Diciamo che è compreso nel prezzo. Anche in DB2 è
        così comunque.

        P.S.: mi piace l'articolo linkato (e anche SQL
        2005)
        • Anonimo scrive:
          Re: SqlServer 2005 lo fa già ed è gratis

          SqlServer 2005 express è gratuito.Sì, ma ci fai DB piccoli piccoli. Appena crescono devi pagare lo stesso....
    • Anonimo scrive:
      Re: SqlServer 2005 lo fa già ed è gratis
      Oracle lo fa da tre versioni....
    • Anonimo scrive:
      Re: SqlServer 2005 lo fa già ed è gratis
      - Scritto da: Anonimo
      http://www.dotnethell.it/articles/SQL-Server-2005-L'unica cosa che fa sql server è cagare.
      • Anonimo scrive:
        Re: SqlServer 2005 lo fa già ed è gratis
        - Scritto da: Anonimo

        - Scritto da: Anonimo


        http://www.dotnethell.it/articles/SQL-Server-2005-

        L'unica cosa che fa sql server è cagare.Prego, motiva un pò questa risposta ;)
    • Anonimo scrive:
      Re: SqlServer 2005 lo fa già ed è gratis
      Ti sfugge che DB2 gestisce decine di TB di dati senza particolari problemi.
      • Anonimo scrive:
        Re: SqlServer 2005 lo fa già ed è gratis
        Anche SQL Server.In entrambi casi per arrivare a quei limiti bisogna sapere come fare. Non basta riempire un DB di qualche tera e pregare come vedo spesso ;)
  • Anonimo scrive:
    Basta XML
    Che p***e questo XML, ma serve veramente?Voglio dire, capisco quando bisogna usare un formato per far comunicare differenti sistemi fra di loro (penso ai web service). Però basta!Attualmente si vede usare XML anche per file di configurazione e per formati di file tipo documento (vedi ODF). Secondo me dovrebbe essere usato SOLTANTO come formato per messaggi.Ora non voglio essere polemico (sono bugiardo :p ) ma memorizzare documenti XML direttamente in un DB è una vaccata. Infatti ogni volta che bisogna estrarre dei dati "veri" dai documenti bisogna parsarli, e viceversa quando si vogliono trasformare i dati veri in XML bisogna serializzarli, sono costi non da poco.Secondo me bisognerebbe spingere verso DBMS ad oggetti che mi sembrano il VERO futuro.
    • Anonimo scrive:
      Re: Basta XML

      Che p***e questo XML, ma serve veramente?Sì. Serve veramente.
      Attualmente si vede usare XML anche per file di
      configurazione e per formati di file tipoEsatto. Cosa dovresti usare? Un formato diverso per ogni file di configurazione, e reinventarti un parser ogni volta? Formati proprietari per i documenti che da qui a cinque anni rischi di non leggere più?
      documento (vedi ODF). Secondo me dovrebbe
      usato SOLTANTO come formato per messaggi.Perché? XML non è nato per i messaggi. SOAP è venuto dopo.
      Ora non voglio essere polemico (sono bugiardo :p
      ) ma memorizzare documenti XML direttamente in un
      DB è una vaccata. Infatti ogni volta che bisognaDipende. Se lo usi male fai una vaccata. Se lo usi bene ci guadagni parecchio.
      Secondo me bisognerebbe spingere verso DBMS ad
      oggetti che mi sembrano il VERO futuro.Sembravano, direi. Se ne parla da anni ormai, ma non hanno mai sfondato, probabilmente un motivo c'è.
      • Anonimo scrive:
        Re: Basta XML
        - Scritto da: Anonimo

        Che p***e questo XML, ma serve veramente?

        Sì. Serve veramente.Intendevo, serve veramente in un DB?


        Attualmente si vede usare XML anche per file di

        configurazione e per formati di file tipo

        Esatto. Cosa dovresti usare? Un formato diverso
        per ogni file di configurazione, e reinventarti
        un parser ogni volta? Formati proprietari per i
        documenti che da qui a cinque anni rischi di non
        leggere più?Ci sono prodotti che gestiscono la configurazione tramite codice (es. PicoContainer usa per la configurazione puro e semplice codice Java).Non parlo di configurazioni che devono stare in un file di testo (ad esempio i parametri di connessione ad un DB) ma di configurazioni interne dell'applicazione (sto pensando ai file xml di configurazione di Struts ad esempio).


        documento (vedi ODF). Secondo me dovrebbe

        usato SOLTANTO come formato per messaggi.

        Perché? XML non è nato per i messaggi. SOAP è
        venuto dopo.XML è nato per fare da tramite tra aziende diverse, quindi di fatto è nato per messaggi di interoperabilità tra aziende.


        Ora non voglio essere polemico (sono bugiardo :p

        ) ma memorizzare documenti XML direttamente in
        un

        DB è una vaccata. Infatti ogni volta che bisogna

        Dipende. Se lo usi male fai una vaccata. Se lo
        usi bene ci guadagni parecchio.La mia avversione ad XML (usato male) è fondamentalmente una: nonostante alcuni dicano il contrario, XML non è scalabile (bisogna cominciare a leggerlo sempre dall'inizio). Questo è il suo problema più grande.


        Secondo me bisognerebbe spingere verso DBMS ad

        oggetti che mi sembrano il VERO futuro.

        Sembravano, direi. Se ne parla da anni ormai, ma
        non hanno mai sfondato, probabilmente un motivo
        c'è.http://www.db4o.com/ sembra molto promettente. Tra l'altro ultimamente su theserverside hanno detto che avrebbero supportato query scritte direttamente in Java. Addio SQL (scherzo).P.S. Secondo me ODF è un passo enorme avanti, perché è uno standard. Solo che magari ci possono essere metodi migliori (sto pensando a TeX).
        • Anonimo scrive:
          Re: Basta XML

          Intendevo, serve veramente in un DB?Sì, serve veramente. Perché è spesso è inutile convertire da codice da XML Tabelle DB. Si perde un sacco di tempo inutilmente.
          interne dell'applicazione (sto pensando ai file
          xml di configurazione di Struts ad esempio).È una comodità. Hai già il parser, il file è autodescrittivo, è human-readable, ci puoi accedere anche con altri strumenti.
          XML è nato per fare da tramite tra aziende
          diverse, quindi di fatto è nato per messaggi di
          interoperabilità tra aziende.No, ti sbagli. XML è nato per avere un linguaggio di mark-up flessibile più semplice di SGML. Si dall'inizio uno dei compiti principali è stato quello di essere usato per "documenti", anche non strettamente gerarchici. L'uso per la messaggistica è solo una delle tante possibilità, ma non è mai stato lo scopo principale.
          cominciare a leggerlo sempre dall'inizio). Questo
          è il suo problema più grande.Anche molti formati binari hanno lo stesso problema. Comunque XML sacrifica la velocità in cambio di flessibilità e indipendenza. Non è detto che sia sempre la cosa migliore, non vorrei vedere un TCP/IP con i pacchetti in formato XML... :-)Del resto i DB non abbandonano la struttura standard. Aggiungono solo una funzionalità in più che in diversi casi è estremamente comoda. Se hai già contenuti in XML è comodo memorizzarli e interrogarli in formato nativo.
          http://www.db4o.com/ sembra molto promettente.Sì, ma come vedi siamo ancora alle promesse. Per ora nessuno ha sfondato, e ce ne sono diversi in giro da anni.
          direttamente in Java. Addio SQL (scherzo).Non scherzi più di tanto... dai un'occhiata a LINQ.
          essere metodi migliori (sto pensando a TeX).Ma TeX è in giro da anni e non si è affermato come standard. Quindi...
    • Anonimo scrive:
      Re: Basta XML
      - Scritto da: Anonimo
      Ora non voglio essere polemico (sono bugiardo :p
      ) ma memorizzare documenti XML direttamente in un
      DB è una vaccata. Infatti ogni volta che bisogna
      estrarre dei dati "veri" dai documenti bisogna
      parsarli, e viceversa quando si vogliono
      trasformare i dati veri in XML bisogna
      serializzarli, sono costi non da poco.Infatti DB2 Viper li gestisce direttamente e questi costi diminuiscono drasticamente. Non per essere polemico :D ma avere la gestione diretta dell'XML oramai è una esigenza che deve essere colmata. XML va anche bene per gestire dati di tipo "documento". Un db relazionale/documentale può gestire una serie di scenari veramente interessanti. Tra l'altro sono gli scenari più innovativi.Purtroppo penso che i db ad oggetti non li vedremo mai. :(
      • Anonimo scrive:
        Re: Basta XML
        - Scritto da: Anonimo

        - Scritto da: Anonimo


        Ora non voglio essere polemico (sono bugiardo :p

        ) ma memorizzare documenti XML direttamente in
        un

        DB è una vaccata. Infatti ogni volta che bisogna

        estrarre dei dati "veri" dai documenti bisogna

        parsarli, e viceversa quando si vogliono

        trasformare i dati veri in XML bisogna

        serializzarli, sono costi non da poco.

        Infatti DB2 Viper li gestisce direttamente e
        questi costi diminuiscono drasticamente. Un momento... io intendo che, quando ti arrivano dopo una query, tu hai un documento XML che devi gestire, e per gestirlo devi fare il parsing con qualcosa. Se ti arriva direttamente una riga di una query, il parsing è praticamente zero (giusto spostamento di variabili).

        Non per essere polemico :D ma avere la
        gestione diretta dell'XML oramai è una esigenza
        che deve essere colmata.Perché tutti ci dicono che XML è il futuro...
        XML va anche bene per
        gestire dati di tipo "documento".Certo che "va bene" ma non è il massimo
        Un db
        relazionale/documentale può gestire una serie di
        scenari veramente interessanti. Tra l'altro sono
        gli scenari più innovativi.Tipo?

        Purtroppo penso che i db ad oggetti non li
        vedremo mai. :(
        http://www.db4o.com/
        • Anonimo scrive:
          Re: Basta XML

          Un momento... io intendo che, quando ti arrivano
          dopo una query, tu hai un documento XML che devi
          gestire, e per gestirlo devi fare il parsing conMa in molti contesti è esattamente quello che voglio!!! :-)Caso pratico: devo memorizzare delle informazioni (documenti), che devo poi visualizzare in modo diverso (XHTML, PDF, ecc.) su dispositivi diversi (dal PC al palmare, passando magari per un televisore). Qual'è la soluzione più semplice? Fare n copie del documento e memorizzarle in un BLOB? Io preferisco memorizzare il documento in formato XML, estrarlo (e la possibilità do ricerca *all'interno* dell'XML memorizzato è essenziale, così come la manipolazione diretta) e quindi con XSLT (o XSL-FO, ecc.) convertirlo nel formato finale.
          Perché tutti ci dicono che XML è il futuro...Perché XML è uno standard e ci sono in giro un mucchio di tool per manipolarlo... perché reinventare tutte le volte l'acqua calda?
          Certo che "va bene" ma non è il massimoDa quando? XML *è nato* per gestire documenti! Ma andate un po' sul sito del W3C a leggervi la documentazione! Come volete gestirli i documenti? In formato Microsoft Word? In PDF? Ma ci avete mai lavorato con un documentale?
      • Anonimo scrive:
        Re: Basta XML


        Purtroppo penso che i db ad oggetti non li
        vedremo mai. :(
        Basta avere il coraggio di uscire dal coro e non scegliere in base al "così fan tutti".http://www.intersystems.com/cache/index.htmlConcordo sul fatto che XML è un modello di rappresentazionedei dati e IMO non è adatto (performante, comodo, efficace....) ad essere utilizzato come modello di archiviazione dati in un database.Altra cosa è avere un database (e i database non solo solo relazionali, se non fai parte del coro) "che fa il suo mestiere" dando la possibilità di "proiettare" (o rappresentare se preferite) i dati in formato XML.Certo che se il database è limitato nelle possibilità di modellizzazione come un relazionale....i problemi di proiezione verso l'XML (o, peggio, viceversa) diventano dolori.....e allora si inventano strati/accrocchi per ovviare al problema di base: i limiti del modello relazionale nel rapresentare in modo semplice problemi del mondo reale.Ovviamente è una mia opinione personale...molto personale visto come va il mercato.....Saluti
  • matcion scrive:
    ACID
    Dall'articolo:"In particolare, IBM sostiene che il nuovo motore del proprio DBMS sarà capace di fondere in maniera trasparente i dati relazionali classici con i dati XML senza dover operare una nuova formattazione di questi ultimi o doverli inserire all'interno di oggetti di grandi dimensioni residenti nel database. Questa caratteristica promette di rendere l'accesso alle informazioni più efficiente e flessibile e, nel contempo, di ridurre i costi associati alle attuali tecniche di data management."Se ho ben capito sarà possibile interrogare dati contenuti in file XML che però non risiederanno sul database. Quindi le transazioni, il recovery dei dati e tutte le cose che i dbms fanno per garantirne l'integrità non saranno applicabili ai dati in XML?
    • Anonimo scrive:
      Re: ACID
      - Scritto da: matcion
      Dall'articolo:

      "In particolare, IBM sostiene che il nuovo motore
      del proprio DBMS sarà capace di fondere in
      maniera trasparente i dati relazionali classici
      con i dati XML senza dover operare una nuova
      formattazione di questi ultimi o doverli inserire
      all'interno di oggetti di grandi dimensioni
      residenti nel database. Questa caratteristica
      promette di rendere l'accesso alle informazioni
      più efficiente e flessibile e, nel contempo, di
      ridurre i costi associati alle attuali tecniche
      di data management."

      Se ho ben capito sarà possibile interrogare dati
      contenuti in file XML che però non risiederanno
      sul database. Quindi le transazioni, il recovery
      dei dati e tutte le cose che i dbms fanno per
      garantirne l'integrità non saranno applicabili ai
      dati in XML?Diciamo che l'articolista ha tradotto male. Il DB2 è un database ORDBMS (relazionale ad oggetti). Finora il DB2 gestiva i dati di tipo XML con il meccanismo degli extender che permette di definire oggetti. Il tipico store di questi oggetti sono LOB (Large OBject) sia binari (BLOB) che carattere (CLOB). Con Viper il dato XML diventa un dato per così dire nativo e quindi estremamente integrato. La parte ACID ovviamente vale ancora.
      • Ubu re scrive:
        Re: ACID
        - Scritto da: Anonimo

        - Scritto da: matcion

        Dall'articolo:



        "In particolare, IBM sostiene che il nuovo
        motore ... dati in XML?

        Diciamo che l'articolista ha tradotto male. Il
        DB2 è un database ORDBMS (relazionale ad
        oggetti). Finora il DB2 gestiva i dati di tipo
        XML con il meccanismo degli extender che permette
        di definire oggetti. Il tipico store di questi
        oggetti sono LOB (Large OBject) sia binari (BLOB)
        che carattere (CLOB). Con Viper il dato XML
        diventa un dato per così dire nativo e quindi
        estremamente integrato. La parte ACID ovviamente
        vale ancora.Vien via non registrato, registrati che cosi' riesco a filtrare i discorsi utili da quelli stupidi.Anche se non usero' mai un DB2 la tua opinione ha un valore.
Chiudi i commenti