[Ktechlab-devel] net-centric ktechlab

[Zoltan Padrah]

 Hi,

I see a lot of potential in the simulation of small networked devices,
like wireless sensor nodes or internet-of-things type of devices. Such
devices are built around microcontrollers like PIC, AVR or ARM-based
stuff. It's just a matter of hooking up the electronic simulator to
the given architecture's simulator, and then we could have really
useful design tool ;)

Regards,

 Zoltan


2012/5/9 Alan Grimes <agrimes at speakeasy.net>:
> ktechlab was a brilliant, innovative and generally awesome piece of
> software for the first decade of the 21st century. Now we're in the
> second decade of the century and it's time to raise the bar to the next
> level.
>
> Everyone is ga-ga about web-based applications these days. They are
> taking perfectly good applications, downgrading their user interface by
> five or more years so that they can run in a constraining, slow, and
> crappy web-browser.
>
> They're missing the point.
>
> There is no point in running crap in a web browser just because it's the
> trendy thing to do.
>
> The point is the *NETWORK*, not the web. Modern software must be network
> centric.
>
> There are several major advantages to network centered software.
>
> -> Collaboration.
> -> ubiquitous access.
> -> real-time sharing of component libraries and platform development.
>
> Basically, these are must-have features for contemporary software.
>
> So what I propose is a client-server architecture with a peer-peer
> infrastructure. So if you want to keep some stuff private, you'll need
> to run your own server, otherwise it would be optional. (kinda like how
> free-civ works.)
>
> The front end will be some kind of game engine. Crystalspace is the
> common open source engine, I'm not sure it will support the dynamic
> content generation we need. The other interesting engine is OpenCobalt
> which is written in Smalltalk. Last I checked it was still definitely
> alpha-ware but has shown dramatic progress from earlier versions.
>
> The back end will consist of a parts database and a world-map which will
> constantly evolve as people add parts. The server will store the circuit
> and the state of the inputs. The client code will run the simulator, but
> only on the circuits near the user. (they would otherwise be running
> much too fast for any kind of server-side simulation).
>
> I want the client to be 3D, so the schematics can be drawn in 3D. This
> is important because nanotechnology will eventually be catching on.
>
> One very practical application would be managing power connections for
> IC components and logic gates. Right now we aren't simulating the power
> needs of logic gates. These are frequently omitted from schematics for
> clarity. For example, a network drawn in the XY plane could have it's
> power layout mapped in the X-Z plane...
>
> 3D design is also very important for MOS gate design as well as new
> layered ICs and PCBs. -- Gerber file exporting will be critical for
> making Ktechlab a viable design tool.
>
> Also, it will provide a crossover environment for mechanical
> simulations/robotics. (there was some stub code for this in the old tree..)
>
> Now the issue of an "on-line" simulator raises the problems of service
> reliability and updating. A peer-peer server infrastructure should
> alleviate the cost to the project maintainers for network operation. The
> bigger issue is managing software updates to the network. Therefore
> there needs to be client-server protocol versioning so that clients can
> negotiate with the server. Also, there needs to be a method for
> extending the server without taking the whole network down. There are a
> number of general approaches for distributing updates. Basically, the
> server must be profoundly modular so if someone makes a true
> oscilloscope object (as opposed to the chart recorder ktechlab 0.3 had),
> that innovation can be integrated and distributed to clients in near
> real-time without introducing security problems (!!). So there might
> have to be some kind of security check on the server so that, for
> example, any code that imports/links against system libraries is
> rejected as "prohibited: security hole".
>
> The idea is to create a platform for open hacking that can evolve
> collaboratively at a near break-neck speed. If what I propose here is
> even half-way successful, it could be totally slashdotted, (survive only
> because of the peer-peer server architecture).
>
> There also needs to be some kind of way to manage user identity, so that
> access to hub servers can be limited and metered, while users with
> private servers can place locks on their own private inventions while
> displaying their other stuff in public in such a way that visitors can
> copy it but not edit the original.
>
> --
> E T F
> N H E
> D E D
>
> Powers are not rights.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel