-
Notifications
You must be signed in to change notification settings - Fork 23
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
Split up cogserver into three parts. #6
Comments
Added comment about how to preserve history when moving files into another repo: opencog/opencog#3391 (comment) |
See also opencog/opencog#3391 |
I've moved the code around, to make this split easier.
The module system should probably be split out into it's own thing ... |
Closed
The code reorg is done. Further work in this direction seems impractical, not really required. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The cogserver is mashup of three unrelated concepts; it would probably work better if it was detangled into those components more cleanly. It is:
PythonModule
)These three are currently in somewhat questionable state of repair, and it might even be very wise to re-imagine the architecture/design from the ground-up.
The multi-tasking ("Agents") framework is lame, and is little more than a REPL loop. The dream of the multi-tasking framework was to somehow manage tasks and set priorities for them (allocating CPU resources), but forcing all agents to be cooperative multi-taskers causes well-known issues (MS Windows3.1 and Apple OS9 from late 1980's illustrated the possibilities and the limitations very clearly.)
The command-shell is kind of goofy, like somebody's school project. It expects new commands to be implemented as dynamically loaded shared libraries, with a very strict API about what is and is not allowed, which makes it very hard to create high-quality modules. Giving the command shell a minimalist design would simplify it, make it work better/less awkwardly.
The network server is the most debugged and mostly quite stable. I would have recommended discarding it, replacing it with some other open-source project, except I once searched the internet for a drop-in replacement, and (surprisingly) found none. Maybe the world needs a generic shell-server!? Biggest problem with the network server is it provides zero authentication, zero security. (it's not obvious how to rip it out and replace it by ssh, for example)
I can kind-of see why all three components are interesting, but given the limitations, they need to be reimagined from the ground-up.
The text was updated successfully, but these errors were encountered: