|
<![CDATA[
To: Frank Schuurmans <frank@bio.vu.nl>
and finally, ....
>> >Maybe a webneuron could be called a 'web unit of processing'
(WebUp or
>> >wup).
>
>> Do you think a webneuron can do more than a real brain neuron then? I
am
>
>Not more than a type A neuron, but certainly more than type B else
programming
>would become impossible.
Interesting. Then you agree that weblets are more powerful than neural-
networks.
If so then we are sitting on a bomb.
>> interested in this. I have contact with someone who knows about real
brain
>> neurons and we can ask him any questions we like.
>> Shall we stick with webneuron for the moment. But do you like
"weblet"?
>
>what is the equivelant of a weblet in the real brain?
Weblet is just a name for a collection of linked webneurons where firing is
involved among them to perform a task. I think a similar collection of brain
neurons (type A) would be called a plexus.
>> >> Links to be made/broken
>> >> Pages to be created/deleted
>> >
>> >Should the weblet be allowed to do those things or only the
programmer?
>>
>> Automatic page creation is common in search engines, and a weblet
based
>> search engine would definitely be on my list.
>I'm sorry I misunderstood you. I view pages as a more or less static
HTML file
>while the output of search engines are dynamic pages: they don't exist on
disk
>unless a user saves them. Of couse weblets should be able to output
(HTML or
>whatever).
The above was just an example, I think we should be able to create
permanent pages under program control too. For example when adding a
record to a weblet database, many pages may need creating and many
cross-links.
>> >What about returning some output to the caller
>
>> Output can be returned to the caller by firing params back to it, and so
is
>> covered by " Triggering of other pages" above. The caller's URL can
be held
>> by a "result" webneuron which can then fire params back to it (please
see
>> the .gif I sent).
>
>What if the caller happpens to be a human (a browser)?
This is a very interesting question.
Let me first say that I now think all browsers should also be 24 hour
servers. I would say this is the future. It was dead easy to set up a server
on my home machine and the software was free. The only problem is the
phone call cost. In the future, when telecom companies realise phone calls
should become PPP based URL requests, and they should use the Internet
phone, then everyone can be connected to the Internet 24 hours without
using an ISP, and likewise, every computer should then become a server.
If the browser couldn't interpret the FIRE command then it couldn't have
fired (called) anything in the first place. So I assume it was capable of
firing. However, there is also a possibility here that some completely
unconnected webneuron could fire something to the browser just by
knowing its IP address.
A browser can have a large list of pages in its cache memory. Output
could be fired to any one of these, even the one currently on display,
assuming the browser was also capable of receiving a fire command, and
directing the fire URL to the correct HTML file.
The fire command from the result webneuron would presumably be
something like:-
<FIRE href="194.34.122.4/file.htm"> where the number is the IP address
This also assumes that the "result" webneuron knows the correct file to
send to, on the browser computer. A lot depends how the browser is
rewritten.
Going one step further, and assuming operating systems and applications
are written in weblets (or brainlets) then output could be fired back to any
part of the computer, since the whole computer would be weblets! The
filename could be replaced by a webneuron index, and this could have
pointers to the webneuron locations in RAM and on hard disk, via an
indexed look up table.
>> >this is in my view the trickiest part of the webneurons since several
>> >webneurons could return output to one call and the system doesn't
consist of
>> >one to one links
>>
>> Yes, but in this case the caller could have some code that told it to wait
>> until all the outputs had been returned.
>How would it know?
By the <ALL> extension mentioned previously.
>> For example, say neuron A fires neurons B, C, & D, neuron B fires B1,
B2, C
>> fires C1, C2, and D fires D1, D2. We have a problem with all these
firings!
>> How can the webbrowser remember to do everything and in what order
should it
>> do them if it could remember.
>If we've got four neurons say A B C & D
> A fires B
> C fires D
>makes it any difference if A fires first or C fires first?
None at all because there is no link between (A,B) and (C,D). Which of A
and C fire first will be determined further "upriver".
>> There is no problem if B, C and D are on different machines because
the
>> webbrowser can just fire them off to the various machines and forget
about
>> them.
>> However, if B, C, D are on the same machine, that machine has to
handle them
>> all itself. This is a problem of multi-tasking.
>Why is multi-tasking a problem?
Well, we have to use a stack. This is more of a problem than if we didn't.
>> >so neurons should send the IP-number of the original caller to each
neuron
>> >they fire or the first neuron should return the output. (I think only the
>> >last solution is realistic: a user should call an 'output neuron')
>>
>> I presume you mean URL when you say IP-number. IP number is the
number of the
>> computer.
>
>Correct, I mean IP-number or URL depending on the nature of the caller.
Sorry.
>> I don't know why you say only the first neuron should return the
output? This
>> is not the way the brain works.
>
>I agree we have to design specialized neurons (like the brain has)
>
>> It would be extremely restrictive and would
>> mean that loops could not be done using the links, so we would have to
keep
>> all the old bad habits (WHILE statements etc).
>
>why could loops not be done using links if the input (first neuron) is
>also the output neuron (last neuron)
Sorry, I misunderstood you. I thought you meant that the first neuron was
the only neuron, rather than linked to other neurons which eventually
linked back to it.
I think your point that the first neuron should also return the output may
have a bearing on webfuns/websubs. In which case this might be a
desirable sub-type we could use for certain standards. I'm not clear on this.
>> I believe we should have the
>> freedom to draw webneuron maps in any fashion we choose as in the
example
>> weblet gif.
>>
>> If you look at the address book example you will see that the caller
URL does
>> not have to be passed from webneuron to webneuron. The last
webneuron in the
>> line is hardwired to fire the original caller.
>
>So only one caller can receive the output?
You can program it any way you like. It was only a very crude example,
not intended to be a full solution. The output could be hardwired to many
other webneurons. The particular one chosen to be decided by logic in the
code. We really have to do some real webneuron programming to
understand the practice of it.
>> But how difficult is it to write a complete client browser in PERL.
>what do you want the browser to do?
Basic display of HTML pages, link between them, gifs, tables etc AND
handle firing. Also fonts, bold, big, etc - everything on the website.
>> Again, I think we have got to allow weblets to be downloaded to
clients and
>> interpreted on the client machine as well. But maybe not immediately.
>Again it's better not to: programmers should be responsible for code the
write
>not users.
But your main goal is to develop a usable, better way of programming. I
take this to mean the common man (user) might be able to program now,
especially if it was taught from school - just the one method, not BASIC,
C, JAVA, PASCAL - all that lot is too confusing for kids, we just need
one method throughout.
>Main Goal:
To develop a usable, better way of 'programming' computers.
Totally agree. I've put it in the Introduction.
>Requirements:
> Speed
Not too bothered on this, just something that proves the principles.
> Secure
Again, not too bothered, we can always encrypt later.
> Platform independent
Yes, but if we go to OS level we will have to tackle each machine
eventually.
> Distributed system
Yes
> (Runnable on the clientside and serverside (or a combination).
At present we need to handle both. In the future, I believe only the
serverside.
> Using the Internet/W3)
Yes.
> Simplicity
It will be simple to program but do you still think it is simple to create,
after my latest posts?
>You probabily won't like my conclusion : it can't be done using HTML
and
>cgi only,
What about if we stay serverside only?
>everything points to Java. In my view this doesn't mean the final
>system looks like Java, it is build 'on top' of java exploiting it's features
>and reducing the amount work. We should not try to beat Java but focus
on
>something new.
>I'm afraid the messages gets a bit long and mixed up: I didn't write it in
>one go, and I've (too) many ideas.
>Maybe we should use the web for brainstorming
A good idea. What are your further thoughts on this?
I have now gone over most of the main points about webneurons that I
know, and discovered a few new ones. There is not much more to say
about theory for the moment, which I expect you are relieved to hear.
>If you have the gif and urls I am willing to make the imagemap
If we could automatically generate the gifs from the website structure that
would be brilliant. Do you know how to do this? One gif of the whole site
could get too large. I will do one gif for every 2 or 3 link levels, starting
from the home page.
I need your feedback on the following:-
1) Are we going to try Java. If so I need to upgrade my computer (no
problem)
2) Should I get Linux or stick with Windows
3) Have we dropped CGI. If so why?
4) Should we just attempt the server side first
I also think we should start breaking up the Email, perhaps under different
subject headings.
Thanks for your reply,
]]>
|
John's Emails
