Oxylus a écrit 2 commentaires

  • [^] # Re: Et la licence...

    Posté par  . En réponse au journal Présentation d'Oxylus. Évalué à 1 (+1/-0).

    Je pensais potentiellement la passer sous MPL

  • [^] # Re: Rien compris

    Posté par  . En réponse au journal Présentation d'Oxylus. Évalué à 5 (+6/-1).

    Pas de soucis.

    Je ne suis pas très doué pour résumer…

    Alors à quels besoins ça répond?
    - Développer des applications/plateformes web fournissant rapidement les outils et besoins de base (gestion des permissions automatisée, etc.);
    - À offrir aux utilisateurs une plateforme répondant à leurs besoins et au besoin avec des applications customs. Similaire à un ERP ou bien un CMS type Wordpress avec ses milliers d'extensions. Mais sans la spécificité de base de chacun: soit un ERP, soit un CMS dont on détourne/étend les usages et le scope;

    Oxylus se comprend sous deux angles:

    • Un framework permettant de développer des applications custom dans une interface unifiée offrant déjà tout un ensemble de composants (frontend et layout, composants d'UI, gestion des permissions, API etc). Il se base sur une intégration entre Vue/Vuetify et Django.
    • Un ensemble applicatif pouvant être réutilisé pour différents cas d'usages: la gestion des utilisateurs, la configuration de compte mails, gestion de tâches en arrière plans, etc. Ce qui permet de développer et fournir un outil qui intègre déjà les interfaces et les workflows utilisateurs.

    La partie applicative est divisée en projets. Les projets sont sur base thématique:

    • Oxylus: les applications de base, comme la gestion des utilisateurs/groupes/permissions;
    • Oxylus ERP: les applications qui sont en lien avec des humains, des organisations, et par la suite tout ce qui est relatif à de l'ERP. Par exemple, des sets de données sont déjà fournis pour ce qui est type d'organisations, informations ISO sur les pays, etc.
    • Oxylus AI: (pas encore présent) pour les applications en lien avec l'IA (chatbot, setup & run LLM, intégration avec Django, etc.)

    À terme bien sûr c'est de pouvoir développer assez d'application que pour permettre à l'utilisateur d'installer la plateforme avec toute une série d'applications qui réponde à ses besoins.

    Je phantasme, mais prenons par exemple une coopérative avec une liste de membres, avec potentiellement comme besoins: CMS, Eshop, gestion de stock, comptabilité, gestion des membres. Beaucoup vont utiliser une base avec Wordpress qui est un CMS, puis ajouter plein d'addons afin d'en étendre les fonctionnalités (eshop, newsletter, etc). Soit on se retrouve avec plein d'addons incompatibles, soit on finit avec des usines à gaz avec tous les problèmes de compatibilité (sans compter le système de thème horrible de WP).

    Ici l'idée c'est que ces applications soient interopérables et que les efforts de développement puissent être concentrés sur une base cohérente. Que les utilisateurs puissent les installer selon leurs besoins et configurer eux-mêmes ceux-ci. Par exemple, la gestion des membres et la comptabilité vont avoir besoin de contacts (d'où l'application erp.contacts)

    Voilà, je ne sais pas si c'est plus clair…