From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2000-December/000075.html | 55 ++++++++++++++++++ pipermail/nel/2000-December/000076.html | 67 ++++++++++++++++++++++ pipermail/nel/2000-December/000077.html | 90 ++++++++++++++++++++++++++++++ pipermail/nel/2000-December/000078.html | 80 +++++++++++++++++++++++++++ pipermail/nel/2000-December/000079.html | 71 ++++++++++++++++++++++++ pipermail/nel/2000-December/000080.html | 51 +++++++++++++++++ pipermail/nel/2000-December/000081.html | 95 ++++++++++++++++++++++++++++++++ pipermail/nel/2000-December/000082.html | 75 +++++++++++++++++++++++++ pipermail/nel/2000-December/000083.html | 72 ++++++++++++++++++++++++ pipermail/nel/2000-December/000084.html | 89 ++++++++++++++++++++++++++++++ pipermail/nel/2000-December/000085.html | 74 +++++++++++++++++++++++++ pipermail/nel/2000-December/000086.html | 76 +++++++++++++++++++++++++ pipermail/nel/2000-December/author.html | 57 +++++++++++++++++++ pipermail/nel/2000-December/date.html | 57 +++++++++++++++++++ pipermail/nel/2000-December/index.html | 79 ++++++++++++++++++++++++++ pipermail/nel/2000-December/subject.html | 57 +++++++++++++++++++ pipermail/nel/2000-December/thread.html | 79 ++++++++++++++++++++++++++ 17 files changed, 1224 insertions(+) create mode 100644 pipermail/nel/2000-December/000075.html create mode 100644 pipermail/nel/2000-December/000076.html create mode 100644 pipermail/nel/2000-December/000077.html create mode 100644 pipermail/nel/2000-December/000078.html create mode 100644 pipermail/nel/2000-December/000079.html create mode 100644 pipermail/nel/2000-December/000080.html create mode 100644 pipermail/nel/2000-December/000081.html create mode 100644 pipermail/nel/2000-December/000082.html create mode 100644 pipermail/nel/2000-December/000083.html create mode 100644 pipermail/nel/2000-December/000084.html create mode 100644 pipermail/nel/2000-December/000085.html create mode 100644 pipermail/nel/2000-December/000086.html create mode 100644 pipermail/nel/2000-December/author.html create mode 100644 pipermail/nel/2000-December/date.html create mode 100644 pipermail/nel/2000-December/index.html create mode 100644 pipermail/nel/2000-December/subject.html create mode 100644 pipermail/nel/2000-December/thread.html (limited to 'pipermail/nel/2000-December') diff --git a/pipermail/nel/2000-December/000075.html b/pipermail/nel/2000-December/000075.html new file mode 100644 index 00000000..2d4ac8d5 --- /dev/null +++ b/pipermail/nel/2000-December/000075.html @@ -0,0 +1,55 @@ + + + + [Nel] Server on GNU/Linux + + + + + + +

[Nel] Server on GNU/Linux

+ Valignat Cedric + valignat@nevrax.com
+ Mon, 4 Dec 2000 16:09:23 +0100 +

+
+ +
Hello everybody,
+
+At least it comes, you should be able to get something to compile and running
+under GNU/Linux platforms ...
+
+Checkout the INSTALL file, it will show you the path to follow :-)
+
+
+Cedric.
+
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000076.html b/pipermail/nel/2000-December/000076.html new file mode 100644 index 00000000..f887eac0 --- /dev/null +++ b/pipermail/nel/2000-December/000076.html @@ -0,0 +1,67 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Jean-Noel Moyne + jnmoyne@tibco.com
+ Fri, 8 Dec 2000 09:53:09 +0100 +

+
+ +
Just had a look at your site and your project because my brother is
+going to work with you guys (as a graphic artist). I see that you have
+need for fast reliable real-time asynchronous (and probably one to many)
+network transport for your messaging. That need being for server to
+server communication, not server to client.
+
+You should have a look at PGM, which is an open reliable multicast
+protocol designed by Cisco and TIBCO (the company I work for), which is
+design to solve just this kind of problems in the most efficient way.
+
+While TIBCO makes a complete messaging system that will use PGM and that
+is a commercial product, we are also releasing an Open Source version of
+the PGM protocol stack (which is probably all you need, and all you
+would want to use, being an Open Source project yourself).
+
+As a suggestion from a network professional with a lot of experience
+designing large scale scalable real time oriented distributed systems,
+you should take a look at it.
+
+http://pgm.tibco.com/
+
+    JNM
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000077.html b/pipermail/nel/2000-December/000077.html new file mode 100644 index 00000000..e1f2e748 --- /dev/null +++ b/pipermail/nel/2000-December/000077.html @@ -0,0 +1,90 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Dim Segebart + zager@teleaction.com
+ Fri, 08 Dec 2000 11:39:18 +0100 +

+
+ +
Hello !
+Just one question.
+
+>From http://pgm.tibco.com/draft-speakman-pgm-spec-04.txt
+>>> PGM runs over a datagram multicast protocol such as IP multicast [5].
+
+AFAIK, many ISP's ban multicast traffic and many users'll be unable to use
+software based on it.
+Am I wrong or missing something ?
+TIA
+
+--
+Dim
+
+
+Jean-Noel Moyne wrote:
+
+> Just had a look at your site and your project because my brother is
+> going to work with you guys (as a graphic artist). I see that you have
+> need for fast reliable real-time asynchronous (and probably one to many)
+> network transport for your messaging. That need being for server to
+> server communication, not server to client.
+>
+> You should have a look at PGM, which is an open reliable multicast
+> protocol designed by Cisco and TIBCO (the company I work for), which is
+> design to solve just this kind of problems in the most efficient way.
+>
+> While TIBCO makes a complete messaging system that will use PGM and that
+> is a commercial product, we are also releasing an Open Source version of
+> the PGM protocol stack (which is probably all you need, and all you
+> would want to use, being an Open Source project yourself).
+>
+> As a suggestion from a network professional with a lot of experience
+> designing large scale scalable real time oriented distributed systems,
+> you should take a look at it.
+>
+> http://pgm.tibco.com/
+>
+>     JNM
+> _______________________________________________
+> Nel mailing list
+> Nel@nevrax.org
+> http://www.nevrax.org/mailman/listinfo.cgi/nel
+
+
+
+ + + + +
+

+ diff --git a/pipermail/nel/2000-December/000078.html b/pipermail/nel/2000-December/000078.html new file mode 100644 index 00000000..e1cfefb6 --- /dev/null +++ b/pipermail/nel/2000-December/000078.html @@ -0,0 +1,80 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Vincent Archer + archer@nevrax.com
+ Tue, 12 Dec 2000 11:08:20 +0100 +

+
+ +
According to Jean-Noel Moyne:
+> You should have a look at PGM, which is an open reliable multicast
+> protocol designed by Cisco and TIBCO (the company I work for), which is
+> design to solve just this kind of problems in the most efficient way.
+
+Hmmm, about everyone around started talking about, then dismissing it
+as unsuited to our needs, but that's chiefly due to one misunderstanding.
+
+At first we didn't see the "server to server" sentence.
+
+We still don't know how well multicasting can be useful in our server
+architecture, because so far, we have very few one-to-many messages
+across servers. Most services discuss with a specific target on a specific
+service.
+
+However, we still have lots of discussion for the "world service",
+i.e. the service which "simulates" the world and run the various objects
+and NPC agents. That one might be a candidate for a multicast protocol,
+since we can expect replication of objects across multiple world services.
+
+This tie in with another question which I didn't had time to reply to,
+regarding how to "split" the world across the multiple world services.
+If the split is done by geography (the UO model), then there is little
+need of a PGM-based protocol, because most objects will be accessed by
+2 world services (edges), or at most 3 (T-intersections). However, if the
+split is done instead by reference (i.e. we cluster an agent with the
+agents that refer to it more often), then we have a higher redundancy
+of agents on servers, and a multicast is probably the best method to
+send message to these agents.
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + + + +
+

+ diff --git a/pipermail/nel/2000-December/000079.html b/pipermail/nel/2000-December/000079.html new file mode 100644 index 00000000..a10bb898 --- /dev/null +++ b/pipermail/nel/2000-December/000079.html @@ -0,0 +1,71 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Vincent Archer + archer@nevrax.com
+ Tue, 12 Dec 2000 11:11:10 +0100 +

+
+ +
According to Dim Segebart:
+> Hello !
+> Just one question.
+> 
+> >From http://pgm.tibco.com/draft-speakman-pgm-spec-04.txt
+> >>> PGM runs over a datagram multicast protocol such as IP multicast [5].
+> 
+> AFAIK, many ISP's ban multicast traffic and many users'll be unable to use
+> software based on it.
+> Am I wrong or missing something ?
+> TIA
+
+And Jean-Noel Moyne said:
+> network transport for your messaging. That need being for server to
+> server communication, not server to client.
+
+Note "server to server". What Jean-Noel was suggesting was not a protocol
+to communicate with the clients, but a protocol to communicate between
+the various servers that constitute a world cluster.
+
+Since these clusters will be located in a single facility, on a dedicated
+switch, the issue of IP filtering do not apply :)
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + +
+

+ diff --git a/pipermail/nel/2000-December/000080.html b/pipermail/nel/2000-December/000080.html new file mode 100644 index 00000000..31b1bb0e --- /dev/null +++ b/pipermail/nel/2000-December/000080.html @@ -0,0 +1,51 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ MIGUEL ANGEL BLANCH LARDIN + x5101920@fedro.ugr.es
+ Tue, 12 Dec 2000 11:13:59 +0100 (MET) +

+
+ +
> At first we didn't see the "server to server" sentence.
+
+Ok, I have a dummy question, but when it is better to have multicast 
+to a server delivering the messages to the rest of servers?
+
+How portable/compatible is mulitcast technology?
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000081.html b/pipermail/nel/2000-December/000081.html new file mode 100644 index 00000000..cc2d1ea2 --- /dev/null +++ b/pipermail/nel/2000-December/000081.html @@ -0,0 +1,95 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Vincent Archer + archer@nevrax.com
+ Tue, 12 Dec 2000 11:37:00 +0100 +

+
+ +
According to MIGUEL ANGEL BLANCH LARDIN:
+> > At first we didn't see the "server to server" sentence.
+> 
+> Ok, I have a dummy question, but when it is better to have multicast 
+> to a server delivering the messages to the rest of servers?
+
+Quite simple: When you need to send the same message to more than one
+server. As soon as you need to send a message to multiple servers,
+you will tie up bandwidth and CPU resending the same message over and over
+to each server.
+
+Consider the following model. Each agent (which represent an object, NPC,
+PC, the door, the lamp, whatever entity in your world) is represented
+typically by an object in a "world service process". Once your world
+becomes large, you need multiple processes. What happens when an agent
+want to "talk" to another agent on a different process. The agent, in an
+ideal (and OO) world, merely talks to an object located in its process
+space, said object being either the recipient agent itself, or merely a
+replica, which will forward the message across the network to the real
+agent.
+
+You don't need multicast for that: its straight 1-to-1.
+
+However, what if the message is "what is your current XYZ". That's a fairly
+frequent question. If you need to query across the network, you'll quickly
+end up loading the net, just to find the value three variables.
+
+That's where PGM/multicast intervenes. In that model, the agent, when he
+changes some of his variables, notifies the replica that "XYZ are now...".
+I spoke about how the world services organise where an agent resides. In
+some models, you have about one, maybe two replicas, which you can notify
+using a standard TCP stream. Or RDP. But, if you want a load-balancing
+system, you quickly end up with a replica of an object in most world
+service processes. It becomes then more efficient to multicast the updates
+as above to all processes, and update them all in one sweep.
+
+> How portable/compatible is mulitcast technology?
+
+Multicast is working, right now. However, to work across separate networks,
+it requires specific support from IP routers, and resources, which most
+providers aren't willing to dedicate (multi-network multicast is mostly
+used for video/audio "broadcasts", video conferencing or shows).
+
+As for PGM, well, the current library has lots of empty directories and
+"TODO" notes in comments, so it's clearly a work in progress :)
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000082.html b/pipermail/nel/2000-December/000082.html new file mode 100644 index 00000000..aa9812a0 --- /dev/null +++ b/pipermail/nel/2000-December/000082.html @@ -0,0 +1,75 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ MIGUEL ANGEL BLANCH LARDIN + x5101920@fedro.ugr.es
+ Tue, 12 Dec 2000 11:48:18 +0100 (MET) +

+
+ +
> That's where PGM/multicast intervenes. In that model, the agent, 
+when he
+> changes some of his variables, notifies the replica that "XYZ are 
+now...".
+> I spoke about how the world services organise where an agent 
+resides. In
+> some models, you have about one, maybe two replicas, which you can 
+notify
+> using a standard TCP stream. Or RDP. But, if you want a 
+load-balancing
+> system, you quickly end up with a replica of an object in most world
+> service processes. It becomes then more efficient to multicast the 
+updates
+> as above to all processes, and update them all in one sweep.
+
+Ok, I always have though of load balancing as load-work division 
+between servers.
+
+I think that the above kind of working can have several inconsistences 
+, just take a look to some distributed Mutual exclusion algos.
+
+Just imagine that both copies of a object multicast different 
+positions, you have to choose what is the best one, and whatever your 
+choose is, it will be wrong, and servers can't be wrong.
+
+Replycating work can be a real pain.
+And for what you have said multicast isn't a solution for end-users.
+
+I think that IPv6 will fix these things, by having a multicast in the 
+standart, isn't it?
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000083.html b/pipermail/nel/2000-December/000083.html new file mode 100644 index 00000000..6a8ba32a --- /dev/null +++ b/pipermail/nel/2000-December/000083.html @@ -0,0 +1,72 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ Vincent Archer + archer@nevrax.com
+ Tue, 12 Dec 2000 12:11:26 +0100 +

+
+ +
According to MIGUEL ANGEL BLANCH LARDIN:
+> Just imagine that both copies of a object multicast different 
+> positions, you have to choose what is the best one, and whatever your 
+> choose is, it will be wrong, and servers can't be wrong.
+
+Ahem, no. I might have used object and agent in various contexts, but
+an agent is the only one which is authorised to change its state. The
+other objects are "replica", or passive objects. Each agent may exist
+only as a single copy over the set of processes, and he is the entity
+responsible for updating the local states of the replica objects in
+the other processes.
+
+If you want "what is your XYZ", the local replica answers. However, if
+you want "teleport to XYZ", the message is transmitted across the network
+to the unique agent, which updates its internal state, and then retransmits
+to all replicas "set internal state XYZ". And the latter is when multicast
+helps when there are many replicas to update.
+
+> Replycating work can be a real pain.
+
+Hey, if I could buy a terahertz processor and have everything run on a
+single process, I'd be happy too :)
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000084.html b/pipermail/nel/2000-December/000084.html new file mode 100644 index 00000000..0d5d29f9 --- /dev/null +++ b/pipermail/nel/2000-December/000084.html @@ -0,0 +1,89 @@ + + + + [Nel] Suggestion for the NeL network library / architecture + + + + + + +

[Nel] Suggestion for the NeL network library / architecture

+ MIGUEL ANGEL BLANCH LARDIN + x5101920@fedro.ugr.es
+ Tue, 12 Dec 2000 12:20:32 +0100 (MET) +

+
+ +
> Ahem, no. I might have used object and agent in various contexts, 
+but
+> an agent is the only one which is authorised to change its state. 
+The
+> other objects are "replica", or passive objects. Each agent may 
+exist
+> only as a single copy over the set of processes, and he is the 
+entity
+> responsible for updating the local states of the replica objects in
+> the other processes.
+>
+> If you want "what is your XYZ", the local replica answers. However, 
+if
+> you want "teleport to XYZ", the message is transmitted across the 
+network
+> to the unique agent, which updates its internal state, and then 
+retransmits
+> to all replicas "set internal state XYZ". And the latter is when 
+multicast
+> helps when there are many replicas to update.
+
+Ok, as far as I am thinking about agents, a replica only show info but 
+can't process code. So all the modificators should be send to the 
+main agent, that then update.
+
+There is still the possibility of an object to get two contradictory 
+updates at the same time. To avoid this you should order the messages, 
+something that I feel is unefficient and ugly.
+
+Just image agent is a ball, and then two user decide to kick the two 
+replica of the agent, so the replicas get the kick commnand and send 
+it to the agent.
+
+> > Replycating work can be a real pain.
+>
+> Hey, if I could buy a terahertz processor and have everything run on 
+a
+> single process, I'd be happy too :)
+
+If you need a terahertz processor to run the server, you better start 
+again the design stage.
+
+Just I want to note that replycanting the work can lead to ugly 
+things and race conditions.
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000085.html b/pipermail/nel/2000-December/000085.html new file mode 100644 index 00000000..9df79cba --- /dev/null +++ b/pipermail/nel/2000-December/000085.html @@ -0,0 +1,74 @@ + + + + [Nel] Bugs on nevrax.org + + + + + + +

[Nel] Bugs on nevrax.org

+ David Mentre + David.Mentre@inria.fr
+ 22 Dec 2000 10:06:41 +0100 +

+
+ +
Hi all nelers,
+
+There are two bugs at nevrax.org:
+
+ 1. the webmaster@nevrax.org address is invalid:
+
+... while talking to www.nevrax.org.:
+>>> RCPT To:<webmaster@nevrax.org>
+<<< 550 5.1.1 <webmaster@nevrax.org>... User unknown
+550 5.1.1 <webmaster@nevrax.org>... User unknown
+
+
+ 2. the bug system is no longer working at the time of this email:
+
+http://www.nevrax.org/bugs/reports.cgi
+Software error:
+
+Can't connect to database server. at globals.pl line 40. 
+
+For help, please send mail to the webmaster (webmaster@nevrax.org),
+giving this error message and the time and date of the error. 
+
+
+Hope it helps,
+Best regards,
+d.
+-- 
+ David.Mentre@inria.fr -- http://www.irisa.fr/prive/dmentre/
+ Opinions expressed here are only mine.
+
+
+ + + +
+

+ diff --git a/pipermail/nel/2000-December/000086.html b/pipermail/nel/2000-December/000086.html new file mode 100644 index 00000000..cb98ac0f --- /dev/null +++ b/pipermail/nel/2000-December/000086.html @@ -0,0 +1,76 @@ + + + + [Nel] Bugs on nevrax.org + + + + + + +

[Nel] Bugs on nevrax.org

+ Vincent Archer + archer@nevrax.com
+ Fri, 22 Dec 2000 10:22:08 +0100 +

+
+ +
According to David Mentre:
+> There are two bugs at nevrax.org:
+> 
+>  1. the webmaster@nevrax.org address is invalid:
+> 
+> ... while talking to www.nevrax.org.:
+> >>> RCPT To:<webmaster@nevrax.org>
+> <<< 550 5.1.1 <webmaster@nevrax.org>... User unknown
+> 550 5.1.1 <webmaster@nevrax.org>... User unknown
+
+Hrrrmmm? There's a comment in front of the alias (can't figure out why.
+My name's there, but it got commented out).
+
+>  2. the bug system is no longer working at the time of this email:
+> 
+> http://www.nevrax.org/bugs/reports.cgi
+> Software error:
+> 
+> Can't connect to database server. at globals.pl line 40. 
+
+No error messages, and the sql server went down. I'll keep an eye on it
+for today.
+
+Please note that the Nevrax offices are closed during the Christmas-New Year
+period. This list and the site shouldn't suffer, but don't expect prompt
+response to any problem or question you may raise.
+
+Happy holiday season all, and see you next century!
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + +
+

+ diff --git a/pipermail/nel/2000-December/author.html b/pipermail/nel/2000-December/author.html new file mode 100644 index 00000000..c529c94c --- /dev/null +++ b/pipermail/nel/2000-December/author.html @@ -0,0 +1,57 @@ + + + + The Nel 2000-December Archive by Author + + + +

2000-December Archives by Author

+ +

Starting: Mon Dec 4 15:09:23 2000
+ Ending: Fri Dec 22 09:22:08 2000
+ Messages: 12

+

+

+ Last message date: + Fri Dec 22 09:22:08 2000
+ Archived on: Fri Dec 22 10:19:00 2000 +

+

+

+

+ This archive was generated by + Pipermail 0.05 (Mailman edition). + + + diff --git a/pipermail/nel/2000-December/date.html b/pipermail/nel/2000-December/date.html new file mode 100644 index 00000000..2b87848b --- /dev/null +++ b/pipermail/nel/2000-December/date.html @@ -0,0 +1,57 @@ + + + + The Nel 2000-December Archive by Date + + + +

2000-December Archives by Date

+ +

Starting: Mon Dec 4 15:09:23 2000
+ Ending: Fri Dec 22 09:22:08 2000
+ Messages: 12

+

+

+ Last message date: + Fri Dec 22 09:22:08 2000
+ Archived on: Fri Dec 22 10:19:00 2000 +

+

+

+

+ This archive was generated by + Pipermail 0.05 (Mailman edition). + + + diff --git a/pipermail/nel/2000-December/index.html b/pipermail/nel/2000-December/index.html new file mode 100644 index 00000000..e74c8b2e --- /dev/null +++ b/pipermail/nel/2000-December/index.html @@ -0,0 +1,79 @@ + + + + The Nel 2000-December Archive by Thread + + + +

2000-December Archives by Thread

+ +

Starting: Mon Dec 4 15:09:23 2000
+ Ending: Fri Dec 22 09:22:08 2000
+ Messages: 12

+

+

+ Last message date: + Fri Dec 22 09:22:08 2000
+ Archived on: Fri Dec 22 10:19:00 2000 +

+

+

+

+ This archive was generated by + Pipermail 0.05 (Mailman edition). + + + diff --git a/pipermail/nel/2000-December/subject.html b/pipermail/nel/2000-December/subject.html new file mode 100644 index 00000000..5d8089c7 --- /dev/null +++ b/pipermail/nel/2000-December/subject.html @@ -0,0 +1,57 @@ + + + + The Nel 2000-December Archive by Subject + + + +

2000-December Archives by Subject

+ +

Starting: Mon Dec 4 15:09:23 2000
+ Ending: Fri Dec 22 09:22:08 2000
+ Messages: 12

+

+

+ Last message date: + Fri Dec 22 09:22:08 2000
+ Archived on: Fri Dec 22 10:19:00 2000 +

+

+

+

+ This archive was generated by + Pipermail 0.05 (Mailman edition). + + + diff --git a/pipermail/nel/2000-December/thread.html b/pipermail/nel/2000-December/thread.html new file mode 100644 index 00000000..e74c8b2e --- /dev/null +++ b/pipermail/nel/2000-December/thread.html @@ -0,0 +1,79 @@ + + + + The Nel 2000-December Archive by Thread + + + +

2000-December Archives by Thread

+ +

Starting: Mon Dec 4 15:09:23 2000
+ Ending: Fri Dec 22 09:22:08 2000
+ Messages: 12

+

+

+ Last message date: + Fri Dec 22 09:22:08 2000
+ Archived on: Fri Dec 22 10:19:00 2000 +

+

+

+

+ This archive was generated by + Pipermail 0.05 (Mailman edition). + + + -- cgit v1.2.1