Neil Nelson wrote:

> But essentially there are a variety of data communication goals

> that require different approaches or controls to get a best

> result. Following my brief OOP understanding: we should

> encapsulate or allow only local access to data that is expected

> to be only used local, pass data from routine/process to routine/

> process that is only present for that communication, and then

> have perhaps several increasing spheres of global-like data that

> a number of processes have access to.



The main problem to me was that it was nearly inpossible to set a

communications standard that would be efficient with all programming

languages. What a RAM-Drive offers is practicaly a hard disk on

steroids, as it is as fast as memory and as easy to use as a harddisk.



Setting data under filenames same to the names of the proceses seems to

immediately solve the problem with keeping the data with the process.

And do not worry about the slow down that would occur when data is

stored in the files in various formats, as messing around with memory is

as fast as it can get, actualy the maximum speed at which an exectuable

can run. This of course means that there is no diffirence in preformance

between a 100MHz 486 that has it's RAM running on 133MHz refresh rate

and a 433MHz Pentium Celeron running it's RAM on the same refresh rate

(this is the case with my two computers).



But perhaps I have missed the point?



> The current hang-up with the parameter passing or socket method

> is that the method assumes that there is a hierarchy of control

> where, say, the calling program (client) initiates the activity

> the program or routine called.  Whereas the ICI is acoordina-

> tion of programs running essentially at the same control level.

> When the data is global, the access level is the same for every

> program/process that then works automatically for coordinated

> (as against hierarchical) processes.  And I would agree that it

> is not immediately obvious how sockets will obtain a coordina-

> ted method as against a hierarchical one.  Pipes might be an

> easier way to obtain a coordination.  However, since we are

> already using sockets for Internet communications, it may be

> useful to have some generalized socket method that obtains a

> coordination.  That is, it seems to me that the basic method is

> determined by the nature of the Internet.



My current skepticism about sockets is that Visual Basic might actualy

require a kind of interpreter for the socket (such as "mswinsck.ocx")

and secondly that DOS based programs will not be able to use that at

all, note asside that they are usualy much better data processors than

Windows based programs.



Pipes and other immediate stuff show an obvious weakness for the

requirement for them to be executed immediately. This would either cause

the computer to sink in ocasional request floods or would at least

require the send/recieve program to have a built-in queue (secondly I

might note here that it is not clear how would your send/recieve program

know where to transmit an incoming message). 



My solution with a virtrual disk does not reduce any options, not to

mention that files in it can easily be used as queues.



> But in general it is a matter of thinking through an idea and

> then getting it to work while keeping in mind any benefits of

> alternatives that could be integrated or have a more useful

> application for a particular case.  It may be that we need

> both methods for different purposes. 



I agree. I am sure there will be various requirements from various

programs and we would make use of all the diffirent kinds of

communication.



> E.g., LDAP--also mentined

> by Harold--

> 

> http://www.openldap.org/

> 

> is a kind of Internet directory standard that may be similar

> to your idea and have particular uses separate from those I am

> thinking about for sockets.



I will have a look at it.



--



Don't feel bad about asking/telling me anything, I will always gladly

reply.



Digging for info? Try AI Meta Search:

Http://WWW.AIMetaSearch.Com



MesonAI -- If nobody else wants to do it, why shouldn't we?(TM)

Http://WWW.MesonAI.Com

