Con un mp con vuestra cuenta de google os doy el acceso, sip.
El SVN anónimo no me chuta :/ Me dice que no existe.
Voy a probar con algún proyecto que tengo yo en googlecode, a ver si es problema suyo.
svn co http://mv6lib.googlecode.com/svn/trunk/ mv6lib-read-only
svn: El URL 'http://mv6lib.googlecode.com/svn/trunk' no existeedit: pues he probado con uno que tengo yo por ahí y no me ha dado problemas...igual no está el dominio ese aun? Creo recordar que tardaba un poco en activarse
Vale, soy idiota, hay que poner esto, y no lo que pone:
svn co http://mv6lib.googlecode.com/svn/ mv6lib-read-onlyQue no hay trunk xDD
Mira a ver si puedes editar lo que pone en la página de "Source", por evitar confusiones
Coño que interesante! Pena que tenga 0 ganas de ponerme pero bueno, a ver si un día aburrido me pongo a hacer algo, aunque sea a hacer pruebas. Podíais poner ideas de lo que vais a hacer u os gustaría que hiciesen xD
Añadí al SVN los amigos, pero he visto que en los perfiles, aunque el contador te ponga 83, en la página dedicada nada más que te salen 50 y no hay manera de ver el resto. He visto que en el hilo de bugs de MV6 está reportado, así que será cuestión de esperar.
A ver si reparo lo del /trunk, que Google Code no me deja cambiar esa página 
Ninja-edit, un clásico:
Se puede hacer una utilidad, sí. Me lo apunto como urgente y así se programa de manera que se haga la menor cantidad de peticiones al servidor posible.
Ya lo he añadido, está en la versión del svn.
Ejemplo de uso:
Vector<Post> p = new Thread(351952).getPosts(25, 35);
for(int i = 0; i < p.size(); i++) {
System.out.println("#" + p.get(i).getPostId() + " por " + p.get(i).getAuthor());
}
Eso te descargaría 2 páginas (la correspondiente a los posts 25-30 y la del 31 al 35). Este método hay que usarlo con moderación, en una aplicación deberíamos ir cargando páginas bajo demanda y cachear todo lo posible. Lo suyo sería simplemente descargar, como mucho, el contenido de la página que estamos leyendo y el de la siguiente, no todo el hilo del tirón.
Usando este método no hace falta llamar al refreshPost() de cada Post, ya lo hace automáticamente.
El amote 
Estaba bloqueado con eso.
Del SVN, ¿me tengo que bajar las fuentes y compilarme yo el jar para meterlo en el proyecto de netbeans?
Sólo he echado un vistazo rápido al código pero te puedo dar un consejillo para que tu libería esté mejor estructurada para funcionar como una API.
Lo primero sería escribir una sola interface que declare todos los métodos públicos de tu API, como podrían ser getPost(), getForum(), getUser(), etc que devuelven instancias de Thread, Post, Forum, etc. Una vez hecho esto creas una clase que será el servicio que implemente dicha interface y a la vez punto único de acceso a la API. Esta clase podría ser un singleton para así no tener que preocuparse de instanciarla y configurarla correctamente ya que podrías externalizar los parámetros a un fichero .properties por ejemplo y que al llamar a getInstance() los lea y se autoconfigure (por parámetros me refiero a cosas que ahora van hardcodeadas, como la url de la web, pero también podrías externalizar incluso las expresiones regulares o imponer límites al número de páginas que puedes pedir en cada consulta). También podrías definir que esta clase cachee el contenido descargado y llame al método refresh() automáticamente cuando se vuelva a solicitar y haya pasado más de X tiempo.
¿Cúal es la razón de definir una interface para dicha clase? Pues que cuando tu creas una API sólo declaras su interface, no su implementación, ya que son cosas independientes. Así cualquier otra persona podría reescribir la clase que la implementa a su manera pero respetando la misma interface y cualquier herramienta que dependa de tu librería seguiría funcionando sin modificar nada. La interface a su vez se puede ampliar en futuras versiones e incluso manetener la compatibilidad con métodos viejos y marcarlos como deprecated para retirarlos por completo más adelante.
A la hora de usar tu librería, uno sólo tendría que obtener una referencia al singleton y ya está, tendría acceso a todos los métodos que proporcionan contenido sobre la web.
Una implementación alternativa interesante de dicha interface sería por ejemplo que tuviera un pool de Threads (y me refiero a java.lang.Thread) para poder atender las peticiones http con múltiples hilos a la vez en vez de hacerlo secuencialmente, lo cual sería mucho más rápido.
Buen análisis PiTaGoRaS. Yo he tenido que implementar un modelo singleton en el curro en los últimos meses en PHP (que es el lenguaje que conozco y que modestamente controlo de puta madre) y funciona muy bien. En PHP se hace (más o menos) igual pero a base de objetos static y instancias "a si misma".
Lo que he hecho es un framework -caserillo- estructurado como MVC con determinadas librerías en singleton, en lugar de objetos normales que referencian con "$this". Como dices tu, no sólo la llamada si no a la hora de extender (extends en PHP) es más manejable, más solido y lógico (para mi gusto, y para la lógica de mi aplicación).
Ahora estoy investigando un poco los nuevos namespaces de PHP que me pueden venir bien para que ese modelo sirva como entidad completa para varios programas.
Este asunto del inferfaz lo comentaba unos post atrás, en las que yo comentaba que sería mejor una comunicación por xml servidos directamente por MV con un interfaz con PHP que respondiera via web a una serie de métodos (getPost, etc) pero claro, eso es tiempo y trabajo xD
Por cierto, no he programado casi nada en java y por lo que parece me migran a java en los próximos meses 
Espero no olvidarme de todo lo que sé ya de PHP, tendré que hacer proyectillos para no olvidarme. Aunque está bien saber que controlas java, por que me van a brear sin duda durante estos meses y tendré que darte el coñazo xD
#41 Sí, si tiras del SVN te tendrías que descargar el contenido y compilarlo tú mismo... o esperar a que vaya subiendo los .jar compilados a la sección de downloads. Acabo de subir la RC3 que ya incluye este tema.
#42 Pues muchas gracias PiTaGoRaS, lo adaptaré a la forma que comentas, seguro que es mucho más sencillo luego para el que la utilice si nada más se tiene que preocupar por una instancia y no por todo el contenido interno que la mueve. Me apunto también lo del singleton y los hilos que se van a encargar de ir descargando las páginas.
Ninja-edit: #43 Échale un ojo a Thinking in Java, que está genial (hay una versión en español, pero es la 2nd Edition y la traducción es chunga).
Lo suyo sería claro, como ya se ha comentado, que todo esto se empaquetara como un web service corriendo en el servidor de mediavida y expusiera la API públicamente a través de SOAP o XML-RPC, pero para eso tienes que convencer al letto & company xD
SiCk yo programaba cositas en PHP4 hace unos añitos ya pero luego me pasé a Java y llevo 3 años trabajando practicamente sólo con eso, así que el PHP lo tengo bastante olvidado la verdad.
#45 No creo que sea por falta de voluntad... pero creo que aún hay una larga lista de bugs de mv6 por corregir...
Vale, ya tengo la clase Singleton y voy a eliminar la necesidad de hacer un refreshPost() para que se conecte a la página. Si una clase detecta que no tiene información, que la descargue. Así simplificamos a esto:
System.out.println(Singleton.getInstance().getMember("PiradoIV").getNick());
System.out.println(Singleton.getInstance().getPost(367539, 2).getAuthor());
// etc...¿Mejor así?.
Estoy pensando en la manera de hacer un queue de páginas a descargar, mantener actualizadas de información las instancias y avisar si se han encontrado cambios... en plan... broadcast de que un usuario tiene una nueva firma, un hilo tiene nuevas respuestas, etc. ¿Qué os parece?.
Yo lo que haría es que la clase Singleton (que no tiene por qué llamarse así por cierto, eso es sólo el nombre del patrón de programación xD) expusiera uno o varios métodos en la API para añadir objetos de tipo Thread, Post, Forum, etc a monitorizar. Estos objetos se añaden a una lista interna de monitorización que se actualizaría regularmente con un hilo corriendo en background (ojo al tema de la sincronización entre hilos). Cuando se dectecta un cambio se podría sacar por pantalla por ejemplo o, más currado, llamar a una clase callback que se haya pasado como parámetro al principio y ejecute una acción específica para ese objeto monitorizado.
Estaría guapo tener un avisador de firmas xD A mi siempre se me pasan.
edit: on a second thought... creo que esto de la cola de monitorización debería sacarse de la clase que implementa la API y hacerse en el lado "cliente". Creo que esa arquitectura tiene más sentido puesto que la API sólo debería proveer métodos para hacer consultas a la web, luego lo que se construya alrededor de eso son clases o proyectos separados que dependen de la librería.
¡Un ejemplo real de uso!: Evolución de usuarios online en las últimas horas.
¿Cómo funciona?:
Mediante mv6lib, se van pillando los usuarios que hay online cada 5 minutos y se van metiendo en una base de datos. Luego se genera la gráfica en tiempo real mediante PHP con GD2.
Ninja-edit: La linea blanca son los usuarios online, las rojas son hilos nuevos/borrados, la verde son posts nuevos/borrados.
Estoy con #48 en separar las monitorizaciones del API, pero sí que incluiría un thread pool para acelerar las peticiones HTTP (el nº de threads parametizable para no ahogar el UPLOAD del cliente).
Salu2 
