Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Framework API #44

Closed
jakubkoci opened this issue May 15, 2020 · 0 comments
Closed

Framework API #44

jakubkoci opened this issue May 15, 2020 · 0 comments

Comments

@jakubkoci
Copy link
Contributor

jakubkoci commented May 15, 2020

The goal of this issue is to discuss the design of a high-level framework API consumed by the developer using this library.

As I've been thinking about the framework architecture I see it consisting of the following parts/areas:

  • Core Functionality
  • Pluggable Protocols
  • Pluggable Storage

Core Functionality

  • providing crypto services: packing/unpacking messages, signing and verifying signatures, generating and storing keys
  • dispatching inbound messages, responding and sending outbound messages via a specified transport layer
  • emit events about protocol state changes (EventEmitter, Observable, ...) or any other mechanism allowing to react on state updates (aca-py emits event about every protocol state change), but developer should not be enforced to use events listener in her app
  • executing commands (acceptInvitation, provision, downloadMessages, sendMessageToConnection, creating credential, ...)

Plugable Protocols

The idea is to be able to add/remove protocols which developer want to use without changing the core framework part (open-close principle)

...

Plugable Storage

...

API

Framework functionality should be provided via an instance of Agent class:

const agent = new Agent(...)

When a developer creates such instance, then she can access modules. Modules works like facade around similar features of the framework:

agent.connections.createConnection()
agent.connections.acceptInvitation(...)

agent.routing.provision(...)
agent.routing.downloadMessages(...)

...

A module can also provide an event emitter:

agent.connections.events.on('newState', connection => { ... })

Other parts of the framework should be hidden and ideally not possible to export and use outside.

NOTE: This description is still in progress, I'll put some updates soon.

@jakubkoci jakubkoci mentioned this issue Jul 17, 2020
@TimoGlastra TimoGlastra pinned this issue Mar 5, 2021
@openwallet-foundation openwallet-foundation locked and limited conversation to collaborators Aug 20, 2021
@TimoGlastra TimoGlastra unpinned this issue Aug 20, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants