|
<![CDATA[
Hi John,
I'm glad you agree to put the business plans on hold for now. I think the
plans are too vague at the moment. Depending on a running system we can still
decide to start a new business. I have spend quite some time thinking about
webneurons. My interest in webneurons is a result from my interest in biology
(my study) and my interest in computing/the Net (my business). Unlike you I
haven't thought a lot about webneurons before but on a more biological way of
using/programming computers (from my conviction that biological systems are
superior: they have been tested for millions of years).
The image you sent showed something new to me: Page 3 which has to be fired
by two other pages. This implies this pages has some memory if it has been
fired, by which webneuron, and by which process (multi-tasking!).
My first understanding of webneurons was that the are quite ignorant of each-
other...
Your email d.d. June 6:
> About the question of speed:-
>
> I can see a big demand for fast local weblets all on the one machine,
> and especially a client machine. Weblets would replace JAVA and "applets".
I don't think webneurons will ever be able to beat Java on raw processing
speed: Interpreted code is always slower compaired to native code. Since Java
is interpreted code very close to native code it is 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. 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 think we want to be able to "run" local weblets.
The question of speed and the ability to run weblets locally may well mean
we've got to use Java.
> Consequently I think the ability to interpret weblets must be built in to
> the client browser, and also into the server. If we ignore the browser
> aspect then Java will continue, when it should be replaced by webneuron
> programming.
I'm not sure I understand your problem with Java. I think that there are some
clever things about it although it is now mainly used to turn webpages into
pinball machines. At the moment I'm learning Java which isn't difficult since
I already know C++.
> On the server side, if say we wanted to rewrite Lycos or create our own
> Internet search engine in weblet form, then we would want it as fast as
> possible and probably running on one machine. Could PERL do it?
I think Perl is the way to go in developing a webneuron server-side-only
system.
> The conclusion I seem to be coming to is that we have to write a combined
> interpreter/browser that will operate at both client and server levels,
> and be capable of running weblets as well as presenting standard HTML to
> the client screen. A new Netscape!!
Since HTML is still rapidly changing it might be a good idea to let
Netscape and Microsoft fight out their battle of the browsers while
developing and optimizing the system. If the system is really good it
would not be difficult to write a browser using webneurons.
> If we want weblets say to control say animated graphical outputs to the
> client's VDU screen then for speed reasons it would be important to download
> the weblets to the client, where they would be interpreted by our interpreter
As I understand a weblet is a collection of HTML pages, It wouldn't suprise me
if running the program remotely (from the clients view) and sending some
control and image data to the browser is faster compaired to downloading a
bunch of HTML pages (see my earlier comments on speed, in this case spreading
a program on several files reduces the speed even more since the network is
used). But only a working system can tell us the fastest solution.
> on the client machine and graphics presented directly. It would be far
> too slow if the weblet was server based since you would have to keep
> going backwards and forwards to the server everytime you wanted to move
> a client graphical object.
> However, just to prove the principle you may be quite correct to suggest
> PERL. Can we install PERL on client machines and use a PERL script
> for browsing? Are there any PERL browsers available now?
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.
> >It is not clear to me how you see the processing
> >capabilities of one page.
> Very simple use of IF ELSE, and + - > etc operators, and data storage
> within (or on the end of) the HTML. This is preliminary and based on
> the address book example I worked through. Everything is early days
> at the moment.
Maybe we should clear up some of the neuron confusion in my head :) I know
of the following neurons:
A) The biological ones
B) The simulated ones from AI.
C) Webneurons
If a C has operators inside of them I suspect you want to model A. The
problem with neurons (A and B) is that you don't program them but try teach
them something. If this is your idea of webneurons I don't understand the
use of operators in webneurons and drawing maps of them. (how many
webneurons would you expect we need to program a simple weblet, do they
need names (or numbers), how would you keep track of them all?)
> >- Data (types) -> in HTML
>
>Yes. Data input via the FIRE command will sometimes need to be stored
> (embedded) in the HTML or on the end for later use. Sometimes it
> will be operated on immediately via IF ELSE. All this is very
>preliminary. At the moment I see data mainly as strings but
>integers, real numbers, even jpg's, audio etc could be useful -
>who knows till we have a system we can experiment on.
By data I meant variables (urls to other neurons, parameters etc..)
I don't see how the webneurons could work without the possibility to use
numbers (this is not a problem in perl because in perl a string number 'is'
also a int or float).
> 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.
> >- Operators -> in HTML
>
> You mean + - > etc?
yep
> They must go in the page. I can't see anywhere
> else for them. But hopefully as few as possible. I prefer the concept
> of lots of small pages with extremely simple coding. I believe that is
> how the brain does it. Don't hold me on this one.
What I know of type A neurons is that they are so complex we don't
understand them yet.
> >- Subroutines, functions etc -> in links
> This is very tricky.
>
> There is no equivalent of the subroutine in the brain, unless you consider
> action within the neuron as such.
yes, could you explain the difference between a webneuron a weblet, websub
and webfun to me?
> A network of brain neurons is hardwired.
and later in the message you write:
> The process of learning may involve neuron creation/deletion, especially in
> the foetus I am told. I think automatic page/link creation/deletion is a
> definite bonus. Besides, why restrict ourselves.
This seems somewhat paradoxal to me, could you explain your ideas on a network
being hardwired and automatic link/page creation and deletion?
> However, there are at least two ways a weblet subroutine/function
> (websub/webfun) could possibly be useful.
> WAY 1 - If you really needed to do some function within the webneuron.
> you could fire a weblet to do it and it could return result(s)
> WITHIN the webneuron page. Call this type of weblet a webfun:-
> <RESULT Street, Town><FIRE href="webfun URL" PARAMS=Address, Mr
Smith><|RESULT>
> (I think "PARAMS" is better than "INPUTS")
using my cgi-idea:
neuron 1 (query.html) would contain:
<TR>
<TD>! address<|TD>
<TD>Mr Smith<|TD>
<TD><A HREF="/cgi-bin/fire/address.html">address<|A>|TD>|TR>
and neuron2 (address.html):
<TR>
<TD>== Mr Smith|TD>
<TD>Street, Town|TD>
<TD><A HREF="/cgi-bin/fire/query.html">query|A>|TD>|TR>
> WAY 2 -
> Say you have a standard weblet that is used time and time again in many
> circumstances. Call this a websub. It may return something to the caller
> by firing param(s) back to it or it may return nothing. But it is not
> internal like the the webfun.
I don't understand the 'internalness' of a webfun do you mean a SSI-like
thing.
> There are at least two options for handling websubs:-
> OPTION A
> Copy the websub from say a central pool of such standard websubs, and
> "slot it in".
> Unfortunately, this means all the websub pages would be duplicated as
> many times as it was copied, and any editing of the copied websub must
> usually be applied to all the copies. This makes maintenance difficult,
> and wastes disk space. Multiple copies would occur even if the websub
> is fired from different pages on the SAME machine. I realise you may
> have trouble grasping some of this. I have been thinking about it for
> about 10 years.
I don't understand how you can't do without making file instances of the
HTML neurons, how could you handel multi user requests, how can page 3 (in
your gif diagram) remember it has already been or not yet been called, surely
not by storing this kind of information in the code of the neuron itself.
> OPTION B
> There would be only one master copy of the websub, and all pages wanting
> to use it would fire it in the normal way. The websub should also have a
> complete list of every firing page. This is good for tracing and indexing
> things. You may not agree on this. It could be a very big list for popular
> websubs.
You're right I don't agree, it makes the system to complex and closed: imagine
this practiced for the web. Further more the number of files increases by a
factor 2, slowing the system...
> There is a problem here, because if the websub is fired again from elsewhere
> while still processing a previous firing, then what do you do?
I don't see the problem
> 1) You can make the other firer(s) wait till the first is finished. But what
> if there were hundreds of waiting firers from all over the world?
> 2) You could create temporary copies of the master, and use those to serve
> any
> queues. Thus you would have a websub server! But what if the websub fired
> websub? Possibly a bit messy?
no a webneuron server, nothing messy about this it is what http servers
do al the time
> OPTION B 2) seems like the way to go, but quite involved. For the moment we
> could use OPTION A or none at all - don't allow websubs - just hardwire
> everything. At least we could get started easier.
> >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.
> 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?
(I've no problem with the name)
> >> 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: the don't exist on disk
unless a user saves them. Off couse weblets should be able to output (HTML or
whatever).
> >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 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?
> We have to try a lot of real
> examples to see how it would work in practice. Certainly it is a strange
> and unusual way to program, but that may be a good thing, since the software
> industry is in a mess and needs something radical.
> >it is not possible to let the webbrowser fire all the neurons
> I presume you are talking about a neuron that itself fires many neurons. The
> situation is complex.
no, I was thinking about a clientside solution: a browser downloads
all source code, then it gets complex indeed.
> 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?
> 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?
> >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.
> 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)
> 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?
> But how difficult is it to write a complete client browser in PERL.
what do you want the browser to do?
> I have heard you can't use PERL with Windows 3.1?
checkout: ftp://sunsite.auc.dk/pub/languages/perl/CPAN/ports for
your favorite perl5 port :)
> What is "real code reuse"? I am certain that "superprograms" are possible
> with weblets.
You don't have to copy weblets to your local machine to use them in your
weblets.
> 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.
A lot of questions this time, well Java wasn't developed over night either :).
I hope this doesn't temper your enthusiasm. Maybe we should define our goals
more clearly. I'll give it a first try:
Main Goal:
To develop a usable, better way of 'programming' computers.
Requirements:
Speed
Secure
Platform independent
Distributed system
(Runnable on the clientside and serverside (or a combination).
Using the Internet/W3)
Simplicity
(the system it self/using it/design etc...)
You probabily won't like my conclusion : it can't be done using HTML and
cgi 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).
Regards,
Frank
____________________________________________________________
Drs. F.P. Schuurmans CYBER PUBLISHERS
frank@bio.vu.nl Amsterdam, The Netherlands
]]>
|
Frank's Emails
Re: webneurons (part 1)