Re: [Grapevine-devel] Animal example now works

[Anthony J. <aj...@cl...>]

Steve,

Event based has the advantage of having explicit state - it's easy to 
see what the state is.  An event model also uses less memory.

A thread based model uses more memory (I don't know how much memory a 
thread uses).  I think that a thread based approach would work well 
enough.  There are problems with deadlocks, etc.

The main reasons I think we should use threads are:

1.  Thread based code is easier to write (than learning a new language, 
or event model).
2.  Thread based code is easier to read (for new developers).
3.  CPU time is not what we're short of - developer time is.
4.  The documentation requirement is **a lot less** than writing our own 
language.

However, you want to use an inference engine so that's what we will do. 
 This will make it easier to port later and I hope that it's all going 
to work OK.  I don't really agree that it's going to be the most 
expedient way to get to our goal (I impatiently want to get this working 
ASAP) but I accept your decision.

TTFN

TJ

Stephen Blackheath wrote:

>Tony,
>
>Ah...  You need to look inside my head to understand why I think this is such 
>a good idea.
>
>It's possibly a little hard to explain, but I'll try...
>
>I've already explained the advantages because the code can be mobile (in a 
>similar way to Java).  But there are good reasons for the language itself.
>
>Think about the problems of writing code for any application that handles TCP 
>connections (as this code will).  The way I see it, there are two 
>fundamentally different approaches (I think they can correctly be called 
>'paradigms'), and most applications will use a bit of both:
>
>  * Threaded:  All state relating to the connection (which can be very 
>complex when you have to do any parsing) is contained in a thread.  The 
>thread lasts for as long as the connection does.
>- Advantages: The code simple to write, because maintaining state is not a 
>chore.
>- Disadvantages: It doesn't scale well, because if the application gets busy, 
>or the connections are of a long duration, then there are a lot of threads 
>consuming a lot of memory.
>
>  * Event-driven:  Each event executes in a short period of time - i.e. no 
>blocking is allowed.  At the commencement of each event, state must be 
>retrieved from memory/disk.  An event then typically makes changes to the 
>state of the system before returning.
>- Advantage: Efficient management of resources, because when an event isn't 
>firing, its state is "on ice" - i.e. you can efficiently cache it to disk, 
>etc.  You also completely avoid all the problems of threading - race 
>conditions, deadlocks, etc, etc.
>- Disadvantage: The code involves a lot of looking things up in hash tables 
>and generally mucking about with state.
>
>A typical web application uses both of these:  An HTTP request is itself an 
>event.  When it starts, you have no state, and you have to retrieve it based 
>on tokens sent in the request.  But the processing of the event is itself 
>thread-based.  If the thread has to request something from a database or 
>legacy system, then it blocks.
>
>As you know, as much as I like threads (and I do), I have a strong preference 
>for the event-driven model.  I am aware that this makes me a little unusual.  
>Everybody else thinks I am a masochist.  But I like it, because the logic is 
>more "pure".  In some ways, threads tie you down and make you think linearly. 
> When you have a complex application with a lot of things going on, you need 
>a lot of threads.  For example, cleaning up unused resources, and handling 
>timing-related things like re-sending requests which haven't had a response.  
>These two things are often done with threads.  But the second thing starts to 
>get complex with threads, and becomes easier in the event-driven model.
>
>In most code people avoid the problem of re-sending requests by simply 
>relying on TCP.  This won't necessarily work for our application, because it 
>works unusually as far as TCP traffic is concerned:  In a normal TCP 
>application, you're talking to ONE remote host, and that's the host you have 
>to talk to.  Your job isn't done until you've talked to that host.  That's 
>the thought-process behind the design of TCP.  In our application, however, 
>if a node isn't responding, we are better off talking to another node that 
>is.  And that means we'll need to write extra logic that isn't going to be 
>handed to us by the operating system.  Think about how difficult it is to 
>write that kind of code in threaded C++.  The thread paradigm is just too 
>'linear'.
>
>What this language (the language is called 'Raisen' for the moment) does in 
>theory is to take the chore out of the event-driven paradigm.  And writing 
>this stuff in C++ is definitely a chore.
>
>And think about this:  We won't need to write any code to serialize a billion 
>different data structures so they can be sent between nodes.  All we do is 
>output facts as XML, optionally bzip2 and encrypt them, and send them.  (Or, 
>put them through a style sheet so they turn into HTML - this system will 
>actually need a user interface too.)
>
>My next plan is to illustrate the concept by writing some code in Raisen that 
>services an HTTP request.  That's a good example, I think, because it's a 
>basic building block of the Grapevine.
>
>I think we'll also find that the 'domains' concept provides a considerably 
>better security model than Java when we eventually get to sandboxing (which 
>we are definitely not going to do right now).  The problem with Java is that 
>for one package to talk to another, it has to make certain methods public.  
>This means that absolutely every package must be meticulously hardened 
>against attack by untrusted code.  (So, untrusted code can't run in the same 
>VM as third-party code, because the former may exploit security holes in the 
>latter).  With domains in Raisen, things are more precisely specified than 
>just 'public'.
>
>I'm sure the language will have its frustrations, too.  The biggest of which 
>will be that we'll periodically find that it just can't *do* something.  In 
>those situations, we can write that something in C++ and provide a Raisen 
>interface for it.  Remember that it isn't really intended to be a 
>general-purpose language - it's just for this application.
>
>-- And another advantage of this language:  It'll make the Java, Python, 
>PlayStation, WinCE, Palm Pilot, etc, ports of Grapevine easy to write, and 
>there won't be any risk of this leading to Grapevine nodes that don't have 
>the correct logic.  (That was a big problem for Gnutella early on.)
>
>
>Steve
>
>On Friday 05 October 2001 02:48, Anthony Jones wrote:
>
>>Steve,
>>
>>Cool. I understand now.  The big question is - what do we use this for?
>>
>>TJ
>>
>>Stephen Blackheath wrote:
>>
>>>Tony,
>>>
>>>Here's what it all means:
>>>
>>>The facts are describing the attributes of a collection of nine animals.
>>>
>>>The rules are saying "Find me a large cat, a small cat, a dog
>>>with medium hair, and a dog with long hair, all four animals being of the
>>>same colour, where the cats have the same hair length and the dogs are the
>>>same size."
>>>
>>>Out of the nine animals, there is one collection of four animals that
>>>meets this constraint:
>>>
>>> <animal colour="calico" hair="short" size="small" type="cat"/>
>>> <animal colour="calico" hair="medium" size="medium" type="dog"/>
>>> <animal colour="calico" hair="short" size="large" type="cat"/>
>>> <animal colour="calico" hair="long" size="medium" type="dog"/>
>>>
>>>If there were more than one solution, then the rule would fire more than
>>>once.
>>>
>>>The 'a1 == ' , 'a2 == ', etc... bind the matched animals to variables
>>>which can be used later, and so do the [C] [S] and [H].  These variables
>>>can be used anywhere before the rule's semicolon.  So, you could add
>>>commands to the rule that make use of the variables C, S, H, a1, a2, a3
>>>and a4.
>>>
>>>For example, you could add this onto the end of the rules:
>>>
>>> ...rules...,
>>> print "the animals are all coloured "+C;
>>>
>>>
>>>Steve
>>>
>>>On Thursday 04 October 2001 01:28, Anthony Jones wrote:
>>>
>>>>Cool.  It looks like it works.  It doesn't make any sense to me though. 
>>>>I don't know what it's trying to achieve.
>>>>
>>>...
>>>
>>>>><grapevine>
>>>>>
>>>>><demo.animal>
>>>>>
>>>>>  <rules>
>>>>>    a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
>>>>>    a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
>>>>>    a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
>>>>>    a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
>>>>>  </rules>
>>>>>
>>>>>  <facts>
>>>>>    <animal type="cat" colour="yellow" size="large"  hair="short"/>
>>>>>    <animal type="cat" colour="calico" size="large"  hair="short"/>
>>>>>    <animal type="cat" colour="calico" size="small"  hair="short"/>
>>>>>    <animal type="dog" colour="brown"  size="medium" hair="long"/>
>>>>>    <animal type="cat" colour="brown"  size="small"  hair="medium"/>
>>>>>    <animal type="dog" colour="brown"  size="small"  hair="short"/>
>>>>>    <animal type="dog" colour="calico" size="medium" hair="medium"/>
>>>>>    <animal type="dog" colour="brown"  size="large"  hair="medium"/>
>>>>>    <animal type="dog" colour="calico" size="medium" hair="long"/>
>>>>>  </facts>
>>>>></demo.animal>
>>>>></grapevine>
>>>>>
>>>.
>>>
>>_______________________________________________
>>Grapevine-devel mailing list
>>Gra...@li...
>>https://lists.sourceforge.net/lists/listinfo/grapevine-devel
>>
>
>