🚀 go-pugleaf

> Poner en mi p�gina web una base de datos. No me importa en qu�.
> Manejar esa base de datos desde un applet (a�adir, borrar, modificar
> registros, etc...). Llamar� a este applet desde mi p�gina web que est� en un
> servidor al que pago religiosamente todos los meses :-( .
> Primera pregunta:
> � Puedo hacer esto sin depender de mi proveedor, o hasta que punto dependo
> de �l? (es facil �no?)

Depende de cuanto te quieras gastar. Un proveedor de presencia internet que te
deje poner CGIs es caro. Si encima quieres poder acceder a una base de datos,
m�s caro todav�a. Y si adem�s quieres "elegir" qu� programa gestiona la base de
datos, ya ni te cuento.

Una empresa de cuyo servidor Web me encargo (http://www.akal.com) est� alojada
en un proveedor (http://www.rapidsite.es) que le cobra 8000 pelas + IVA por
tener derecho a ejecutar CGIs en la m�quina UNIX. Si contrat�ramos la
posibilidad de usar la base de datos mSQL, tendr�amos que pagar bastante m�s (el
doble, creo). Y para poder usar SQL Server sobre NT, que supongo que ser�a lo
m�s c�modo, las tarifas se disparan (me suena que a las 50.000, pero no estoy
seguro).

En resumen... que cuanta m�s libertad quieras, m�s tienes que pagar.

Soluci�n barata, aunque no muy c�moda: implementa el acceso a la base de datos
con un CGI. El navegador accede al CGI a trav�s de un form en una p�gina Web, y
el CGI trabaja con el archivo de la base de datos de forma local. Y si quieres
usar Java para darle m�s funcionalidad al cliente, mete en la p�gina un applet
que se encargue de llamar al CGI y que lea los datos de vuelta.

Con este sistema, te tienes que encargar t� de abrir el fichero desde el CGI,
leer el contenido, buscar los registros, etc... Es un co�azo, pero es barato. El
CGI puede estar en cualquier lenguaje, pero lo m�s usual es escribirlo en Perl o
C.


> Cuarta pregunta (y �ltima por que te tendr�s que ir a dormir):
> Leyendo un poco he encontrado algo llamado "socket", �AH!, que bonita
> palabra, la voy a escribir otra vez.... socket!.

> L�stima que no sepa lo que es!.
> Eso s�, intuyo que algo tiene que ver con lo del escuchar.

Los sockets son los "canales" a trav�s de los que se comunican los programas
mediante TCP/IP. Y efectivamente... para que un proceso cliente pueda abrir un
socket en un puerto de una m�quina remota, previamente tiene que haber un
proceso servidor escuchando en dicho puerto.

Por ejemplo, cuando tu navegador llama a http://www.netscape.com, en realidad
est� intentando abrir un socket con el puerto 80 de la m�quina www.netscape.com.
Y, por supuesto, el servidor Web se encuentra previamente escuchando en ese
puerto.

Para m�s info en castellano sobre la utilizaci�n de sockets en Java:
http://www.akal.com/chano/

Un saludo.

Chano.