|
WhoPinchedMyName wrote: Q: who knows even less than who?
They have a term definition problem. And both failed to recognize that.
Definition of a TCP Push.
1. There are two actors: server and client. These do NOT define implementation but rather how each behaves.
2. A 'server' is waiting for a connection.
3. A 'client' opens a TCP connection. This is exact step defines the push. The one that opens it is the only one that can be defined as doing the push.
4. The 'client' sends a message to the 'server'.
What if the 'server' sends a message to the 'client'. Doesn't matter. It can't do that until the 'client' opens the connection.
A browser, in general, uses HTTP which is built on TCP. So HTTP in any discussion is irrelevant.
A browser, as used by the vast majority of the public, does not have a public IP.
A browser, the common ones do not act as server because of that (at least for this discussion.) It would be pointless because without a public IP nothing on the 'internet' could do step #3 in the above list.
------------------------------------------------
Web designers use API/libraries which use terminology that uses the term 'push' which has nothing to do with the above.
That sort of push does require that the browser acts as a client (see list above).
Terminology does not change that the 'client' (browser) must first open the connection.
An easy example of this is when a user asks for a report that takes a long time to run. They might sit there refreshing the page waiting seconds, minutes or hours for it to show up. Or the web designer might make the page refresh on its own. Thus at some point the user knows that the report is ready.
But if the browser is closed there is no way for the report service to 'push' a notification that the report is done to the browser.
|
|
|
|
|
OK... but isn't that more or less what Wombat is saying? The only one that can open a connection is the user's browser - they are the client - and the server can only "push" a notification to them once they (the client) have opened a conection.
What's puzzling Muppet then is, if this is the case, how it is called a "push" - it's just a case of the client polling the server until the server says "OK, now I have new message for you" and returning it - that's not really any different from a client pull, and can be done with a standard JavaScript setInteraval function and AJAX call... (and when a user subscribes, set a persistent cookie that tells the page to initiates this every time it is opened).
|
|
|
|
|
WhoPinchedMyName wrote: OK... but isn't that more or less what Wombat is saying? The only one that can open a connection is the user's browser - they are the client - and the server can only "push" a notification to them once they (the client) have opened a conection.
That does not contradict what I said.
That is a redefinition of what the term traditionally means. So they must define the term before they can agree on what is happening.
WhoPinchedMyName wrote: it's just a case of the client polling the server until the server says "OK
I wasn't going to read all of that but once a connection is established either side can send a request. So it is not necessary for the 'client' (my definition) to poll. However perhaps using their definition, not mine, they are redefining the term completely to suggest that the client (browser) poll is resulting in a push. That however is quite a stretch it terms not only of the original definition but even in what the meaning of 'push' is in the English language.
|
|
|
|
|
I don't undersatand your definition of client and server. In web terms, a client is traditionally thought of as the end-user (or their browser), and a server is what sends them pages/data/whatever upon request.
A server can only know if a client is still connected if it receives something from the client. So a so-called "push notification" (from ther server to client) can only happen if the server has had such a "something" establishing (or keeping alive) a connection - that "something" telling it where to push the notification to.
SO how does this differ from the client using a simple AJAX call on a setTimeout to ask the server if it has anything new it wants to say? As far as I can make out, the only difference is that it can run as some kind of background service - well, whooppee, I can do without that. Seems a whole lot of effort for little benefit, though I guess someone likes it. It certiany seems to be popular (amongst web devs anyway; not so sure about end users.)
|
|
|
|
|
WhoPinchedMyName wrote: I don't undersatand your definition of client and server
My first response defined those specifically.
2. A 'server' is waiting for a connection.
3. A 'client' opens a TCP connection. This is exact step defines the push. The one that opens it is the only one that can be defined as doing the push.
Too much detail for this but TCP is a protocol that defines communication and establishing the connection in the first place requires a 'client' and a 'server'. Using specifically and only the definitions above.
Do not confuse those with what you might think of when using a browser and what it connects to (certainly related and it does use the protocol but it definitely uses layers on top of those.)
WhoPinchedMyName wrote: a client is traditionally thought of as the end-user (or their browser), and a server is what sends them pages/data/whatever upon request.
That is either phrased badly or is wrong.
The traditional browser server idiom is that the browser requests (a specific type of message/data) and the server responds (a specific type of message/data) to that request.
In terms of TCP (not HTTP) the server does in fact 'send' the response based on what the client (browser) 'sent' the request.
WhoPinchedMyName wrote: So a so-called "push notification" (from ther server to client) can only happen if the server has had such a "something" establishing (or keeping alive) a connection - that "something" telling it where to push the notification to
I can't even suggest that is phrased incorrectly. It is just wrong.
There is no communication without an open socket. None. Nothing can be sent in any way from any side unless the connection already exists.
There are two parts to the socket/connection
1. Open the socket
2. Use the socket.
Messages and communication from either side only happens with #2.
WhoPinchedMyName wrote: SO how does this differ from the client using a simple AJAX call on a setTimeout to
Now you are confusing how libraries and protocols that live on TOP of TCP work. And perhaps because their documentation is confusing and the documentation is overloading terms for their own reasons.
It does not matter what those 'claim' to do. They must all follow the rules of TCP because otherwise there absolutely no communication no matter what they do or how they claim to do it.
WhoPinchedMyName wrote: that it can run as some kind of background service - well, whooppee
In terms of the entire modern architecture from the browser all the way to the backend servers (multiple ones) and persisted data stores and third party services...yes background servicing is essential (technically threading processing.)
Might not be something you care about now. Might not even matter to you ever depending on where your focus lies.
|
|
|
|
|
I have the following code:
<div style="width:100%;height:100px;clear:left;background-color:#aaddee;border-style: solid;border-width: 1px;float:left;">
<div style="width:100px;height:100%;background-color:#ffeaae;border-style: solid;border-width:3px;text-align: center;vertical-align:middle;">
Tuesday
2023-03-15
</div>
</div>
Why this code doesn't center the text at middle on vertical direction ?
modified 16-Mar-23 8:44am.
|
|
|
|
|
The parent div would include several divs, where the text will be aligned separately.
|
|
|
|
|
I have tried:
<div style="width:100%;height:100px;border: 1px dashed #4b2869;clear:left;">
<div style="width:100%;height:100%;display:table;">
<div style="width:100px;height:100%;border: 2px dashed #4f2869;vertical-align:middle;text-align:center">
Tuesday
2023-03-15
</div>
</div>
</div>
No work.
|
|
|
|
|
|
Yes, I know, but the trick is that the second div has no vertical correct alignment, and I don't realise why:
<pre><!DOCTYPE html>
<html>
<head>
<title>Horizontal and Vertical alignment</title>
<style>
.container {
height: 200px;
width: 400px;
border: 2px dashed #4b2869;
display: table-cell;
text-align: center;
vertical-align: middle;
position: relative;
}
.container1 {
height: 200px;
width: 400px;
border: 2px dashed #4b2869;
display: table-cell;
text-align: center;
vertical-align: bottom;
position: absolute;
}
</style>
</head>
<body style="background-color:#646464;">
<div class="container">container</div>
<div class="container1">container1</div>
</body>
</html>
|
|
|
|
|
Sorry, I have tried a number of different styles and combinations but cannot get it to do what you want. But as I mentioned, I am not a CSS expert.
|
|
|
|
|
Thank you Richard a lot. As you see, the vertical alignment of the second div is not correct, and I don't know why, I am not a web developer at all.
|
|
|
|
|
I'm afraid I only dabble so my knowledge is limited. You might try opening the same question in QA to see if it gets a better response.
|
|
|
|
|
Just a heads up, floats are not needed here at all. Anyway, the vertical align property is for inline containers. A div by default is a block level element so it's ignored. To see what I mean check out the examples on MDN and W3Schools.
With that being said, there are much, much better ways to do this. If you want to vertically center without having to use explicit heights, the recommended way these days is to just use flexbox. There are a ton of other techniques like negative margins, line height, etc. too but flexbox should be something to master anyway. So, no time like the present.
<div style="width:100%;height:100px;background-color:#aaddee;border-style:solid;border-width:1px;display:flex;align-items:center;justify-content:center;">
<div style="background-color:#ffeaae;border-style:solid;border-width:3px;">
Tuesday 2023-03-20
</div>
</div>
Be aware that inline styles should be avoided. Only using them here to match your example.
Jeremy Falcon
|
|
|
|
|
It works now, thanks a lot !
|
|
|
|
|
You're very welcome.
Jeremy Falcon
|
|
|
|
|
Hi,
It is my intention to build a site shop for a photographer but I have no idea which would be the next appropriate language to focus on learning to get the job done out of Javascript or PHP.
What with other work commitments, I don't have the time to learn enough of both languages before the intended date of the site going live at the beginning of December.
I'm hoping that if I give you an outline of the kind of functionality I want you will be able to point me in the appropriate direction:
The photographer in question has a vast number of images they wish to sell as singles, or in sets of three for a reduced price in comparison to buying singles.
The images will be displayed in categories, each of which has the potential to run into a number of pages.
Customers are to be free to choose any image from any page of any category to make up their purchases.
I don't currently want to build a login and members capacity so that session data (the selections made) can be stored and come back to at a later date.
For now I want to be be able to allow customers to, on a single session basis, select as many images as they wish and then preview their selection prior to adding their final choice/s to a basket ready to check out.
I also want to be able to ensure that if there is a session in which a customer previews their choice, sees they have eight images selected, for example, and want to choose one more - in order to benefit from the set of three price, that they can go back to continue shopping without loosing the selections they had made prior to going to the preview page.
In terms of the shopping basket I cam across a paypal specific script that can be incorporated into html without the need to therefore build a php and mysql basket into the site.
I anticipate that I will have to use radio buttons or check boxes for customers to be able to make their selections prior to previewing them. But is it possible, or feasible for a form to span all the category pages and their sub pages?
Thanks in anticipation of you consideration and response
|
|
|
|
|
Member 15952980 wrote: to get the job done out of Javascript or PHP.
You probably need both: PHP runs in the server to do the backend work, while Javascript runs in the browser to manage the actual presentation (and data capture, etc.) of the web page.
You might be better looking into something like Wordpress which has many templates that you can adapt to your own needs.
|
|
|
|
|
Thankyou Richard.
Reguarding using Wordpress, I'm confident with HTML and CSS and was hoping to hand code the whole site to avoid generating lots of code I don't understand, and therefore wouldn't be able to debug more easily.
Are you familiar with Wordpress? (I've never used it but know it is avaialable as part of the hosting package I purchased for a HTML site I built)
If so do you envisage it being buggy within the context of the functionality I want?
|
|
|
|
|
Member 15952980 wrote: If so do you envisage it being buggy within the context of the functionality I want?
I have not used Wordpress myself, but I know it is in wide use. As to whether it would be buggy, there is only one way to answer such a question.
|
|
|
|
|
Fair point. It may well be my best bet for now given the timeframe I have to work to.
|
|
|
|
|
Given the choice between JavaScript and PHP, master JavsScript and also use Node for the backend work. It'll take you further these days.
Jeremy Falcon
|
|
|
|
|
Thanks for insight. I've never heard of Node before and just read a basic introduction about what it can do on W3 schools... I notice that Node work in partnership with mysql as php does. Mysql is my intended progression after php or Node.js
So does using Node mean you can skip learing php altogether?
Also, considering it is javascript based, are the server side scripts run entirely on the server as with php? Or are there client and server security concerns that put using it at disadvantage compared to using an entirely server side language such as php?
|
|
|
|
|
Member 15952980 wrote: So does using Node mean you can skip learing php altogether?
Yes
Member 15952980 wrote: Also, considering it is javascript based, are the server side scripts run entirely on the server as with php?
Yes. One of the main advantages to Node too, is that you can have what's called an isomorphic application. Which is a fancy of way of saying you can run the same code on both the client and server. Stuff that accesses the DOM will be client only, but for algorithmic type routines it's the same code.
Member 15952980 wrote: Or are there client and server security concerns that put using it at disadvantage compared to using an entirely server side language such as php?
No security concerns that PHP wouldn't also suffer. The main considerations are performance and available libraries. Google has put a lot of work into V8 (the JS engine Node is built on), so it's not nearly as slow as people would think. PHP can pre-compile into bytecode to speed up parsing prior to execution, but V8 also JITs in real time to native code in memory. Don't get me wrong, V8 will never be as fast as C/C++ or Rust and it's single threaded. But when compared to things like PHP, it does pretty well.
PHP vs Node js - Which programs are fastest?
PHP has a ton of built in functionality, like say for editing PDF files. Node doesn't. Fortunately, the community is huge for Node so finding a package to do most stuff is rarely a problem. In fact, it's so huge the real problem will be knowing which packages to avoid.
I say this as a dude who used to love PHP. I'll always have a fond soft spot for it, but times change.
Jeremy Falcon
|
|
|
|
|
Thank you very much Jeremy for taking the time to answer my questions and concerns.
I did do a course on PHP years ago, just before the laucnch of Node.js, and figured it would be easiest to just go back to learning that from scratch. But as you say times change.
You mention that PHP has a ton of functionality that Node doesn't.... My limited knowledge of php did leave me wanting to go forwards with certain capabilities. In a personal capacity I would like to build a music database. Would I be able to use Node, in conjuntion with mysql to:
- make directories (to, for example, store uploaded mp3 files)
- make pages (to, for example, print html code to make a html document)
Thanks in advance for your consideration
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
