Pour contourner l’impossibilité de gérer les droits sur des « espaces » au sein d’un même atelier, nous créons un atelier par projet client.
Cet atelier est une copie d’un atelier modèle contenant bcp d’information.
Nous avons besoin que cet atelier soit indépendant de notre atelier modèle, donc nous ne pouvons passer par un atelier dérivé.
Nous avons donc opté pour la solution « de base » : sauvegarde de l’atelier modèle puis création de l’atelier copie à partie de la SVG.
Le souci c’est que comme l’atelier modèle est conséquent, l’export et le rechargement dans un nouvel atelier sont très longs… alors que la création d’un atelier dérivé est instantanée.
N’y aurait-il pas moyen de déconnecter un atelier dérivé de son parent ?
Si la création d’un atelier dérivé est instantané, c’est parce qu’il n’y a aucune duplication du contenu, mais de simples références logiques « virtuelles ». « Déconnecter » un atelier dérivé de son parent revient à faire ce que tu fais manuellement : tout dupliquer.
Peux-tu préciser le « conséquent » :
combien d’items
volume de l’archive
ratio items binaires (images, audio, video, pdf…) / items xml
temps d’export et temps d’import ?
Il est possible que l’essentiel de la lourdeur soit dans la phase d’export et d’import à travers le réseau, surtout si vous avez beaucoup de ressources binaires. Si c’est le cas, la solution serait que nous ajoutions des fonctions de duplication inter-ateliers directement, sans passer par cette logique d’export et de réimport. Nous avons rencontré assez peu d’usages de cette fonction, mais si l’usage est là on pourrait envisager de les ajouter.
PS: je précise un détail pour les autres lecteurs : " l’impossibilité de gérer les droits sur des « espaces » " en LECTURE. Les droits sur les espaces d’un atelier permettent de restreindre les droits en écriture, mais pas en lecture car il y a un conflit logique entre les liens inter-items partagés par tous et des restrictions de droits qui ne seraient pas identiques entre tous les utilisateurs.
Merci pour ces infos.
Je ne sais pas vraiment comment identifier les volumes de data que tu cites…
En revanche, je déduis déjà de tes explications, les « bonnes pratiques » suivantes :
1 - l’intérêt manifeste de « stocker » au maximum nos ressources « binaires » dans un atelier public.
2 - pour produire des contenus (xml) dans les ateliers de production dédiés (et qui feront appel aux données binaires via des liens inter-ateliers). Ces ateliers de prod. seront ainsi bcp plus légers à importer/exporter.
Il est certainement probable que le BEST du BEST serait de déposer les ressources binaires dans un dépôt public pour les appeler via des items « ressources distantes », particulièrement les vidéos.
Cela dit, sauf erreur de ma part, elles seraient plus exposées à la vue de tous qu’en étant stockées dans un atelier public.
Merci de ton retour sur ces différentes affirmations,
ou du partage d’autres pratiques d’autres contributeurs.
Bonjour chez vous !
JPC.
PS : Bien sûr que le développement d’une « fonctions de duplication inter-ateliers directement » serait TOP.
Mais à l’issue des présentes réflexions, je m’aperçois qu’en fait comme ce serait une solution de facilité +++, on aurait tendance à multiplier l’intégration des ressources lourdes dans chaque atelier au lieu de les mutualiser dans un atelier public => consommation de Go sur les serveur… pas écologique cette option… Alors je vais voter pour le non développement de l’option
Je ne sais pas vraiment comment identifier les volumes de data que tu cites…
Par exemple la taille du fichier scar que tu télécharges. Mais tu parles de vidéo, donc j’ai déjà une petite idée : l’essentiel du problème vient probablement de la lourdeur de ces flux binaires qu’il n’est pas bon de faire passer par le réseau…
les « bonnes pratiques » suivantes[…]
Oui à date ce sont les meilleures approches
Cela dit, sauf erreur de ma part, elles seraient plus exposées à la vue de tous qu’en étant stockées dans un atelier public.
Si ton dépot est protégé par un accès authentifié tes videos sur le dépot seront inaccessibles pour un visiteur anonyme. Mais si tes videos sont centralisés dans un seul dossier commun partagé par tous tes clients authentifiés, alors tous tes clients connectés auront accès à ces vidéos. Après tu pourrais affecter les droits manuellement video par video, client par client, mais ca devient vite ingérable. On pourrait imaginer scripter ces affectations de droits, mais c’est un peu de dev. Sinon la brique Distrib pourrait bientôt faire ce travail de gestion de droit « à la pince à épiler », mais là aussi il y a du dev…
on aurait tendance à multiplier l’intégration des ressources lourdes dans chaque atelier au lieu de les mutualiser dans un atelier public => consommation de Go sur les serveur… pas écologique cette option…
Scenari a toujours été conçu avec un souci écologique Donc non, dans SCENARIserver, le même flux binaire dupliqué dans plein d’ateliers différents ne consommera pas plus : nous avons un mécanisme de déduplication de flux identiques (ce n’est généralement pas le cas pour les flux xml si ils contiennent des références vers d’autres items, car ces références sont modifiés à la volée pendant la duplication, les flux xml ne sont donc généralement pas parfaitement identiques).
Clairement, dans ton contexte des fonctions de clonage de contenus intra-serveur mais inter-ateliers auraient un intérêt… Je me le note dans un coin de la tête
Merci pour ces compléments d’infos very instructives.
En REX : on a externalisé nos ressources binaires dans un Atelier public.
Le scar est passé de 200Mo à 25Mo… => temps d’export d’à peine 1 minute + idem temps d’importation
Donc non, dans SCENARIserver, le même flux binaire dupliqué dans plein d’ateliers différents ne consommera pas plus : nous avons un mécanisme de déduplication de flux identiques (ce n’est généralement pas le cas pour les flux xml si ils contiennent des références vers d’autres items, car ces références sont modifiés à la volée pendant la duplication, les flux xml ne sont donc généralement pas parfaitement identiques).
Merci pour ces compléments d’infos very instructives.
