A web application, when in active use, is a large decentralized system. Thousands (and hopefully more) of participants, each with their own machine running a web browser, are generating events to -- and requesting resources from -- the web server portion of the web application.
It can become centralized if the web server controls who can access the web application. This doesn't have to happen; it is a decision (whether consciously or unconsciously made) by its designers.
Website or web application?
We begin by assuming that you have something to offer to the world. A series of questions can determine what kind of web presence you could provide.
Are you presenting information?
In this case, you can store static assets -- pages of information on your web server. These could be marked up with HTML with embedded images, but could also be simple text files, or PDF files. Their appearance and attractiveness is a different dimension than the one we are discussing here.
This assumes that every visitor to your website will see exactly the same thing for each of those pages.
You may wish to study your audience, and the web provides a lot of information that can let you do this, without knowing who they are exactly. By processing the web server logs, you can determine how many there are, where they come from, which pages they called for, how long they stay on your site, etc.
You may wish to put a visitor count on some of your pages, so that both you and your visitors can see how many are consuming your information. While this breaks the rule that "every visitor to your website will see the same thing," it can be done (without knowing who exactly they are) by placing a counter in the pages*.
Are you providing a web-based service?
In this case, your customer can bring their data to your website and you can perform the service. Again, you don't need to know exactly who your customers are**.
Do you need to know your customer?
So far we've been working our way towards more customary web applications, which know quite a bit about their customers, and in fact expect them to sign up for -- and then login to -- the website for each session.
Why would you want to know?
If you are a bank or credit union, you are required by law to know your customer (KYC), and you might not choose PicoStack as your implementation platform.
If you are participating in the surveillance economy, then you do need to know as much as possible about your customers to maximize your profits by sending them targeted advertisements***.
There is also a technical reason for knowing who is visiting your website. If you are holding data on their behalf, you need to know which block of data to associate with which visitor. Using PicoStack, the block of data would be maintained by a pico belonging to the particular visitor (in ways described in an earlier post).
How to maintain session data?
In a web application which represents persons, there would be one pico owned by each person. When a visitor is looking at the participant pico of another person, we may still need to know things about the logged-in visitor. This data would not be in the pico they are looking at, yet must be available somehow. This qualifies as session data.
A session pico
The obvious answer would be to put it into a session pico. It would be created as part of the login operation, and deleted when the visitor left the site or signed out (or after the passage of some time). We do not have experience with this solution. If you do, please let us know in the comments.
Browser cookies
The web server can send data about the logged-in visitor to the browser in such a way that the browser will keep it in cookies. This allows the browser to know the data about the logged-in visitor. And, the browser will send it to the web server with each request, so that a ruleset running in one person's pico can have access to that data about the logged-in person.
On the web server side, cookies can be queried in the manner shown in this code. And to update a cookie in the browser, the pico could use a rule like this one. A discussion of setting and reading cookies is provided in the Pico Labs documentation.
Notes
* One way of doing this is described in a series of posts (the latest of which is linked here) describing how this can be done in a very large website of this kind. This has been done using picos (currently only supported by version 0 of the pico engine).
** There are many websites like this on the web. To name three: base64decode.org, validator.w3.org, sequencediagram.org. The first of these funds its operation by showing ads; the others offer a public service at no charge. The last one is interesting because you can visit it multiple times for the same problem; you are responsible for holding on to the data, importing it each visit, and remembering to download it as you leave each session. It shows a popup warning that you have unsaved changes as you leave.
*** The author disapproves of this way of funding a website, and hopes that you would not bring PicoStack into that world. Ads which are not targeted, as mentioned above**, although annoying, are acceptable to the author.
No comments:
Post a Comment