Aide sur architecture de solution

Bonjour,

Pour mon boulot je dois passer par un éditeur web pour coder des web apps. L'éditeur est basé sur Che —l'Eclipse web edition— et c'est buggé à souhait. On reste cependant sur une architecture client serveur donc avec un peu de reverse engineering j'ai pu définir comment fonctionne l'API et je vais pouvoir à terme travailler avec des fichiers locaux synchronisés avec le backend au travers d'une app sur la machine client. Les tests sont concluant.

Voilà les morceaux qu'il me faut :

  • un qui s'occupe de la communication avec l'API.
  • un watcher qui scrute les changements sur le disque.
  • un central engine qui gère l'état des fichiers, la synchronisation, etc..

Pour le moment je compte faire ça avec une seule app monolithique qui utilise GCD pour les appels réseau. Mais je me demande si ça n'est pas le bon moment pour mettre les doigts dans les XPC avec :

  • L'app qui sert de central engine.
  • Un XPC pour scruter le disque.
  • Un XPC pour la gestion de l'API.

Je n'ai jamais utilisé cette techno, j'ai une bonne connaissance générale de la com inter-process mais ça remonte à mes TP, je n'ai pas eu à les utiliser depuis lors. Ou presque pas.

Ce qui fait que je me demande si :

  • L'architecture que je propose est viable (deux XPC n'est-ce pas un de trop, ou deux...)
  • Vous avez des conseils sur l'emploi de cette techno ou un autre avis sur l'architecture.

Pour le moment je vais commencer à coder les différentes parties et les tester je pourrai réorganiser par la suite.

Merci 😃

Mots clés:

Réponses

  • Personne n’a un avis sur la question ?
  • Dissocier certaines parties "potentiellement critiques" de l'application dans des XPC est un bon choix. De plus ce projet te sert pour mettre le pied à l'étrier de cette technologie c'est encore mieux.
    Personnellement je ne vais qu'abonder dans ton sens et je ne trouve rien à redire dans ton choix.

    Cela dit, et uniquement par curiosité et pour voir si j'ai bien compris, qu'elle est l'API sur laquelle tu as effectué le RE ? Celle de Eclipse WE ou une autre partie ?

  • @Pyroh a dit :
    Personne n’a un avis sur la question ?

    Ça t'aide si je te dis que je ne sais pas ce qu'est un XPC ?

  • PyrohPyroh Membre
    janvier 2019 modifié #5

    @Draken a dit :

    Ça t'aide si je te dis que je ne sais pas ce qu'est un XPC ?

    Non 😧

    @Lexxis a dit :
    Dissocier certaines parties "potentiellement critiques" de l'application dans des XPC est un bon choix. De plus ce projet te sert pour mettre le pied à l'étrier de cette technologie c'est encore mieux.
    Personnellement je ne vais qu'abonder dans ton sens et je ne trouve rien à redire dans ton choix.

    Cela dit, et uniquement par curiosité et pour voir si j'ai bien compris, qu'elle est l'API sur laquelle tu as effectué le RE ? Celle de Eclipse WE ou une autre partie ?

    Plus je réfléchis à la question plus je me dis qu'il me faut un XPC pour la partie communication avec l'API certes mais il me faudrait aussi un helper. Une app faceless qui s'occupe de tout et qui se pilote depuis un GUI. Donc il me faut un helper mais je trouve très peu de documentation sur comment l'implémenter.

    Quelqu'un a une idée de comment gérer un helper qui fasse autre chose que lancer une app sandboxée au boot ? C'est surtout la communication entre ce helper et le GUI qui m'intéresse.

    Pour ce qui est de l'API en elle même c'est du produit SAP basé sur Eclipse WE donc c'est quelque chose de très spécifique. Tout ce que je peux dire d'intéressant est que c'est l'API qui permet au frontend en javascript de communiquer avec le backend. Je n'ai aucune info sur le backend.
    J'ai trouvé comment faire des opérations CRUD sur la liste des workspaces, des projets et des fichiers. Le reste ne m'intéresse pas parce qu'il est potentiellement buggé.

  • "gérer un helper" que veux tu dire ?
    Tu veux donc avoir une application qui officie en tâche de fond même si ton application principale n'est pas lancé ? Faut-il vraiment cela, un XPC ne serait-il pas suffisant ?
    Pour la communication je pense que tu as le choix, socket, shared memory, machport, distributed object (runtime cocoa). Certaines méthodes ne sont pas compatibles avec les apps sandboxés et pour d'autres il faut utiliser le même "application group".

  • tabliertablier Membre
    janvier 2019 modifié #7

    @Draken a dit :
    Ça t'aide si je te dis que je ne sais pas ce qu'est un XPC ?

    Ouais, ce n'est pas la première fois que j'entends ou lis "XPC" mais je ne sais toujours pas ce que c'est !

  • muqaddarmuqaddar Administrateur

    @tablier a dit :

    @Draken a dit :
    Ça t'aide si je te dis que je ne sais pas ce qu'est un XPC ?

    Moi, c'est la première fois !

  • Voir la session 241 sur youtube spécial XPC

    https://youtube.com/watch?v=2vvHlK3DvTM&t=856s

  • @Lexxis a dit :
    "gérer un helper" que veux tu dire ?
    Tu veux donc avoir une application qui officie en tâche de fond même si ton application principale n'est pas lancé ? Faut-il vraiment cela, un XPC ne serait-il pas suffisant ?
    Pour la communication je pense que tu as le choix, socket, shared memory, machport, distributed object (runtime cocoa). Certaines méthodes ne sont pas compatibles avec les apps sandboxés et pour d'autres il faut utiliser le même "application group".

    Alors l'architecture que j'ai décidé d'explorer est la suivante :

    • Un helper qui se lance automatiquement. En fait une app complète mais faceless qui s'occupe de tout en background et qui tourne tout le temps (c'est la technique du LoginItems)
    • Un ou plusieurs XPC Process pour la communication avec l'API et pilotés par le helper.
    • Une GUI qui communique avec le helper via le protocol XPC (visiblement ça se fait)

    Le helper n'est pas un XPC Process pour la simple et bonne raison que d'après la doc ils sont stateless (pas pratique) et surtout qu'il peuvent être killé par l'OS à tout moment (vraiment pas pratique).

Connectez-vous ou Inscrivez-vous pour répondre.