Skip to content
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

Save relevant device info when initially creating/adding a project #289

Closed
achou11 opened this issue Sep 28, 2023 · 2 comments · Fixed by #297
Closed

Save relevant device info when initially creating/adding a project #289

achou11 opened this issue Sep 28, 2023 · 2 comments · Fixed by #297
Assignees

Comments

@achou11
Copy link
Member

achou11 commented Sep 28, 2023

Description

When creating a project instance via MapeoManager using createProject() or addProject(), the project instance should attempt to write to its deviceInfo store with information from MapeoManager.getDeviceInfo(). A couple of ideas for approaching:

  1. Pass the device info as a constructor param for MapeoProject, which is then used when instantiating

  2. Expose a method on MapeoProject to add that info and then call it from the consumer after the instance is created. Maybe in the $member namespace i.e. project.$member.add(deviceId, info). e.g.

// From MapeoManager...
// `addProject` would be similar

async createProject() {
  // ... 

  const project = new MapeoProject({...})
  
  const selfDeviceInfo = await this.#getDeviceInfo()
  
  project.$member.add(this.#deviceId, selfDeviceInfo)
  
  // ...
}

One potential advantage for 2 is that it could also be used by MemberApi.invite(), which lives in the MapeoProject, We currently don't save the device info if the invite is accepted (currently only update the capabilities). Believe we still need #245 but once that's in place, we can update the implementation like so:

if (response === InviteResponse_Decision.ACCEPT) {
+ await this.#add(deviceId, deviceInfo) // device info would come from rpc invite response
  await this.#capabilities.assignRole(deviceId, roleId)
}

Tasks

  • [ ]
@achou11
Copy link
Member Author

achou11 commented Oct 2, 2023

additional questions related to this:

  • should my device info be the same across all of my projects? for example, I consider the following sequence:
  1. I call myself andrew via MapeoManager.setDeviceInfo()
  2. I create a project foo. i am known as andrew in project foo.
  3. I add project bar. i am known as andrew in project bar.
  • should changing my device info immediately update all (active) project instances? following the above sequence, let's say:
  1. I call now myself andy on a device level via MapeoManager.setDeviceInfo()
  2. Am I known as andy in foo and bar? If so, is this done automatically after 4, or does the code have to call some other api in order to update the relevant projects?

Questions arising from the above:

  • is it useful to have different device info about yourself per project? this suggests that the device-level info is more of a default/fallback in case you haven't explicitly set that information about yourself for the project
    • if yes, should we expose some kind of api on MapeoProject that's specifically about updating your device info for a specific project? in theory, we could just expose the deviceInfo datatype that already exists internally in the project instance using a namespace e.g. project.$deviceInfo

@gmaclennan
Copy link
Member

additional questions related to this:

  • should my device info be the same across all of my projects? for example, I consider the following sequence:
  1. I call myself andrew via MapeoManager.setDeviceInfo()
  2. I create a project foo. i am known as andrew in project foo.
  3. I add project bar. i am known as andrew in project bar.

Initially, yes. For others in the project to know who you are, the name needs to be written to a project core, so in the case above, the project creation / project add function needs a step to set the device name based on the "global" device info.

In the future we might allow peers other than the device owner to set the name (and additional metadata). In this case we would not want to change the "global" device info - this would be a project specific name. There are UX questions around this though - would it cause confusion for users?

  • should changing my device info immediately update all (active) project instances? following the above sequence, let's say:
  1. I call now myself andy on a device level via MapeoManager.setDeviceInfo()
  2. Am I known as andy in foo and bar? If so, is this done automatically after 4, or does the code have to call some other api in order to update the relevant projects?

Yes, it should change the name for all projects known on the device (not just "active" ones). This needs to be done by writing the project device info.

Questions arising from the above:

  • is it useful to have different device info about yourself per project? this suggests that the device-level info is more of a default/fallback in case you haven't explicitly set that information about yourself for the project

There are use-cases for this, but we haven't figured out the UX yet, so we're just treating device name as one-per device, and hiding the fact that there is a separate record for each project. The main use-case that I have heard is when a project coordinator wants to name devices, rather than allowing users their own choice. One thing that this helps is being clear about which devices are part of the project - it stops a user renaming their project device name to the name of another device in order to "secretly" remain in the project.

  • if yes, should we expose some kind of api on MapeoProject that's specifically about updating your device info for a specific project? in theory, we could just expose the deviceInfo datatype that already exists internally in the project instance using a namespace e.g. project.$deviceInfo

Eventually, yes, For now it can be an internal API only, which is called from within MapeoManager.setDeviceInfo()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants