Busy holiday; I'd hoped someone else might pick up this thread, but I'll see what I can do here:
A1Qicks wrote:what the advantages of a server over a database?
A database is a means of storing and retrieving large amounts of data, and a server is a means of making centralized resources available to clients.
In some cases a database may be a
database server in which is can accept requests and deliver data to clients without needing other software. For example MySQL, MongoDB and CouchDB are database servers, but SQLite is not.
That said, there are many kinds of servers for different tasks, and as servers go a database server is fairly limited in what it can do. Mostly it just stores and retrieves data, and broadcasting is beyond the scope of most DB servers.
When you only need to store and retrieve data among a relatively small number of trusted users, and when the database is only being used on a local network and not exposed to the Internet, you can use it directly for the types of tasks it's designed for, which even include use account management and authentication.
But if you need it to do anything more, or you need to protect it from being exposed to the Internet, most commonly a middleware is used, such as PHP, Python, Perl, or LiveCode, which sits between a Web server such as Apache and calls the database only within the server. So the user is making Web calls, Apache hands those off to the middleware, and the middleware deals with the database using sockets internal to the server. This protects the server from being exposed to the Internet directly, and allows greater functionality provided through the more general-purpose middleware.
Many chat services are implemented using HTTP, using the middleware to coordinate data with the clients. But as you found, in many systems this requires the client to poll the server, or use WebSockets or other newer options to receive notification of new messages.
When using a middleware tool like PHP or LiveCode it may not even be necessary to use a database to store the messages. In many cases the individual messages are of little value as discrete elements, equally useful if included as entries in a single log file such as we have with IRC chats.
So if you needed to make an HTTP-based Web chat service, the database is purely optional, and may be just exta overhead.
But you can make an even leaner system that uses sockets directly, provided your server allows you to run custom server software beyond Apache. A dedicated server or VPS will allow that, but a shared host won't, since it would be possible for a custom server application to affect other users sharing the machine.
If you're using a dedicated server or VPS, having a custom app like the Chat Server from the example I'd linked to is a very efficient solution, making full use of socket messages without needing to poll.
If you're using a shared hosting service you may have no choice but to use an HTTP-based solution, but in that case I'd check with the service to see if they have one pre-installed for use, which will usually be much simpler than making one from scratch - phpFreeChat is one example:
http://www.phpfreechat.net/
Even simpler, some chat software is available as a service you can plug into your Web site with a quick copy-and-paste of some JavaScript. The PHPFreeChat page has links to such services, and there are many others around.
A1Qicks wrote:1.
on socketClosed pSocket
delete line lineoffset(pSocket, sConnectedClients) of sConnectedClients
end socketClosed
Why is 'lineoffset' required? I'm just about following the concept of the code itself, but I don't understand why it can't just be "line pSocket of sConnectedClients". It would make sense that it would need the offset if LiveCode used it as a way to locate the line pSocket, but since it's an offset between the line pSocket (and therefore it has to find it anyway) and sConnectedClients, why is it "lineoffset(pSocket, sConnectedClients" of sConnectedClients" instead of "line pSocket of sConnectedClients"?
Short answer: because that's how it works.
Long answer:
The lineOffset function returns the number of the found line, which can then be used with get, put, delete, or other commands to act on that line.
Your suggestion that it would be useful to have something that would both find a given line and act on it chimes with my own preferences, but this was explored on the use-livecode list a while back and if you read the whole discussion you'll find some of the reasons this is not as trivial as it might seem:
http://runtime-revolution.278305.n4.nab ... 98214.html
Perhaps better would be to use an array rather than a list. Array access is generally faster to get and set values in than delimited text, and the syntax is some cases more compact, e.g.:
Code: Select all
delete variable sConnectedClients[pSocket]
2.
Wider question phrased in the form of this article:
on broadcastServerClientConnected pSocket
put pSocket & return after sConnectedClients
read from socket pSocket until return \
with message "broadcastServerMessageReceived"
end broadcastServerClientConnected
Where does pSocket come from? It's not a variable defined outside of the handlers nor a temporary one within the handlers; it corresponds certainly to each individual client (pSocket is a variable referring to whichever client is in use at any given time, yes?) but how does LiveCode automatically know that "on broadcastServerClientConnected pSocket" refers to the client sending the message?
I presume the answer lies in:
command broadcastServerStart
if not sRunning then
put true into sRunning
accept connections on port kPort \
with message "broadcastServerClientConnected"
end if
end broadcastServerStart
So the client connects and the connection causes the message "broadcastServerClientConnected" to be sent (presumably by the host to the host - or from the socket to the host? It doesn't specify and I can feel the coffee draining out of my brain fluid), and then broadcastServerClientConnected as a handler acts upon pSocket, but how does LiveCode know that pSocket refers to the client which prompted the message?
Short answer: because that's how it works.
Long answer:
Socket communications keep track of which socket and port are being affected (most often in the form <socket>:<port>, e.g. "100.100.100.100:80"), usually passed to the socket-related messages as an argument. Your hunch is confirmed by the Dictionary entry for the accept command, where it notes:
The callbackMessage is sent to the object whose script contains the accept command. Either one or two parameters are sent with this message. The first parameter is the IP address of the system or process making the connection. If a datagram is being accepted, the second parameter is the contents of the datagram.