|
<![CDATA[
Hi John,
Your mail on webaxons and webstores:
> 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
> 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)
> I hope all this is not too confusing,
If afraid it is. I don't understand splitting things up.
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.
> Do you earn a living from the Internet? I thought this was very difficult.
> How do you earn money if you don't mind me asking?
Making HTML and CGI scripts. For example see http://www.srtca.shell.nl/
> 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.
> 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?)
> 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
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
Because of the shape of the firing in time the neuron has a 'memory'
My guess is that firing frequencies are very important in the functioning of
the brain.
This could be modelled into webneurons by storing the times at which
a webneuron has been fired. At least this data doesn't need resetting like
storing which neuron called.
> 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)
> 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.
> 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
> >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
> 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
> 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.
> >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.
> 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.
> 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. Why not using an existing OS (like linux) and
extending this. Or why not using the multi-threading and system interfacing of Java,
so we can focus on the webneurons.
I see webneurons as a new level of programming:
assembler -> structured programming (C, pascal etc) -> OOP (C++, Java etc) ->
webneurons
> >I think Perl is the way to go in developing a webneuron server-side-only
> >system.
>
> Can we also do this with Java?
It can be done using any language
> 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.
> But the executable HTML pages can be very small. In this case I am pretty sure that
for most
> screen applications, operating in real time using a modem line would be impractical.
I am
Not if the interpeter is smart enough.
> 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... :)
> 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.
> >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
> 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...
> >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?
> 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?
> 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
> 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)
> endless address space of unique filenames/URL's. This is one reason I like using
web pages -
> no 16/32 bit address space limits. We don't have to change anything when computers
go to 64 .
> >> It may be advantageous to have an EVAL type statement that would allow
> >> us to create a line of HTML using strings and embed it into or on the
> >> end of the page.
> >
> >I hope you don't mean a function you can pass system calls to (like the perl
> >eval function). Then we've got a potential security hole the size of
> >the Titanic.
>
> Could you tell me more about this please. What causes the security problem?
You give people the possibility to eval their input (for example mailing
passwd file).
Groetjes,
Frank
____________________________________________________________
Drs. F.P. Schuurmans CYBER PUBLISHERS
frank@bio.vu.nl Amsterdam, The Netherlands
]]>
|
Frank's Emails
webaxons and webstores