Open bugs181 opened 5 years ago
I like this. I have a few ideas in this domain. This is why I might be useful in looking for holes.
In your examples on your README.md, I can see simple linear paths. Once you start mapping parallel paths using conventions it becomes less accessible to the programmer. One would need to spend time as a dedicated software scientist to conceive all the possible ways that Frame could fail.
Only then would we know if it's weak/strong.
On the surface, it looks like it's conducive to message piping. But I suspect message piping will have much more complexity in reality.
Finally, the inclusion of any base framework, whether novel or mature, will be something that new contributors will need to understand.
I recommend that if Frame is used, don't make it foundational. There are multiple programming patterns that can be used to keep code modular, reliable, and secure. I suggest this could be considered one of many.
Very much appreciate the constructive criticism (concern?), however Frame is not "just" message piping. It's also a fully async module loading system and flow control library. It makes no assumptions about the types of "modules" that can be used. As one of my "erks" of being a lead software engineer for over 15 years, I can let you rest easy knowing that it is both forwards and backwards compatible.
@bugs181 nice.
You're at the top of the game, and there are few challengers up there. It's best that you get "tested" early and often. Only you, with the full understanding of what you built, can know whether I have raised any valid points.
Repost from the Gun repo: Issue 717
As some of you may know, I've been working on a project called Frame. This library/framework is vendor, host, library, and programming style agnostic. In simple terms it's primary purpose is to be a declarative flow style programming suite.
The library side of the core is about 90% finished with just one known issue that stands in the way of the current implementation proposal for blueprint syntax. Once I've completed that step and implemented several modular components (called Blueprints), I intend to make an Open Source IDE with drag and drop capabilities that allows users to wire up any library/framework/blueprint without writing a single line of code.
My new proposal as discussed with a few other developers, is to use Frame as the primary method of creating the core functionality of JoyDB. Joy core would be composed of several blueprints utilizing the flow aspects of Frame, which would include a Singleton and several other modular parts like Schema, ACLs, and Adapters.
Going forward, I'm asking Gun developers to thoroughly consider this offer and if you support this idea, leave a comment, question, like/love on this issue.