search

CasterVoice / caster-core

GNU General Public License v3.0
1 stars 1 forks source link

Improve documentation towards releasing prototype #20

Closed Timoses closed 2 years ago

Timoses commented 3 years ago

LexiconCode stated the following:

I think presenting it as a possible rewrite in the caster channel for "design" feedback would be appropriate. In order to do that you're going to have to state that only the goals of the design of core and plug-ins which should be simple but also its known limitations. I can spend time filling out more of questions (some of which we have discussed) below but it's meant to give you an idea of some things people might ask. However I doubt a lot of feedback will occur as the caster channel represents more users than developers in the classical sense.

How does a plug-in differ from a rule? Does caster-core work with all current engines? Caster-core handle dragonfly function context? Equivalent to companion rules exist? If plug-ins are not meant to be edited by the end-user how are they customized? Where are the plug-ins stored and how are they installed? Does CCR work as expected with extras, default rather than just repetition? What happens when CCR rules have identical specs? Are current rules backwards compatible and why not? Can we package multiple plug-ins in one repository that can be installed separately? Are plug-in dependencies isolated/separate from other plug-in dependencies? People are foremost going to be concerned about ease-of-use over design. They will care about design only if it impedes ease-of-use. In order for it to become a viable rewrite it has to replace existing functionality of the current project even if it doesn't share the same design. In other words isn't just an issue of packaging rules into plug-ins but plug-in ecosystem (Not grammars/rules) and caster core framework needs to be capable of emulating existing features. We want to transition the community. To push this too early without feature equivalents would cause a split in the community one that we could not afford. Managing the caster project has been tough over the last 5 years. I have had to care about the entire project not just the parts that interest me. That has been a real challenge and forced me to grow in very limited time available for me to contribute.

A quick thought on design I think caster core should handle to concepts plug-ins and extensions.

Plug-ins always contain voice grammars and non-shareable code Extensions are meant to be utilized by plug-ins but do not contain voice grammars. They would extend functionality beyond caster-core and to be listed as dependencies of plug-ins. Plug-ins only rely on extensions and not other plug-ins. Extensions should be caster core version agnostic. Extensions could be easily PIP installable. Plug-ins I'm not fully convinced on pip as a primary means of installation.

Above points should be considered.

Timoses commented 3 years ago

I don't think we are there yet to create a community release. There's still so much to design and work out.

I think the first step would be a 'prototype' release.

So these documentation changes are once again a little step towards a better access towards the prototype.