Future Development Proposals

I plan to spend more time working on vanadium in the near future. My goals for this work as follows:

• Generally refresh the code base to take advantage of improvements in the go ecosystem since 2015 and hence make it easier to integrate into other projects.
  1. rework verror to use the new xerrors approach, factor out the i18n aspects from error handling
  2. simplify the vom implementation to make it easier to support in other languages, potentially move vom into its own go module
  3. rework the vanadium context.T to use context.Context.
  4. cleanup the long standing logging mess, I'm considering moving to uber's zap structured logger.
  5. cleanup command line arguments so that other flag/cmdline packages can be used with libraries, implies refactoring the current v23.Init API and implementation. For example, it should only be needed when running an RPC service or client.
  6. rework the inconsistent and noisy apilog godepcop generated logging, by reanimating gologcop currently in the go.devtools repo, regenerating all of the calls to the current/new API structure and making it easier to avoid noisy logging. The noise is particularly annoying for naming related invocations which are recursive.
  7. use ssh-agent extensions instead of the current v23 agent, get rid of the agent code.
  8. use contemporary linting such as goreportcard.com
• Refocus vanadium core and go.lib on cloud-based distributed applications, this implies de-prioritizing mobile and to some extent embedded/IoT uses. Including but not limited to:
  1. removing java and swift support and move them to separate repos
  2. removing syncbase and associated packages
  3. moving all services other than the mounttable out of core.
  4. get rid of the life cycle management and subprocess management services, libraries and internal complexity
• Partition the two use cases of RPC/naming and security (authentication+authorization), so that the latter can be used separately from the first. This may result in the security related packages being moved to a separate go module (fortunately this is now trivial). I have other projects that I'd like to use the security packages for.
• Look at running publicly available mounttable and logind for developers to use - this is one reason I want to trim everything down to the smallest footprint possible since I'll be paying to run this service!
• Update the website to reflect all of this.