|
<![CDATA[
To: Frank Schuurmans <frank@bio.vu.nl>
Hi Frank,
>
>> Having thought about things for a while, and also referring to my
>> notes for the assembly language (hub) implementation, I now think
>> that each INPUT to a webneuron should have its own separate HTML
>> page with links to caller and target, and no code. Call this a WEBAXON.
>
>> One reason for webaxons is because an INPUT could be anything, graphics,
>> Email, string, numeric etc, and if there are lots of INPUTS then the poor
>> webneuron is going to get very large and confused. We may as well simplify
>
>Why not make a different webneuron for each kind of input? Actually We would
>need some OOP here:
>- one abstract webneuron for a specific task
>- different decendants from this webneuron for handling different kinds of input
I can't see how we could control this with the simple mappable network that we have.
Input links are hardwired from caller to target. If the data type changes for a particular
input, we still have to use the same link and therefore the same webaxon to store the
data. Thus data type must be able to change within a webaxon, contrary to your idea.
It is up to the interpreter to handle the data. You could presumably build the
descendant idea in at the interpreter level, but I think we have to stick to a very simple
framework at the webneuron level. You could however have a data type code in the
webaxon. this would be valuable information for the interpreter.
>> the programming task by making more links and pages, which is one of the
>> principles of webneurons anyway. So the webaxon is a data storage location
>> and a link page between the caller and target.
>> This fits in with the brain because it is the axon that holds the signal
>> data values transmitted between brain neurons.
>
>The axon is part of the neuron (the caller neuron)
Have I slipped up here? I wondered if I should have used "dendrite". I should have
checked. But webdendrite doesn't sound too good. I think we can still use "axon"
because it must have something to do with the output to target.
>> I hope all this is not too confusing,
>If afraid it is. I don't understand splitting things up.
Maybe I don't explain things too well.
>Re: webneurons (part 1)
>
>> I should also say that there is a whole lot of theory about hubs that
>> I have not yet mentioned for fear of confusing
>> everyone (including me). Before the webneuron idea I looked into
>> developing hubs at assembler level.
>
>I feel the idea is too vague at the moment. My thoughts on webneuron still
>are not 'cristallised'. It should be much clearer before it can be
>implemented.
Yes, we need to do quite a few more Emails before really starting.
>> Yes, a page must be able to have a memory. If page 2 fires page 3 first,
>> then page 3 must know that, when page 4 fires it next. We may need an
>> extension something like:-
>
>> <MEM NAME=status>fred<|MEM>
>>
>> This would be a readable/writeable storage location in the HTML page
>> (called status). The tag could go anywhere in the page. In the example
>> above status = "fred". But it could also be say:-
>
>We now have the multitasking problem and the problem of resetting the variable
>values when the weblet has finished computing.
Why do you want to reset them? In Excel for example variables are not reset after a
macro call, they are persistent. I have used Excel a lot and persistence seems to me an
advantage. Resetting doesn't give you much but it takes away a lot. New data just
overwrite the old in the variable.
>> We would need the ability to read and write to it while the page was
>> being interpreted.
>So the page would be kept in computer memory. (all pages of a weblet?)
Some pages may be on a different machine and also hard disc. I think the interpreter
has to cope with all these eventually. For the moment we maybe should just keep all
pages in RAM and on one machine, to keep things as simple as possible.
>> Status has to be saved with the HTML of the page, even if it goes to hard disc.
>> There is no other way I can think of. Thus we have to permanently alter the
>> HTML during the process of interpretation. If we don't allow this then we are
>> going nowhere. The brain obviously has this feature. Each neuron can keep a
>> memory of how much it has been fired recently and use that to adjust its
>> normal response to further firing.
>
>As I understand the firing of brainneurons:
>First the signal is not a binary signal:
>
> amplitude (voltage)
> ^
> | |\
> | \
> | \
>
> --> time
>
>Second A neuron fires if a certain input level is reached:
>
> ONE FIRING DOESN'T TRIGGER A NEW FIRING
Perhaps the new idea on webaxons can better model this. Here you can set outputs
without firing the target.
> amplitude (voltage)
> ^
> |
> --- voltage level nes. for firing
>
> |\
> | \
> | \
>
> --> time
>
>One firing is not enough (in this case) to make the second neuron fire
>but multiple firings by the same or other neurons makes
>that the level is reached:
>
> 3 FIRINGS: NOW THE NEURON FIRES
>
> amplitude (voltage)
> ^
> |
> |\ --- voltage level nes. for firing
> |\ | \
> |\| \| \
> | \ \
> | \
>
> --> time
>
We can roughly model this by the system of markers and webaxons with data. The
frequency of brain dendrite pulses can be modelled by an integer in the webaxon. Each
webaxon can have a marker (or flag) which indicates whether it has changed since the
last time the target webneuron was fired.
[SNIP - Closer to the brain]
>> What I think would happen is that we would develop a family of standard type
>> webneurons with code already embedded. We could then pick from this family the
>> type that suited each purpose. So we wouldn't have to keep writing the code again
>> and again. It would be more like building by plugging in components.
>
>like OOP (eg as in smalltalk, C++, Java etc)
Believe it or not, I have avoided all these, after deciding long ago that all script based
computer languages were a waste of my time. So I don't really know what Object
Oriented Programming is.
>> Maybe we can use the JAVA code for our own purposes inside the page then.
>
>When I talk about using Java it is in reference to writing an interpeter
>not about programming in webneurons.
Understood and agreed.
>> When I said "fast local weblets" I only meant that if the weblet was distributed
>> over several machines then processing could be very slow indeed, so local and
>> downloadable weblets could be important.
>
>I don't think downloading a bunch of HTML pages from several machines will be
fast
There is a big difference between a distributed weblet and a downloaded weblet. A
distributed weblet is a permanent mappable system of webneurons over several
machines.
A weblet is downloadable in a similar way that a JAVA applet is downloadable, and
would I think usually from one server machine only. Such a weblet would only be
mappable within itself and would have no connection to the main network until it had
been processed in the client machine. It would therefore be a websub or webfun.
After use it would only remain connected to the main network if it was a hardcopied
websub. If it was an attached webfun then it would only remain connected to its host
webneuron and not (strictly) the main network. I am assuming that the client machine
has permanent links to the main network (other machines).
>> >Secondly if webneurons only exist in the form of HTML-documents all
documents
>> >have to be accessed/read and a lot of unnessary (comments, HTML markup, etc)
>> >info is included in those files slowing the system even more.
>>
>> I see <PROG> sections going at the top of pages and being executed before any
other
>> HTML markup is encountered. In addition I see lots of very short pages so your
>
>But the whole file needs to be transfered from host to client
Yes this will slow things, especially if a large websub/webfun is transferred. As I said
before we could stick files together in a larger file to speed things up. Once in the
client the websub could run quickly. When the fast cable modems (300 times faster
than 28.8K modem) take over I don't think these download times will matter too much.
>> It is interesting to speculate whether HTML could go down to that low level. I
>> think it might. Microsoft are already (from April 96) building Java into Windows.
>> This is a big come-down for them. So the trend is to replace conventional
>> operating systems with Internet stuff. If HTML wins over Java then presumably
>
>I don't see how Java can win over HTML or vice versa
You know more than me about Java. Fil Mackay (see his Emaild http:...../606.htm)
suggested it could take over from HTML.
>> HTML can be taken down into Windows, MacOS, UNIX etc too. We could end
up with
>> an HTML OS. But only with weblets! Whatever the future holds I think it will
>> be based on hubs and brainlets, whether HTML or not.
>
>You have a strange view of OSs. Eventually OSs will be just device drivers.
OK, but can't the device drivers be written in assembly language weblets? It would be
good to include this low level area in our goal for a more usable simple programming
system. Why shouldn't the public have access to device driver level! It's their
computer, if they want to wreck it that's up to them - anyway they could take a backup
before fooling around. I don't believe in locking out any level.
>> >This might mean we have to leave the idea of processing the pages themselves
>> >but using them as a interface to the system and storing the table data in one
>> >file or a relational database (how is your SQL knowledge :) )
>>
>> I have programmed a relational database in dbase4, and converted my property
>> business using Excel (non-relational). I know little of SQL. HTML has tables,
>> couldn't we use that?
>
>Yes, but I would like to store the webneurons in a compact form as well as
>contructing a weblet file (as I view it: a collection of webneurons) fast.
>While using HTML as a programming and code browsing tool.
What about having all the webneurons on a machine, end to end in a single file, and
have a look up table at the top of the file for the interpreter to locate them. Because
each webneuron contains its input and output links then all map and weblet details are
also included in the file.
I want to do away with files altogether eventually.
Non-library webneurons on a machine should linked in a single mappable network. A
weblet is also any subset of the whole network, but no such weblet can be considered
"independent" or separable since it will always be mapped into the rest of the network.
Only library webneurons, webfuns and websubs are independent and separate.
>> I think with HTML it could still be fast enough for many purposes. The main
>> problem is that each page is a separate file. We may need to pack many small
>> pages into one file. This is how Netscape handles Email and Free Agent
>> stores news postings.
>
>It would make weblets rather static.
Except for webfuns/websubs weblets are intended to be very static. Brain neurons are
mostly static, you don't find groups of neurons moving from place to place (even if
you are on LSD).
One reason I am unsure about the validity of temp websubs is because they seem to
contradict the static nature of brain neurons.
>> I have no objection to trying to use Java for a weblet operating system
>> (if it can be done). I only object if Java is used instead of weblet applications.
>> I think you will find that once you have proved it with Java, then a lot of what
>> Java is itself could be replaced by weblets. We should only need a small non-
weblet
>> operating system kernel, for example a stacking system to handle the multi-
threading,
>> and a bit of unique code for interfacing to the hardware of each different computer,
>> to handle the screen/hard disc interface etc.
>
>So we are going to write an OS then.
PC's are the only valid target for this amount of work. I already started to try this some
years ago and got bogged down very quickly. You have a 16 bit BIOS problem right
from the start even though 486's are 32 bit. You can't use the BIOS directly AND have
32 bit capability. You have to use roundabout methods or rewrite the BIOS in 32 bit
code. I gave up but it's not impossible. Linux presumably did it.
I switched to an Atari Falcon (which I still have) and made much more progress. I
have some initial code for this. The basic idea is the same with software neurons,
axons, markers, stores and some simple "script" It could quite quickly be finished
with a team effort. But then is a system on a Falcon any good to anyone?
To get ridiculous, we really need to build a new multi-processor computer too,
designed specifically to process software neurons and possibly also to fit in with the
Internet. Each processor would have its own RAM and could communicate with the
others via PPP perhaps. Each device (monitor, modem etc) would also have a PPP
processor. PPP needs looking at. I know zero about it. Maybe it's wrong too.
If we extrapolate this argument we end up with a single nanocomputer in each
webneuron. Extrapolating even further by using biological nanocomputers we go full
circle, we have a real? brain, Well .... if only we knew how to connect up all those
webneurons.....
>Why not using an existing OS (like linux) and extending this.
I like what I read about linux. I think you said you wanted to develop the webneuron
idea using the same way linux is controlled. i.e. Open standard where source code
must always be provided and those rules cannot be changed. I know I have been
confused about business plans, but I would like to go ahead with this same Open
system for the webneurons if you agree.
Regarding using Linux itself, I think that is an good idea. For one we can get at the
source code. For two it's nothing to do with Mr Gates. For three it runs on PC's
(doesn't it?). Drawback - would people be prepared to install our Linux and lose
Windows 95? On the other hand - who cares about this drawback - I want a
webneuron system for
MY OWN use as soon as possible. What do you program Linux in?
This is where I restate (from the original posting) the term "Plexos" i.e. Plexus (nerve
bundle) Operating System. If we modify Linux I think Plexos would be a good name
for our product, and I am into names as you know.
>Or why not using the multi-threading and system interfacing of Java,
>so we can focus on the webneurons.
This sounds good and quick but I am ignorant of Java so I can't help on this decision.
You will have to decide. But I need to know soon because if I go to Java I need to
upgrade from Windows 95 - or can you run Java on Linux? If I get Linux will that
blow out my Windows 3.1? I do a lot of businees on the computer. Do I need a second
computer?
Have you dropped CGI?
>I see webneurons as a new level of programming:
>
>assembler -> structured programming (C, pascal etc) -> OOP (C++, Java etc) ->
webneurons
You can write webneurons from Assembler and replace all of the above. The rest of
that stuff is a turd pile. Webneurons etc, are fairly simple structures that can be
represented by a short linked list or a table, plus any stored data. We ought to scrap all
that excess baggage and start again. However, there is the time factor.
>> I need a decision here on which way to go. Do I get Linux and use Perl, or do we
go for Java?
>
>We need are decision on what webneurons will be before this decision.
Yes, ideas are still changing too much, but I am anxious to get something to
experiment with quickly. It is a circular argument. We need to build prototype weblets
to help in deciding about weblets. Trial and error.
>> proposing that downloadable weblets replace most instances of downloadable Java
applets
>> (unless speed is super critical).
>
>> I don't believe in files. The only building blocks we need are structures such as
webneurons,
>Let me guess.. you don't use a harddisk and flops... :)
A harddisc or floppy does not come from the factory with files on it. Files are an
entirely incorrect and artificial software creation. They are just part of the old heritage
of junk that todays software mess is built from. Has the brain got files? or is it just a
fairly homogeneous linked network of neurons - all you need is the neurons (or
webneurons) + a few other bits.
>> webaxons and webstores. Each weblet could contain a "contents" webneuron with a
list of every
>> other structure in the weblet. Each application could have contents webneuron with
a list of
>> each weblet contents page. Plus the operating system could have a list of each
application
>> contents page. To transfer webneurons/weblets/applications to other machines, the
only thing
>> you need is the contents webneurons, not a file manager. How the webneurons
should ideally be
>> stored on hard disc is an OS problem I have not thought about much yet.
>
>If you want to write an OS this is quite important.
In assembler initially, we can just dump RAM to hard disc, or floppy. Webneurons are
self organising since they contain mappable links to all their callers and targets - the
only problem is when you run out of RAM. To prove a demo we don't need to worry
about that yet. There is the problem of where you put the interpreter though?
Strictly speaking you don't need a hard disc. You can use battery backed RAM and
download/backup software from/to the Internet.
>> >I don't know of any perl browsers there is a perl http server, but basic (
>> >text only) handeling of webneurons would not be to difficult using a perl
>> >script and hacking the server.
>>
>> Surely we need to be able to do everything Netscape does + we need to handle
webneurons.
>
>The more reason to extend existing browser capabilities (using Java) instead of
>writing a new one
I'm happy to try this if you are.
>> We should be able to do both with webneurons. You realise that all of this is very
>> difficult to predict since I have never had a brainlet programming system to
experiment
>> on. It is all imagination.
>
>Maybe weblets should also be able to grow and replicate...
I wish you hadn't said that. Now it's going to take me 10 more pages to comment on
this interesting point. No, wait a minute... Please see the Jeff Browndyke thread
http://......574.htm
>> >how many webneurons would you expect we need to program a simple weblet.
>
>> A weblet could technically be any size, but I see them as similar to subroutines in
>> conventional languages e.g. small calculations, a bit of graphics/string handling,
>> etc. I suppose a typical weblet could have 10 webneurons or so. But then we will
stitch
>> weblets together to perform more complex applications. I don't quite know how all
that
>> will turn out because I have never had anything to experiment on.
>
>where are the objects/classes?
Why do you need any? Are there any in the brain?
I don't understand OOP.
>> If you look at how the Website is arranged you can see the way I think it will
work. You
>> keep track of them mainly by the structure/map of the links. It is remarkably easy
to
>> remember your way around providing each target also has a link back to the caller,
>
>What if your weblet gets rather large?
I have ideas for indexing and directories. For a crude example see the people page on
the website. You can still have homepages and local homepages. We will discover
how to solve a lot of these problems later (I hope). It may be unproductive to try and
imagine the whole future system in advance. We will probably get it wrong any way.
>> which is true on our Website but not on the WWW. This is a big problem with the
WWW -
>> very few explicit links back to callers - only links to targets, so you can't draw a
>> complete map starting from any page - The WWW is not like the brain at all
>> (but it could be). Starting from any neuron in the brain you could trace out a
>> complete map of it!
>
>I don't agree. Neurons don't know of each other the only make forward links like the
Web
Imagine you are microscopic and standing on a brain neuron. You can then walk back
to all the calling neurons by following back the dendrite/axon pathways. Similarly, you
can find the targets. The brain is certainly mappable (but might take a while). Just
because the pulses from the caller only travel forwards to the target doesn't mean the
physical structure is not mappable. Physical structure is important as well as the firing.
********** I hope you can now accept this point because it is fundamental.
********************
The Web is not mappable because I don't know who may have put a link in to my
homepage. If Web pages go "live", as webneurons, then it may have to be illegal to
make such firings without approval because they could cause havoc. You might be
running a weblet and suddenly some idiot would fire one of its webneurons at the
wrong time. Yes, we have a security problem here. The solution may be to have ALL
webneurons in a continual state of firing, as mentioned elsewhere, but then you have to
check the inputs haven't been tampered with. Alternatively to insist that all firers URL's
are checked with the list in the target webneuron, of physical links to callers.
On the current WWW is it possible for a client to deceive the server about the client's
identity. If say client A pretended to be client B, would client B then be surprised to
suddenly see on his monitor, the page client A had requested (on his behalf)?
Each webneuron should contain a list of callers. If a webneuron can check a caller's
identity against this list and a caller cannot lie about it's identity, then we may have a
built in security feature, like a username at least, if not a password.
>> There is no problem in giving names to each page/webneuron (see page names on
the Website).
>> These do not have to be unique. Each page has a filename/URL to locate it. There
are a virtually
>
>How can you have two files with the same name? (I consider dirs as a parts of the
filename)
The page name I am referring to above is the HTML page title, not the filename. I just
use unique numbers for filenames because I don't use files for remembering names.
]]>
|
John's Emails
