Me estoy poniendo al día con este hilo, pero ciertamente creo que la respuesta es sí
Debido al éxito de nuestra comunidad empresarial (tanto con nuestros usuarios como dentro de nuestro negocio), nuestro equipo de documentación se acercó y nos preguntó si podíamos crear un sistema de comentarios para toda la documentación de sailpoint.com. Por lo que parece, podremos hacer casi todo lo que queremos lograr como mínimo:
Incrustar comentarios (función de incrustación)
También queremos usar diferentes usuarios para publicar y aplicar diferentes conjuntos de etiquetas, según la incrustación. Esta función llegará muy pronto:
A partir de ahí, todo lo demás que el equipo de documentación (y mi equipo) quería estaba dentro de Discourse para que pudiéramos segregar efectivamente esta experiencia del resto de nuestro uso del foro “del día a día”, al tiempo que brindamos a las personas la capacidad de comentar, recibir notificaciones de respuestas, etc.
Capacidad para designar qué usuarios pueden y no pueden comentar
Asignar moderadores de categoría a los temas asociados
Suprimir esta plétora de categorías para estos documentos de nuestro sitio principal
categoría no se puede buscar
componente temático utilizado para ocultarlo de la lista principal de categorías
suprimido del resumen
agregado a las categorías silenciadas predeterminadas
Comentarios eliminados después de n días
Algunas otras configuraciones…
¡Definitivamente me encantaría ver implementadas muchas de las funciones mencionadas aquí!
¿El objetivo es permitir a los usuarios crear comentarios en https://documentation.sailpoint.com/, o está bien con solo incrustar los comentarios en el sitio de documentación y que los usuarios visiten su sitio de Discourse para comentar los artículos?
El primero es una característica que agradecería y me encantaría tener (es decir, por favor, constrúyanla, CDCK), pero la segunda cumple nuestros requisitos mínimos, al menos.
De hecho, exploraré una idea en el futuro cercano de hacer que Discourse sirva nuestra documentación markdown (no, no en temas, sino en documentos tradicionales de estilo markdown) en cuyo caso los comentarios, y el registro para hacerlos, serían inclusivos. Pero esa exploración aún no ha comenzado.
Con el enfoque en el que estoy trabajando ahora, sería técnicamente posible permitir que los comentarios de Discourse se generen directamente en las páginas de MkDocs, pero requeriría el uso de un framework del lado del servidor (Remix, Rails, etc.) para servir las páginas de MkDocs. Eso haría posible autenticar a los usuarios (con DiscourseConnect) en el sitio de documentación y también permitiría usar una base de datos en memoria para almacenar en caché los comentarios devueltos anteriormente.
(Edición: solo para aclarar, estoy hablando de usar Discourse como proveedor de identidad para el sitio web, no el sitio web como proveedor de identidad para Discourse. Este último enfoque funciona, pero es demasiado inflexible para la mayoría de los casos de uso).
Sin embargo, sería un gran cambio pedirle a su equipo que lo haga.
Estoy seguro de que desde su perspectiva sería más sencillo si esto se lograra completamente dentro de Discourse, pero también es posible usar Discourse como un sistema de gestión de contenido. En ese caso, la documentación de markdown se generaría como temas regulares de Discourse. Se usarían webhooks de Discourse para activar la generación de una página de documentación en un sitio externo. Esa es, de hecho, la base del sitio de demostración de comentarios de Discourse que estoy configurando.
Dado que este tema fue enlazado hoy, pensé que debería actualizarlo con las conclusiones a las que llegué después de dedicarle algo de trabajo a la idea.
Sigo pensando que Discourse sería una buena plataforma de comentarios por las razones que expuse en el OP.
En cuanto a cómo hacerlo, creo que el trabajo debe hacerse en el lado de Discourse, idealmente mejorando el script de incrustación de comentarios de Discourse. Esto podría hacerse de forma incremental.
Técnicamente es posible usar Discourse como servidor para una plataforma de comentarios haciendo todo el trabajo en un cliente de Discourse (por ejemplo, el plugin WP Discourse), pero debido a tener que gestionar el estado entre el cliente y Discourse, y evitar problemas de limitación de velocidad, se convierte en un problema complejo. Es definitivamente más complejo de lo que quiero ser responsable de mantener.
Algunas publicaciones en este tema indicaron que la gente estaría interesada en simplemente permitir a los usuarios crear comentarios de Discourse en un sitio de blog. Desde mi punto de vista, no es una gran solución, pero se puede lograr ahora con la API de Discourse. Donde las cosas se complican es al intentar crear un sistema de comentarios completo, donde los usuarios puedan interactuar con los comentarios de Discourse en un sitio web de manera similar a como esperarían interactuar con los comentarios en un sitio de noticias típico y convencional.
Dada mi experiencia con ActivityPub y WP Discourse, creo que los comentarios bidireccionales a través de JavaScript incrustado son factibles. El script de incrustación contendría lo siguiente:
“Lectura” no autenticada que funciona de manera similar al script de incrustación actual (con algunas optimizaciones).
Cliente remoto (es decir, el navegador del usuario) registra un cliente de clave API de usuario, específico para la sesión del usuario y almacena los detalles relevantes en el almacenamiento local del navegador.
Se le presenta al usuario “Iniciar sesión para comentar”.
El usuario se autentica (con Discourse) para recuperar una clave API de usuario de sesión que se almacena en el almacenamiento local del navegador.
Cada actividad (comentario, me gusta, etc.) se publica directamente en un punto final dedicado con las salvaguardias, el manejo y la gestión de tareas apropiados.
Con el presupuesto adecuado, creo que podría tener la v1 lista para producción e integrada con discourse/discourse en 6-8 meses. Después del lanzamiento inicial, podría hacer lo siguiente:
Agregar soporte explícito para Wordpress, Ghost y otras plataformas seleccionadas.
Intenta implementarlo de una manera que tenga sentido para usuarios no técnicos. Plataformas existentes como Disqus y los comentarios de Facebook probablemente ofrezcan buenos ejemplos.
Algunas opciones de autenticación más:
el sitio cliente se convierte en un cliente de DiscourseConnect. Esto es sencillo de implementar, pero requiere código adicional del lado del servidor en el sitio cliente.
los usuarios inician sesión directamente en Discourse a través del iframe
Mi reticencia a desarrollar esto puramente en el lado del cliente provino de considerar los problemas del sistema funcionando a cualquier tipo de escala. Esencialmente, tuve que poner en cola las solicitudes de la API y manejar las respuestas de las solicitudes en cola. No me pareció lo suficientemente robusto para lidiar con, digamos, 1000 usuarios concurrentes. Tendría preocupaciones similares, pero por diferentes razones, con el enfoque de incrustación de javascript. Sospecho que sería mucho más fácil de manejar que intentar sincronizar todo en el cliente.
Le di más vueltas a esto ayer, ya que el tema se retomó (por eso terminé publicando aquí). Creo que una solución solo para el cliente (es decir, un script incrustado de JavaScript) es la única que realmente tiene sentido aquí. De lo contrario, estaríamos hablando de una serie de implementaciones específicas de la plataforma, cada una con su propio conjunto de problemas.
Tienes razón en que la concurrencia y la carga son problemas. Hay problemas significativos de carga y concurrencia con ActivityPub, ya que una sola publicación de ActivityPub puede exponerte a muchas solicitudes entrantes y salientes desde y hacia el Fediverso. En ese contexto, esto puede ser en realidad un poco más fácil, ya que los clientes remotos están controlados. Además, en este caso, la concurrencia y la carga solo son realmente problemas en el lado del servidor (es decir, en el lado de Discourse) y, aunque son problemas, creo que deberían resolverse mediante trabajos en segundo plano, caché y mutex. Pero sí, son problemas importantes a considerar.
Para ser honesto, mi mayor preocupación aquí es el tiempo.
Composer v2 está a la vuelta de la esquina, sería una locura embarcarse en esta aventura y no apoyarse en nuestro nuevo composer, pero hay una gran cantidad de trabajo que necesitamos por adelantado para que sea factible usarlo en una aplicación ligera.
Creo que lo correcto aquí es observar este espacio para el nuevo composer durante, digamos, 2-3 meses y luego volver a examinar la cuestión.
Creo que se puede hacer en paralelo. Necesitas hacer 2 cambios en el discurso.
El botón “Responder” debe ser visible para los usuarios no registrados.
Y cuando los usuarios no registrados hagan clic en este botón, se debería mostrar esto:
A continuación, necesitas averiguar cómo utilizar la inserción de comentarios. Es probable que se trate de pequeños cambios de código en lugar de mucho trabajo.
Me pregunto si todavía hay interés en desarrollar esta función, ahora que Composer v2 está disponible. Voto porque todavía es algo que me encantaría ver y usar.
