A draft agenda to discuss these topics.
- Should it be a library at all? (5 min) There are good arguments not to do this.
- How should it be reorganized? (10 min)
a. Extract library to another repository, add dependency. Most effort, most commitment.
b. Keep everything in 1 repo, use lerna to separate packages. More effort, less commitment.
c. Keep everything in 1 repo, follow lib/client style in Girder Web Components. Least effort, lowest commitment
- What should go in the library? ( 10 min)
a. Some of src/components/*.Vue
b. All of src/components/[layers|annotators|controls]
c. Some of src/use, like trackstore, selection, filters, and event chart and line chart
d. src/lib except for src/lib/api and probably also not src/lib/vue-utilities
e. Anything else?
- Packaging and distribution. (10 min) Nobody uses GWC as a UMD: it's exclusively imported as source code. Should we even bother packaging? It would be nice to compile the typescript parts to es6 so consumers aren't forced to configure typescript on their projects. Rollup would be perfect for this, and I think I'd like to set that up at some point, but that may be premature. For now, maybe just publish the raw source code and let consumers deal with it? Does vite provide similar features to rollup that we could use to transpile ES6 for publishing?
- Marketing/Identity. (5 min)
a. So far I've been thinking of 'VIAME Web' as the web application we're building for NOAA. If another project were to use some of the capabilities of the library, I think it's very important for marketing purposes to make sure that those customers understand that what they're using isn't associated with VIAME.
b. In other words, I want to tell people, "VIAME Web is built with _____. You can use _____ on your project too."
c. For the past little bit, something like libswim or swim-js has been knocking around in my head. Kitware has a tendency to use tortured acronyms, and I'd rather not do that. I think the name should pay obvious homage to it's "parent" project while also having a distinct identity. We will need clear messaging about what VIAME is, what the library is, and which you should use for your project.
d. I only care about internal brand/marketing. Thinks like SEO, name collision with external projects, etc. are irrelevant to me. Others may feel differently.
- Scope creep. (5 min) When other projects inevitably (immediately) want to start adding new features to this library, we should have some kind of roadmap/design doc/philosophy with which to measure the idea. For the time being, I think it'd be fair to require that all feature requests to the library be able to also demonstrate value to VIAME Web (the project or the interface). If you can't explain how it will help VIAME, it doesn't belong in the lib.
A draft agenda to discuss these topics.
a. Extract library to another repository, add dependency. Most effort, most commitment.
b. Keep everything in 1 repo, use lerna to separate packages. More effort, less commitment.
c. Keep everything in 1 repo, follow lib/client style in Girder Web Components. Least effort, lowest commitment
a. Some of
src/components/*.Vueb. All of
src/components/[layers|annotators|controls]c. Some of
src/use, like trackstore, selection, filters, and event chart and line chartd.
src/libexcept forsrc/lib/apiand probably also notsrc/lib/vue-utilitiese. Anything else?
a. So far I've been thinking of 'VIAME Web' as the web application we're building for NOAA. If another project were to use some of the capabilities of the library, I think it's very important for marketing purposes to make sure that those customers understand that what they're using isn't associated with VIAME.
b. In other words, I want to tell people, "VIAME Web is built with _____. You can use _____ on your project too."
c. For the past little bit, something like
libswimorswim-jshas been knocking around in my head. Kitware has a tendency to use tortured acronyms, and I'd rather not do that. I think the name should pay obvious homage to it's "parent" project while also having a distinct identity. We will need clear messaging about what VIAME is, what the library is, and which you should use for your project.d. I only care about internal brand/marketing. Thinks like SEO, name collision with external projects, etc. are irrelevant to me. Others may feel differently.