Recomendadme lenguaje totalmente multiplataforma

estoy pensando en desarrollar un sistema basado en P2P y quiero que sea totalmente multiplataforma.

el software usara protocolos de red (sockets TCP/IP), una interfaz de usuario grafica (y tb texto) y quiero que tenga posibilidad de 'bindings' con el sistema de archivos local (esto es, que en windows el sistema P2P se pueda montar como una unidad de disco duro mas, que en linux se pueda montar como un directorio, que en macosx se pueda ver como un ifolder...)

en principio, y por la ley de minimo esfuerzo, me parecio buena la idea de hacerlo en JAVA, pero los bindings con los sistemas de archivo locales me echan atras, ademas que segun antiguas experiencias el soporte de programas JAVA no esta muy alla en linux...

De C me gustaria huir, pero creo que no habra otro remedio.

lenguajes interpretados no creo que los tenga en consideracion (python, va por ti)

de hecho, pensaba hacerlo en VisualBasic, pero entre que no tengo una licencia valida de VisualBasic (la mia de estudiantes caduco hace tiempo) y que VB no es multiplataforma, me echa atras...

ademas, busco un IDE decente (y libre/gratis) que me moleste lo menos posible mientras este desarrollando y que haga las compilaciones y las pruebas de forma automatica, no quiero estar saliendo cada 2x3 a la consola a ejecutar el compilador...

en C he probado DEV-C++ y no me parece mal, Kdevelop tampoco tiene mala pinta.
para Java he probado NetBeans y en principio tiene todo lo que busco, pero el tema de bindings de java me echa atras

¿alguna sugerencia?
Buuuuuuffff.... que manía tenéis últimamente con querer hacer cosas sin saber un lenguaje concreto.

Aprended, id haciendo pequeñas cosas... y tener muy claro lo que queréis hacer. EL LENGUAJE ES LO DE MENOS. (siempre que no sea Visual Basic)

Por cierto... ya dirás que quieres hacer de "P2P", porque o escoges un protocolo... o te lo inventas, y esto último puede ser jodido.

Saludos!
rurouni, no me pegues hombre...

he hecho pequeñas cosas en Java, python y php
medianas cosas en C, C++
y grandes cosas en VisualBasic.

y puedo decir que VB no es lo que necesito para mi proyecto, porque lo conozco, porque lo he mamao, porque se sus limitaciones y sus puntos fuertes...

y temo no conocer lo suficiente java o C, que son los dos contendientes para decidirme como para darme cuenta que me he equivocado de lenguaje en mitad del proyecto (que aunque sintacticamente C++ y java son similares, arquitecturalmente son algo distintos, lo suficiente para que la migracion sea 'una molestia')

va a ser mi primer proyecto grande en Java o C++, y quiero saber si alguien ha hecho algo parecido a lo que pretendo como para dar una opinon. (en ningun momento pongo en tela de juicio la tuya, rurouni)

y el protocolo, voy a adaptar en gran parte el del edonkey (que no emule), pero no quiero hacer un clon de edonkey, sino algo distinto, pero por el tema de mensajes y demas, edonkey es un protocolo que tiene pensadas ya bastantes cosas y cogerlo como guia me puede ayudar bastante a dar luz mi protocolo propio.
f5inet escribió:rurouni, no me pegues hombre...
No te pego! Sólo que, según mi experiéncia, se suele empezar la casa por el tejado, y no creo que sea la mejor opción...

Puedes intentarlo con JAVA o C#. Pero si no te quieres pelear con POO, hazlo en C y utiliza liberías multiplataforma.

Saludos!
Hombre... yo sobre el lenguaje no te voy a hablar, porque creo que Rurouni ya te lo ha dejado más o menos claro :P

De lo que si te voy a hablar, es que, tal y como está el panorama p2p, ¿no sería mejor que lo hicieses una vez estes empadronado en las Caiman, en las Fidji o en algunas islas de esas raras que no dependan de la república bananera de turno?

Te lo digo, más que nada, porque no me apetece ver una noticia del estilo:

Detenido un español creador del programa de intercambio de pares más famoso de la época, usaba la web http://www.elotrolado.net para maquinar la evolución del programa...

Se que es puro alarmismo barato, pero... la pregunta es: ¿por qué un p2p?

Saludos :P
jPlayer escribió:Se que es puro alarmismo barato, pero... la pregunta es: ¿por qué un p2p?

Saludos :P


porque como tecnologia y metodo de trabajo, el P2P es el futuro.

personalmente creo que los vetustos FTPs gigantescos y servidores de ficheros estan sobrevalorados. tienes que tener mucho hardware, por barato que sea, para dar servicio a gente, mientras que con P2P siempre puedes llegar teoricamente al tope de linea con poca sobrecarga adicional al server principal.

hicimos una prueba con Bittorrent en una red local 100Mbps de 5 PCs.

Archivo de prueba: RAR-ISO de 4GB de una pelicula DVD
Maximo teorico de la red: 12MB/s
Server FTP, 4 clientes chupando simultaneamente, velocidad media: 3,5MB/s (medido con flashFXP)
Server Azureus con archivo completo y compartiendo, haciendo ademas de tracker, 4 clientes simultaneos, velocidad media: 8MB/s

el P2P es una tecnologia que puede eclosionar en cualquier momento, y que me aspen si yo no tengo la idea para eclosionarla...

por supuesto el P2P no es malo, lo malo es el uso que se le de...

Con respecto a POO, no me molesta, es mas, me gusta programar en POO, el asquito que me daba VB es que tenia una POO de juguete en objetos externos (metodos privados ¿donde? variables protegidas ¿para que?)...
jPlayer escribió:Detenido un español creador del programa de intercambio de pares más famoso de la época, usaba la web http://www.elotrolado.net para maquinar la evolución del programa...


[qmparto] [qmparto] [qmparto] [qmparto] [qmparto] [qmparto]
C es el lenguaje más portable que existe.
resucito el hilo.

finalmente me he decidido por C y crear un protocolo propio P2P. me gustaban las caracteristicas de proteccion automatica de arrays y demas cosas de Java, pero necesito un cliente 'light' que cargue rapido y en diversas pruebas internas, un cliente Java tardaba en cargar una media de 25segundos, mientras que el equivalente a C tardaba unos miseros 5segundos. los 20 segundos extras eran toda la carga de la maquina virtual, supongo. El cliente hacia unas pocas consultas SQL y abria y cerraba unos cuantos sockets. una vez ambos clientes arrancados e inicializados el rendimiento era comparable. ahora viene la segunda pregunta:

necesito una interfaz de usuario multiplataforma. he visto algo de wxwidgets, pero no la he catado como para decidirme por ella y me gustaria que el 'look and feel' fuera consistente entre plataformas. en la medida de lo posible querria evitar GTK y QT, puesto que como he dicho, necesito un cliente 'ligero' (del tipico que se queda al ladito del reloj, en el system tray, y se lo molesto que es que un programita de los que se quedan ahi tarden tanto en arrancar al iniciar el equipo).

estoy dispuesto a escuchar recomendaciones, incluso si me recomendais python estaria dispuesto a escuchar opiniones.

mas datos:
- el cliente usara una GUI grafica que se instalara en el system tray (me oriento por WxWidgets)
- el cliente usara sockets SSL sobre HTTP (importante, no se que libreria usar en C o Python. Java tiene la suya propia)
- el cliente usara SQL internamente (me oriento por SQLite de momento)
- el cliente usara criptografia asimetrica (PGP/GPG)
- el cliente podria usar sistemas de comunicacion alternativos, como POP3/SMTP para envios de correo (multidifusion por email) o envios FTP con visibilidad HTTP (multidifusion por HTTP)

asi que os pido que me orienteis dentro de lo que sepais o entendais. lo que solicito es diversas opciones en librerias en C o en el lenguaje de vuestra eleccion para ir documentandome.
Usa openssl en C.

No puedo aportar mucho más.

- ferdy
Joder, hay algo que no vaya a llevar? [plas]

Yo también me decantaría por el C.. no se komo kedaría de bonito el wmwmwmwwidgets ese X-D ,pero como dice Ferdy.. más portable imposible xD

Sobre firmas asimetrikas.. supongo ke podrías llamar al gnupg o incorporarlo dentro del proyecto, si es libre, claro [sati]


En fins, suerte && 1 saludo
sobre firma/encriptacion asimetrica ya he estado viendo openssl e implementa RSA.

la pena es que el desarrollo de wxSSL lleva detenido 4 años :(
¿Has pensado en separar la parte background y la interfaz de usuario?

Es trabajo extra pero el resultado es gratificante(lo digo por experiencia).

Suerte.
si, el cliente es el miniprograma C que estamos hablado

la Gui es una WEB que usa XML/XSLT sobre HTTPS

¿os acordais del audiogalaxy (el downloader en el system tray y para descargar cosas os conectabais a la web)? pues eso mismo
Siento no haber conocido el AudioGalaxy.

Pero el programa cliente, aunque este en el system tray, tendrá su correspondiente gui de configuración, de status, de progreso.....(interfaz de usuario por llamarlo de alguna manera) ,y a parte todo el del diálogo con servidores u otros clientes para descargas, poll........(background por decirlo de alguna manera).

Encontraras maneras buenisimas y rapidas de hacer interfaces de usuario.
Encontraras librerias buenisimas para dialogar con servidores y clientes.
¿Pero por que demonios es tan dificil que convivan las dos juntas?
!Pues las separo! !ea!.

Algunas ventajas :

Mas facilidad a la hora de escoger las mejores herramientas
Mejor soporte para distintos interfaces de usuario, incluso remotos.

Algunas Desventajas:

Hay que currarse la comunicacion entre la interfaz de usuario y el background(que no es poco, pero hay cosas ya hechas).


Suerte
14 respuestas