This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is fully explained, and there are more tips, at my Power Browsing page.)
Page contents © TK Boyd, Sheepdog Software, 3/13.
This essay is an overview of Things You Might Want To Do... Names of parts, grand theory. Little "how to do it".
It also includes indications, if not always full explanations, of Things You Need to Understand if you want do go beyond the basics of merely visiting other people's web pages, or using other servers provided for you by other people... e.g. email servers.
(I haven't... because I don't know a lot about them!... gone into music or video servers. Sometimes they come from a simple file server... NAS (network attached storage). That is also something I haven't gone into... but... Note to Self... ought to. Many of the issues discussed below relate to NAS servers.)
If you want to.... over the internet, or maybe just over a LAN
To get very far with those, you'll need to master...
This page may start a bit slowly for some readers. If the early bits are "too easy" for you, you can read them quickly, can't you? If they are too hard, please write me, tell me where you wanted to go, and what was too hard?
I imagine that you are reading this on the display of some electronic device? If you aren't, pretend you are!
It is a nice, familiar (I hope!) example of what you are trying to do, if Google has brought you to the right place. I'm going to go through things you already know about, but explaining them in, perhaps, new- to- you terms.
To get it on your screen, you probably fired up a web browser (Firefox? Internet Explorer?)
You then typed something into that, and "said go", and a moment later this text was in front of you. Simple enough. That's "what you need to do", and I will be writing "what to do" essays to complement the one you are currently reading. This essay aims to clarify the right terms for what you may want to do.
If you weren't already here, the "may want to do" which you apparently already know how to do is "fetch a page from a webserver."
So... you already know how to do something. But do you know, in detail, what it is you've done?
What you've done is to fire up some client software in a client machine and accessed a web, or http, server, and obtained a page of html from the server.
The web browser (which was your "client software") takes what the server has sent to it, and presents it on the page in front of you in a somewhat more "human friendly" form than, fundamentally, it is actually in.
The page you are reading, at the time I wrote this, began with...
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!--DOCTYPE must be in caps, o6n first line of file, and replaces <html> See plh1fs.htm for more info--> <!--TB.SG//srv/s0broad.htm vers (tweak visible (c) in intro, too) 05 Mar 13 Spellchecked 05 Mar 13, 11:08 Validated (validator.w3.org) 05 Mar 13, 11:08 Links (validator.w3.org/checklink) 22Oct12xx
... and after some more even less human friendly stuff, led on to stuff like...
<p>If you weren't already here, the "may want to do" which you apparently already know <i>how</i> to do is "fetch a page from a webserver."</p> <p>So... you already know how to do something. But do you know, in detail, <i>what</i> it is you've done?</p>
We will move on in a moment, I promise... but just to recap that, and stress two words fundamental to all that this page is about:
To get where I think you are, reading this text on some electronic device, you, as a client, using client software on a client device, accessed a (web) server. It delivered "some stuff" in response to the request for service, and your browser turned that stuff into what I intended you to see when I wrote the stuff that the server delivered to you!
Simple concepts! Just sometimes a little tricky to get everything working exactly as it should!
Do you want to "publish" things "on the web", for other people to read? It is easy! The essay you are reading goes way beyond everything you need to know to publish. I only went into all that about clients accessing web servers as a starting point for what this essay is about!
That's my best shot at getting you started with "what is a server?" and "what is a client?". You probably aren't yet "done" with mastering what they are... but as you embark upon reading the following, I hope I have given you a foundation upon which you can now build?
Remember: This essay is not for people who just want to publish something on the web. This next section may sound like it, but it is going to go into some of what's behind "ordinary" web publishing, to further strengthen your grasp of some concepts fundamental to more exciting things which we will come to in due course.
The page you are reading comes from a single file on a web server somewhere. I have very limited access to that server, though I do have slightly more access than you do. You can read this file. I can read it, but I can also remove it from the server, or replace it with a modified version.
You read the file with a web browser, as would I. If I want to remove the file, or replace it with a modified version, I access the server via FTP (much more on FTP later). Even "going in" via FTP, I have only limited access to the server.
So who has more than limited access to the server? The server admin. ("Admin" being short for "administrator".)
The server's admin can create new resources on the server. The admin controls the users of the server, and determines their privileges. When I signed up with the company that makes my small corner of the server available to me, it created a folder which is where you are taken when you ask for "sheepdogguides.com". The admin gave me the password needed to "get into" that folder for anything more than read access. One of an admin's most critical roles is ensuring the security of the server. Only the right people should be able to do the things that can be done!
What I've called "the company" here is more usually referred to as a "web hosting service". It is giving access to a "service" and "server", in the narrow, computing sense, but in "web hosting service", we are really using the term in the more everyday sense of, say, "train service". (Not so very different, in general terms, I suppose.) I have used www.1and1.com and www.1and1.co.uk for many years, very happily. (If you go on from the first link to open an account, it help$ me... but i wouldn't be recommending them unless happy with their service and prices.)
A little sidebar....
This essay is trying to help you get going with various client/ server set ups. I've made a start by trying to discuss something you probably know about... "using the internet" (to view pages from "the World Wide Web"), but describing that activity in "client/ server" terms. I'm not making an analogy... using the internet really is a client/ server activity. But not a lot of people understand it in those terms, nor need to.
In this sidebar I'd like to mention a few things inherent in web browsing which are not, essentially, matters of How Client Server works.
First there is the "magic" of links. Most web pages are littered with things you can click on which will take you someplace else. For instance, I would like it if sometime you visit my page with freeware and shareware for Windows users. (It will open in a new window or tab, so you just close that to get back here.)
You could get there simply by going, by hand, to...
... but, built into what you downloaded when you downloaded what you are reading now, is a "quick way" to make your browser do for you what you could do by hand. A web page is still served to the client you are controlling... but there's nothing special about the transaction.
Another "bit of magic" taken care of elsewhere is the generation of dynamic content. If you use Google to search for a page about, say, making maps, the computer at Google puts together a new page of stuff, just for you, from the latest material available. But that page is requested, and it is sent out, by "simple", "ordinary" client/ server "stuff" which we have already covered. Many servers serve up dynamically created pages. For example Amazon.
I suppose there is "a little trick" in things like the Google search. You have not only asked for a page, but you added a message to your request saying what sort of things you want on the page. But that will have to be a story for another day.
... end of sidebar
Whew! Take a break... you've earned it! And we've come to a good place to stop for a moment, catch our breath
As I said earlier, you've used someone else's server just to look at this page! (Probably... you did, if you got it over the internet.) And I used someone else's server to make it available to you. It didn't come from my server. I wrote a file of html on my PC, and then uploaded it (using an FTP client program) to the hard drives of the nice people at 1and1.com, and they provide the FTP server I used, and the web server you used. And I paid them, on behalf of both of us.
You use a web server, and an search engine (another server) when you search for something using Google.com.
You are free to use my Arduserver server... a $40 piece of discrete hardware that only needs to be connected to the internet through "other stuff" which I have anyway, other stuff that I use to send and receive email, to browse the web, to publish stuff such as what you are reading. (The link takes you to an ordinary web-page ABOUT the Arduserver. From there, you can access specific instances of the hardware, with their built in servers.)
But you have limited permissions at any of those servers. It is all a bit "look, but don't touch".
While there are many issues specific to specific servers, there are some issues common to almost all servers.
For a start, let's get a little phraseology out of the way. You can speak of "setting up a server", or of "providing a service". As long as you keep the term "service" narrowly defined, the two are much the same thing, from Windows XP onwards, at least.
If you run "services.msc", you will see a (to me) quite daunting list of "things" that are running in a computer even when it is "doing nothing. (It is no wonder they are so fragile, given all the "bits" that must work together.)
"When you were a child", and merely ran nice simple applications, you could see they were running, and they were fairly independent entities. If you progress onward, and set up services on your computer, you are moving to a new level. Happily, there are packages to make it easy to install the services.
Be aware, though, that the sort of services talked about below require a deal of administration. Settings need to be tweaked, for many of the services, you need to set up users, determine their passwords, what priviledges they have, etc, etc. These chores are usually done via special programs for administering the server. You are the "system admin(istrator)". The name is simple and straightforward, at least.
So! That's one service (web page server) looked at in some detail, and some general points covered. Let's look at some specific servers/ services...
I would commend to you a short "definitions" page I've written. It may consolidate things you've already grasped... or alert you to some things about client/ server work that you need to grasp! (It will open in a new window or tab, so you can get back here easily.)
I'm now going to romp through a whirlwind tour of some services you could, without a lot of trouble, put on the web yourself. I'm not, here, going to go into the details of the "how". Merely sketch the "what".
Remember: You don't need to do all of this just to publish something on the web. But if you want to do more, Oliver, then here are some possibilities.
To do any of these for the world in general, you will need a computer (or at least a router and Arduserver or IP camera) which is always on, and always connected to the internet. (You can also do the following things, but with use restricted to just people using computers connected to the same LAN ("local area network") as your servers are on.
If you want to serve simple, static webpages, there are packages out there on the internet to let you set yourself up to do that very painlessly. The packages for Windows go by the name WAMP, those for Linux are called LAMP. These packages are free, by the way.
By "simple, static webpage", I'm talking about pages of .html created by you. I prefer to create such pages with a simple text editor. (I like Textpad, but there are many good ones.) You can, if you prefer, use html generators as complex as you wish.
HTTP and HTML: The "H" in both stands for the same thing: Hypertext. HTTP stands for "HypertexT Transport Protocol"... a set of rules for moving hypertext around between machines by LAN or WAN. HTML stands for "HypertexT Markup Language". If I put...
Mary had a little lamb,
who's fleece was white as snow
.... into a web page, like that, "behind the scenes", that is what comes through, courtesy of HTTP.
However, to get....
Mary had a little lamb,
who's fleece was
black white as snow
... I need to put the following, "marked up" simple text into the webpage...
<p><b>Mary</b> had a <i>little</i> lamb,<br> who's fleece was <s>black</s> white as snow</p>
(That barely scratches the surface of all that you can do to mark up web-pages, but is a sufficient start for your understanding of "HTML".)
... sidebar ends
Returning to "WAMP" and "LAMP" packages: The "A" stands for "Apache", which is the software and files to set up a web server. The "M" is for MySQL... the AMP package gives you a MySQL server, too. Normally, I don't like "do everything" packages, but in this case, they are a good idea. If you do not (yet) want to provide a MySQL server, you can just turn that bit off. But someday you will, I would lay odds, want a MySQL server, and it is so much easier if you have installed an integrated system from the start. The same applies to the PHP server which is the explanation of the "P" part of WAMP and LAMP.
I must have forgotten something. That's all I want to say for the moment about the possibility of setting up a server for pages of .html written by you.
So! That's the basics of creating a traditional web server to supply pages of html to users.
DETAILS: How to set up WAMP or LAMP: I haven't tried installing up a LAMP package (yet!). When I've installed a WAMP package, I've used the one from WampServer.com. (By the way, although I generally recommend that you "bite the bullet", and go for a full WAMP/ LAMP ((Windows/Linux, Apache web server, Mysql database, PHP program language) server, you could, if that's where you were starting, install just a MySQL server. See below, for that.
A more "niche" server can be created by someone with the right skills. It too will return html. It is, in fact, also a web server... but a very limited one. It does "all" that a big PC could do, but with just a little microprocessor and an ethernet interface board. It would cost you about $40 to set one up. It is called an "Arduserver", as it is hosted in an Arduino.
Not a lot of people will want to actually make one... it only serves a very simple page... but it does offer something its "big brothers" don't: Not only can the client who visits an Arduserver see the temperature where the Arduserver is, but the client can cause something next to the Arduserver to be turned on or off. And yes, the Arduserver is a little invention of mine. Full details at Arduserver.com... cited here not because I think it will be your next project, but because just reading through the material there may help you consolidate your understanding of what clients and servers do in general.
An IP cam is a bit like a webcam... but it is a general resource, connected to a LAN, available to more than just a single PC.
I would suggest that if you are new to IP Cams, you set it up and look at the picture it is producing via a PC on the same LAN as the IP Cam. Getting that much working is the way to start, anyway. When you do have that much working, if you put some more things in place, you should also be able to see what the camera sees from anywhere on the internet. Of course, if you are not careful, anyone else may also be able to see what the camera sees. Not terribly important, probably, but it pays to consider whether it is important. What you have the camera trained on will probably have a bearing on the answer to that. Do, as Mr.Watson requested, Think?
An IP cam is, again, essentially a web server... even if it is serving something a little more exotic that pages of fixed text. It will also be normal for an IP cam to have one or more "pages" which it can serve to an ordinary browser, by means of which properly authorized users can alter the setting which determine how the IP cam operates. (The authorization process is also handled by the service the IP cam delivers: Users supply an ID and a password, and the IP cam grants access, acts on change requests, if the user/ password combination is one that the IP cam has been told to obey.
Here you will, if you think about it, spot a "chicken and egg" problem. It is overcome as follows....
When the IP cam is first delivered, or immediately after a user has caused a reset to factory defaults, the IP cam will communicate with the LAN by a route explained in the user guide, and it will accept a default admin user ID and password... often user "admin", password "admin". The first thing the sensible owner of an IP cam (and many other devices!) does is to connect to the device, and change the name of the admin user and the admin user's password. (And write down the values chosen for future reference!)
Not complex... but it only takes one little "gotcha" to make just one thing wrong, and it may seem as if your IP cam, or whatever, "doesn't work". And security is important... don't be too cavalier.
My mention of my FarWatch program is a bit of a cheek, actually.
While FarWatch does rely on a server to be useful... the server it needs is just an ordinary, WAMP provided, web server. FarWatch creates and keeps up to date a simple page of HTML which users look at to see how things are, when they "watch" someplace from "aFAR".
It is, if I do say so myself, a good product. And the one that got me into playing with servers in the first place. But it is not a "service" in it's own right.
I said that this page was about broad principles. And, in general, it is.
However, I am now going to talk about another part of setting up servers in rather more detail, because it fits well here, I think.
One bit of good news before I start: If you are only interested in connecting across a LAN to servers, then you don't need to read the material I am about to present about DDNS, dynamic DNS updating.
Before I try to tell you about dynamic DNS updating, I will start by explaining the DNS, the Domain Name System.
When you set out to read this page, probably either you (or Google, on your behalf, after a search) put...
...into your browser as the page you wanted to read... and then "the system" went off, fetched the page, and there it is on your screen.
But! "SheepdogGuides.." is almost useless to "the internet". I can explain that with a very close analogy drawn from using telephones.
While most of us now have "directories" built into our phones, we all(?) know that the phone system works on numbers, not names.
It isn't so widely known that the internet also works on numeric "addresses". From early in the life of the World Wide Web, a free (phone companies please take note), and largely invisible system has been in place, allowing us to use names rather than the numbers which underlie our access to internet resources. That system is the Domain Name System, DNS.
If you wanted to contact, say, the sales desk at Dell computers, the NAME wouldn't be much use, would it. You'd need the number. The same is true for "things on the net"... except that the system for getting you "the number" is automated, and you can ask for things "by name".
So, I hear you wondering, what has this got to do with me?
Just before I answer that, I must mention that there are two sorts of IP addresses... no, not the IP6 and IP4 addresses... that's another "two sorts" issue.
The devices in a local area network each have a local IP address... probably something like 192.168.0.140. Although it is not a widely used acronym, I am going to refer to local IP addresses as LIPAs.
Things "on the internet" have what I am going to callWAN IP Addresses, WIPAs, in brief. ("WAN"? Wide Area Network... "the internet"). Like LIPAs, they consist of four (well, traditionally, and for the moment four) numbers, each less than 256, separated by full stops... but a WIPA will never start 192.168.
That's what you need for now about LIPAs and WIPAs! I've tried to say that briefly in a separate page, which will open in a new window or tab, so you won't lose your plase here if you click the link. Stuff there may answer questions you still have.
In the just concluded section above, I spoke of you setting up a server or servers.
In a discussion elsewhere about that, I will show you that users of PCs (or other intelligent devices) on the same local area network (LAN) as your server can be given access to it via its LIPA.
For you server to be useable (and hopefully useful, but that's up to what you serve!), either your server's WIPA must be known to your public, or another way for people to get to it must be provided. (Your WIPA is likely to change quite frequently, and few users will BE users if you only give them a numeric address for the server. If your WIPA is "static", i.e. it doesn't change very often, if at all, they you would know about it, and you would be way past needing my help... assuming you pay for your own internet access.
But! Fear not! Help is available. Even a modest home user of the internet may use a DDNS service. With one of these, it doesn't matter in you do not have a "static ip address".
As the page you are reading is about general principles, I won't go too far here with the practicalities of using a DDNS service. I've written about it many times already elsewhere.... in a thoroughly scatterbrained and disorganized manner. I WILL TRY to get that material rationalized.
But... in broad terms: (Take a deep breath). Somewhere in your LAN... preferably in your router, if it offers the feature... something repeatedly... once every 60 seconds, perhaps?... checks to see what WIPA your connection to the internet is currently allocated. If it is the same as it was the last time your DDNS updater checked, then nothing further happens. If, however, the WIPA for "you" has changed, the DDNS updater sends a message to the DDNS service you are signed up with. They then "pass the word" to the people that matter, saying, "You know that (say) SheepdogGuides.com used to be at WIPA 220.127.116.11? Well, it isn't anymore. Now it is at..."
Thus, if anyone wants to connect to SheepdogGuides.com, "the system" (the DNS system, that is) will have the right number for the resource when the enquiry arises. Pretty neat... if a little convoluted!
So! That's DDNS out of the way. Almost anyone reading this essay who wants to do any of the things discussed here... beyond access merely within a LAN... will need to sort out setting up a DDNS service for the router by which their server connects to the internet. Hence the digression.
DETAILS: How to do DDNS In due course I hope to re-write it, and incorporate a rationalized version as part of this set of web-pages, but for now I offer you a "How To" on DDNS I wrote earlier in a different context.
Back to more general things...
You can send whole files, untouched, around your LAN or across the WAN (internet), as attachements to emails. Whole files can be sent back and forth using a web server and a browser.
We have already heard of FTP servers, in the section above about publishing web pages.
If you publish pages... like this one... they will be on an HTTP server somewhere. If that "somewhere" is a server managed for you, by a third party, you may well be communicating with that server via an FTP connection. But you will only need the "client" side of that relationship... simple. Mere readers of your pages will access them via HTTP, using a web browser. (Each page is contained in a file on the web server.) YOUR access to the same files will be via FTP. You will be using an FTP client program; with it you will be accessing the FTP server provided for these purposes by the same people who HOST your web pages. (If you are hosting your own web pages, i.e. providing the server, you can use FTP, but it will probably be just easier to use a more direct method.)
As I said, we've heard of FTP already. Now we are going to go into it more deeply...
You can drive a screw into a piece of wood with a hammer... but a screwdriver does a better job.
The "screwdriver" for sending files around is FTP. (Just to further confuse you, you can "do FTP"... if rather crudely... with Firefox. But I'm going to show you how to do it better.
Think for a moment about how you move and copy files around inside your machine. You do, I hope, from time to time use your operating system's basic file management tool? The tool that lets you rename a file, any file. Or make a copy of it in a different location. Or "move" it... which is just a "copy", followed by an automatic delete of the original file. In Windows, that would be Windows (not Internet) Explorer (or the Linux or Mac equivalents... or FreeCommander if Microsoft's latest bright ideas finally pushed you away from their schemes.)
Your operating system's basic file management tool will also allow you, (if you have sufficient authority), to create new folders (aka "directories"), and delete things.
Doing similar things across your LAN is quite easy as long has you have "shared" folders. "Authorities" (or "permissions" or "privileges", e.g. "read", "write", "delete" will become more significant as you get more "clever" in what you are trying to do.)
Across your LAN, you can still use Windows Explorer. You may even be able to do that across the internet, but I wouldn't want to "open up" the things which would have to be opened to make that possible.
The "answer" is to use FTP.
In the case of moving files with Windows Explorer, you didn't need anything "special" at either end... not at the "source" end, not at the "destination" end.
For FTP, you need a server at the source end, and a client at the destination end.
There are (at least) two well supported, mature, free, multi-platform tools available. I'm not an expert or anything, as Billy's dad said, but I use the Filezilla server and client.
You get both the client and the server from http://filezilla-project.org/
I hope you already have access to an FTP server somewhere? Perhaps you publish web pages, but use a third party hosting service?
Get the Filezilla FTP client working first. It is a bit like Windows Explorer
Sidebar: Ha! You have to admire their cheek! I went off looking for a public FTP server you could "point" your FTP client at.
What I found wasn't quite that. There was, when I looked, a very tidy, very "professional looking" site which was "kindly" offering to let you test your FTP server. If you would enter your server's IP address (it's WIPA, not just it's local address on your LAN), the user name, and the password, then the "nice people" at the site would tell you if the server could be accessed.
Ah... DUH! If you given them your log in details, then yes, your site probably can be accessed! But if you are that foolish, is there likely to be anything of value on your server??
What you want to look for, if you don't already have access to a professionally administered FTP server you can try to access with your newly installed FTP client software... you are NOT, yet, trying to see if your server (which you probably don't even have set up yet) can be accessed. You will test that yourself, in due course, with your own FTP client software.
..... end of sidebar.
Once your FTP client is up and running, then you are ready to install and set up your own FTP server, if only for your own use. Be a little careful about "opening the doors" on your LAN to the outside world... you may open the system further than was your intention.
You don't need to set up an FTP server to make files available to the outside world. Just store them where you store your web pages, and create links to them. "The system" will let your readers download the files. For example, you can download my arithmetic game just by clicking on that link. (That will put an .exe file on your hard drive. It isn't a "setup file" which will "do things" to your system when you run it. It is the whole game... for Windows only, I fear. Inspired by "Goldie", of Radleigh School, England.
The underlying HTML for that is merely...
...you can <a href="http://www.arunet.co.uk/tkboyd/tma36.exe" target="_blank">download my arithmetic game</a> just by clicking on that link...
But! Back to your own FTP server!....
I suggested that you start by getting an FTP client up and running on your system. Then you can move on to creating an FTP server.
With your client, you have to enter some information, e.g. the address of the server you want to access. Some will let "just anyone" in. Others require that you supply an user id and a password. These can be entered into your FTP client, and saved for re-use.
If you move on to installing a server, too, then you take on administrator chores. The server needs to be running whenever you want users, even if only yourself, to have access to the services it is there for. Quite separately, there is the question of administering the service. You, as the FTP server's administrator, will need to tell it what users can access it, what they can do when they access it, where they can go, etc, and you will tell the server the password for each user. (We are all so used to being able to change the password on our various web page accounts that I ought, perhaps, to mention that users of the Filezilla FTP server cannot change their own passwords. Password changes have to be done by the FTP server's admin(istrator)).
DETAILS: How to do FTP In due course I hope to write a page for you about setting up an FTP client on your computer, setting up an FTP server.
Although the "broad outline" (!) notes above are extensive, I'm pleased to tell you that setting up an FTP server is, of itself, no big deal. For access from "the outside world", you need to understand local and wide area IP addresses, router NAT settings, having a DDNS service running... but you need to understand those things for any of the server work we're discussing here. The "extra stuff" for FTP serving is not extensive. Setting up an FTP client is easier than setting up an email client! (Assuming you do your email via POP/SMPT, not merely by a web-based service.)
First catch (your understanding of) "database"
Before you're ready to "fight" with a MySQL server, you need to have some idea, at least, of using databases.
Now... you may think you know about databases. You may have a very clear idea about what a database "should" do for you. But be careful: Does MySQL know (or care) what you think it does?
Getting started with databases is quite unlike getting started with, say, a wordprocessor or even a spreadsheet. Both of those can be used, at least to some level of success, more or less intuitively.
Trying to do database work intuitively is about as likely to lead to success as trying to fly a jet fighter plane "intuitively".
But! Enough with the negative!
At a simple level, a database consists of a table with data in it. (But, did you realize? Often databases consist of several one tables.)
In the table, the columns are for things like "Telephone number", "Name", "Town they live in". These are called the fields of the database.
Each row consists of the information for, in the case we are developing, one person's information, e.g....
John Smith // 1-303-555-1212 // Denver
Each row is a "record"
Every table must have a field (designated the table's "primary key") holding a value which is unique... no two records can have the same value in their primary key field. A simple "serial number" is often used, although where possible... often... it is better to use something more meaningful.
I like the database which comes with Open Office... rather poorly "named" "Base". (Not the most useful keyword for a Google search!)
You can use that... to prodigious levels... without ever using a MySQL server. I have written pages which get about 5,000 visits per week about using Open Office's database Base.However, you can also use Base and MySQL together.
When you have a MySQL server, your table(s) reside "inside" the server. It is a bit like it was a "web server", serving up pages of html to a browser, the browser being the client. However, a database server exists to "serve up" bits of tables, or temporary tables assembled out of the bits of actual tables. (That last "thing" is a non-technical way of saying "return the results of a multi-table query"). In a database client/server situation, the client... the equivalent to the web page browser, e.g. Firefox, is the database front end you choose to use. Open Office's Base can be used as a front end for MySQL.
DETAILS: How to set up MySQL: I generally recommend that you "bite the bullet", and go for a full WAMP/ LAMP ((Windows/Linux, Apache web server, Mysql database, PHP program language) package. See above for that.
You could, if you prefer (and don't mind opening the door for hassles for the future.. though they "should" not arise...) install just a MySQL server. I used the setup package at dev.MySQL.com to do that, in February 2013, on a Windows XP box. There are alternate packages for Linux and Mac.
I have written a separate page with a guide to setting up MySQL servers for you.
While I don't intend to write supporting pages with details of how you might set up you own email servers, I will discuss the general principles, because thinking about them may help you in you other ventures.
In recent years, many people have moved away from SMTP/ POP email, 8to using web based services.
I'm not going to discuss web based services. I'm talking about "doing email" the old-fashioned way, e.g. with Outlook Express, or Pegasus, or other client programs which leave you with your emails on your own PC. You can look at them without being connected to the internet.
Did you know that when you "do email", (the old way or the new) you're actually using two separate servers? (More in the case of "fancy", "modern" email... the two the "oldies" use, plus at least one "extra" one to handle your requests to "do things".)
Let's start with your incoming email. Your email address points to something very like a post office box. Step 1: People put emails to you in it, by means which are just the complement of how you put emails in other people's email "boxes".
When you want to read those messages, you (probably) use a "POP client". It goes to your email "box", and fetches what's there for you. While many people have things set up "the easy way", you can work many variations on the themes.
The easy way is to just scoop up everything in the "box" whenever you visit, move everything to your PC, and then delete everything in the box.
It is possible to collect just the "headers" of the messages. Imagine a "real" post office box. I have one. When I collect my mail, I glance at what I can see on the envelope. Some pieces of mail get left in the box, to be collected later. Some things, on the basis of the outside alone ("the headers") get thrown out unread.
Doing email can be done like this, although with email you can take a copy of something in the box, but leave a copy in the box, too. A bit hard to do with "real" mail. Pegasus makes working this way easy. (Sadly, this is only available for Windows... but is free!)
When it comes time to send emails, you use something called an "SMTP client." It puts things in other people's "email boxes". Obvious, when you think about it, that sending and receiving are quite different activities?
"But!", I hear you cry, "I don't use two programs for doing email!" No, you don't. But there are two clients built into your email program... one for fetching stuff from you "post office box", and a second one for distributing things to other people's boxes.
The boxes are quite clever... it is relatively easy to put things into them... but to look at something in an "email box", and certainly to delete it from the box, you need higher permissions.
So! We've skated over the highlights of many different servers, and aspects of being a client or an administrator of them.
Getting a server running isn't as simple as plugging in a new USB mouse... but it is immensely rewarding.
The biggest problem for me is that to have a service up and running properly, you need to get many, many "bits" right. Often exactly right. One typo in one of the (several) passwords associated with a given undertaking will stop it working. And often, especially for the neophyte, it is hard to know where the problem lies. I will try in my essays on the practical issues of setting up the services I've discussed to present logical progressions, so that you can get the service up and running, and clients connect to it, with the minimum of anguish along the way.
I'm sorry that all of this is pretty skeletal and rough so far. Working on it, I promise!
Scattered around my websites, you will find many bits and pieces relating to working with servers. These are from The Bad Old Days when I was stumbling around, more or less in the dark.
I think I have a better grasp of "the big picture" now, and will be trying to rationalize all the old scrappy things.
Although THIS page doesn't really deserve it yet, I have put the following button in as part of the page building process. Have you heard of Flattr? Great new idea to make it easy for you to send small thank you$ to people who provide Good Stuff on the web. If you want to send $$erious thank yous, there are better ways, but for a small "tip" here and there, Flattr ticks a lot of boxes which no one else has found a way to do yet. Please at least check out my introduction to Flattr, if you haven't heard of it? "No obligation", as they say!
I dislike 'fancy' websites more concerned with a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Not everyone has fast broadband.
I present this material in a format aimed at to helping you USE it. There are two aspects to that: The way it is split up, and the way it is posted..
Please remember the material is copyright. (TK Boyd, 2006 and later) The procedures in the page just cited are suggested only for convenient personal use of the material, however, also....
Feel free to use this information in computer courses, etc, but a credit of the source, quoting the URL, would be appreciated. If you simply copy the pages to other web pages you will do your readers a disservice: Your copies won't stay current. Far better to link to the original pages, and then your readers will see up-to-date versions. For those who care- thank you. I have posted a page with more information on what copyright waivers I extend, and suggestions for those who wish to put this material on CDs, etc. (There is at least one prison using Sheepdog Software/ Sheepdog Guides material for inmate education. Situations do exist where good internet connections are not possible!)
Translations are welcomed. Tell me about yours, so I can post links to it. (More information at the page about copyright waivers.)
PLEASE >>> Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages <<< PLEASE
If you liked this tutorial, see my main webpage for more things from the same author.Editor's email address. Suggestions welcomed! - - - Want a site hosted, or email? I like 1&1's services.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes. There were two "unknown attributes" in Google+ button code. Sigh.
. . . . . P a g e . . . E n d s . . . . .