For websockets, section 5.2 of the standard is all join needs.
Join bots do not talk doesn't talk http. Maybe one of the attached grammars does, but join bots themselves frame data directly and skip the http handshake and likely will skip the keep alive protocol and use connection recovery instead.
What do I get? A message system without the asynchronous call backs of the MQ protocols like ActiveMQ and RabbitMQ. Join bots do not need message queuing, they are naturally queued in the join stack already. My bot are traversing directed graphs without loops with a join protocol that prevents collisions between bots.
So, I am back to simplicity, a botnet for the join machine retains absurd simplicity, no way I am down loading megabytes of MQ bloat to execute the simple framing protocol. The join bots are the only network talking LazyJ, as of yet. When other applications adopt it then I can worry the standards issue.
In my network, browsers sit at the edge of the net, bots traverse the net and the local join machine emits html for the user browser. There really is no need for HTML servers, just join servers and all the data inside the join net is mainly streams of printable text. You cannot build semantic network inside any tagging protocol like XML, bot don't need that and the join system will have to toss the tags as soon as it sees it, replacing the tags with a tag link stack used by Ext to traverse the directed graph. The XML or HTML tags, removed and never replaced. Instead an html version of data is created on the spot by the local join machine as the user requires.
I am pretty smart about this. I have used as much of the standards as I can, and skipped tech that needs new standard. I dump the standards like html and xml right away as the bots don't use those protocols in botnet. With JSON, all I have done really is dump their useless quotation marks and I get a slightly enhanced Comma Separated File format. There is a lot of reversion to pre-web formats because bots do not use browsers, join bots do not understand bitmaps.
But in an enterprise, the ability of this botnet to read and summarize hundreds of web sites for each of the employees is a great productivity tool. Each employee tracks all the web talks concerning their tech and market. And that is just a specialized application for join, multiply that gain by five to cover all the new productivity.
How do bots activate communications?
A grammar networking grammar gets a fetch or append or step or skip. It sets the current instance to pause and does the framing protocol with the destination node on the semantic network. The join itself has no concept of remote or local, or communications at all. It just traverses the next node as required by the match function.. And match includes the LazyJ select and/or replace syntax, yet undefined. Everything is falling into place for one reason, the stability of traversing directed graphs, they are Turing complete.
2500 lines of code for join and the typical grammar attachments. One per each linux system and the resulting botnet can read the entire web. Really, look at the notes on join grammar, skip the code, follow the development logic and it is plain, the entire botnet community needs this capability, and we get the shell tech, works with standard linux cmd sequence grammar thus enabling all the linux utilities to participate. All of it under the CutnPaste software license, "if you can cut it, you can paste it". The code of conduct is simple, join bots for everyone.
How about a standard object network access protocol for linux?
MS has one why not linux? Because linux already has one, the linux command and argument format works just fine for basic object and method access, and most linux utilities can adapt to the model by reserving certain argument flags as an agreed object standard, simple. Most linux utilities can easily classify their flag set according to a method and inheritance model. The add a wrapper to use that system over the existing argument parser they all have. Thus, in the join system join can easily provide access to an object symbol table for subsystems, all the linux utilities adapted.
There is nothing wrong with linux command sequences for basic object communications. Skip join, just look at shell as a system for compile into object access into a standard command sequences. Just informally declare a flag type called -method and -object. The object shell in each linux utility just cnverts these back into thee existing sequence of argument format peculiar to the utility. We become backward compatible everywhere with the new shell, but offer object interfaces as powerful as MS PowerShell. Encapsulate and reuse linux utilities everywhere.
Consider gcc as an example. Add the object wrapper and gcc command, at the script level, looks like:
gcc.compile.shared
The method "shared" gtells gcc you want a standard shared library ready for standard linux use.
The linux pros get into the gcc object wrapper and convert 'shared' into the series of flag sets normally required, backward compatible. This can actually be done with simple table look up inside gcc and it makes life simple for all. This is right in line with using environment macro expansion, nothing new except a prior agreement on argument flags to identify object format usage.
In fact the shell can do the conversion with symbol table expansion, as long as someone wants to set up the table, then any of the linux utilities become object accessible. How much work? There are about 20 important linux utilities, about a week's worth of work. Linux has a powerful competitor to MS .NET, a few folks getting it is all we need.
So with a thousand lines of shell we get complete object access to linux. The key is a syntax interpreter that knows inux command sequence for an executable format. The scripting syntax containing all we need to set up conversion to object access, no undelying change tolinus or utilities. You deploy is with:
gcc shell.c
No header files needed, includes are all in the script declarations, the common interface protocol is standard c arg list delivering standard linux command sequence. Suddenly, we have enough to compete with anything MS does with .NET, as far as enterprise management. Linux bloat become manageable, the complexity of linux argument flags gets reduced to the essentials need on an ad hoc basis. And depending upon the application, the method identifiers need not be standard, and can be decomposed into a series of linux commands, compound linux commands attached to one mehod.
Ned to add dot sequence format to the current shell syntax making the script not quite c compatible but more like Golang.
No comments:
Post a Comment