Project Free HRD & Payroll Application
Moderator: Rathinagiri
- serge_girard
- Posts: 3161
- Joined: Sun Nov 25, 2012 2:44 pm
- DBs Used: 1 MySQL - MariaDB
2 DBF - Location: Belgium
- Contact:
Re: Project Free HRD & Payroll Application
Agil,
You have woken up a beast... !
S
You have woken up a beast... !
S
There's nothing you can do that can't be done...
- Agil Abdullah
- Posts: 204
- Joined: Mon Aug 25, 2014 11:57 am
- Location: Jakarta, Indonesia
- Contact:
Re: Project Free HRD & Payroll Application
<continue from previous>
If multiple clients are serviced, the server continually monitors for service requests. The server queues each request as it is received, ensuring all the clients receive the temperature data they request. The application queues each client and services it in a first-come-first-serve (First In First Out -- FIFO) manner. Once the queue is empty, the server continues to wait for new clients. The monitoring process is best broken into two components. One component detects the requests and queues up each client. The second component processes each queued client and performs the task requested one at a time. In this case, the server returns the temperature.
Processing clients one-at-at-time may be suitable for a simple temperature monitoring application. Simultaneously servicing clients is important for more complicated requests that can take a longer time, or if you expect a large number of clients. However, client requests still need to be queued however you design the component that processes the actual request. Servicing each client in different and independent threads or processes can accomplish this.
Some applications require that you give different clients different priorities. A temperature monitoring system can have passive clients, which display the temperature at any given time, and active clients that query the temperature and process it as part of a larger application. You may need to prioritize the active clients over the passive clients. To do this the server must have a method to identify, differentiate, and authenticate the clients requesting service.
To be serviced effectively, the client program must work with the interface or protocol defined by the server. The client program for each of the application architectures described is very similar. In each case the client program must send a temperature request message and must understand the reply from the server. In the case of a server servicing a single remote client or a server servicing multiple clients in a FIFO manner, the client programs have no noticeable difference in architecture. However, a client program interacting with a server that prioritizes different clients has a request mechanism that includes parameters for identification and authentication. This could be as simple as adding two parameters to the temperature request message for an ID and a password that the server can verify.
The server defines the interface for communication between the client and server programs. A well designed interface only exposes how to send messages, what messages are supported, and what the response to each message is to the client. The server is also developed in a modular fashion, separating the message handling mechanism from the functional component processing the request itself. Therefore, you can update the functional component of the server without affecting any clients. This modular approach to a client-server application provides a distributed application for remote temperature monitoring that you can maintain and update without affecting each client and server component.
Finish.
My comment:
I guess that Serge, Rathinagiri, Mustafa, Roberto Lopez are principally agree with the article. That's we are heading for by revising source-progs of Manpower, little by little with their help to implement it with HMG.
Regards
If multiple clients are serviced, the server continually monitors for service requests. The server queues each request as it is received, ensuring all the clients receive the temperature data they request. The application queues each client and services it in a first-come-first-serve (First In First Out -- FIFO) manner. Once the queue is empty, the server continues to wait for new clients. The monitoring process is best broken into two components. One component detects the requests and queues up each client. The second component processes each queued client and performs the task requested one at a time. In this case, the server returns the temperature.
Processing clients one-at-at-time may be suitable for a simple temperature monitoring application. Simultaneously servicing clients is important for more complicated requests that can take a longer time, or if you expect a large number of clients. However, client requests still need to be queued however you design the component that processes the actual request. Servicing each client in different and independent threads or processes can accomplish this.
Some applications require that you give different clients different priorities. A temperature monitoring system can have passive clients, which display the temperature at any given time, and active clients that query the temperature and process it as part of a larger application. You may need to prioritize the active clients over the passive clients. To do this the server must have a method to identify, differentiate, and authenticate the clients requesting service.
To be serviced effectively, the client program must work with the interface or protocol defined by the server. The client program for each of the application architectures described is very similar. In each case the client program must send a temperature request message and must understand the reply from the server. In the case of a server servicing a single remote client or a server servicing multiple clients in a FIFO manner, the client programs have no noticeable difference in architecture. However, a client program interacting with a server that prioritizes different clients has a request mechanism that includes parameters for identification and authentication. This could be as simple as adding two parameters to the temperature request message for an ID and a password that the server can verify.
The server defines the interface for communication between the client and server programs. A well designed interface only exposes how to send messages, what messages are supported, and what the response to each message is to the client. The server is also developed in a modular fashion, separating the message handling mechanism from the functional component processing the request itself. Therefore, you can update the functional component of the server without affecting any clients. This modular approach to a client-server application provides a distributed application for remote temperature monitoring that you can maintain and update without affecting each client and server component.
Finish.
My comment:
I guess that Serge, Rathinagiri, Mustafa, Roberto Lopez are principally agree with the article. That's we are heading for by revising source-progs of Manpower, little by little with their help to implement it with HMG.
Regards
Agil Abdullah Albatati (just call me Agil)
Programmer Never Surrender
Programmer Never Surrender
- Agil Abdullah
- Posts: 204
- Joined: Mon Aug 25, 2014 11:57 am
- Location: Jakarta, Indonesia
- Contact:
Re: Project Free HRD & Payroll Application
While working hard to revise source-progs to meet higher standard,
let's be relaxed.
Nothing wrong to include Bos Taurus Library to do exercises with drawing & images beside rigid numbers on Payroll.
let's be relaxed.
Nothing wrong to include Bos Taurus Library to do exercises with drawing & images beside rigid numbers on Payroll.
- Attachments
-
- Hmgpower.png (796.98 KiB) Viewed 5815 times
Agil Abdullah Albatati (just call me Agil)
Programmer Never Surrender
Programmer Never Surrender
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: Project Free HRD & Payroll Application
+1serge_girard wrote:Agil,
You have woken up a beast... !
S
A monster never surrender
Viva INTERNATIONAL HMG
- serge_girard
- Posts: 3161
- Joined: Sun Nov 25, 2012 2:44 pm
- DBs Used: 1 MySQL - MariaDB
2 DBF - Location: Belgium
- Contact:
Re: Project Free HRD & Payroll Application
Yes, and remember Dr. Frankenstein....
S
S
There's nothing you can do that can't be done...
- Agil Abdullah
- Posts: 204
- Joined: Mon Aug 25, 2014 11:57 am
- Location: Jakarta, Indonesia
- Contact:
Re: Project Free HRD & Payroll Application
Relax... I would say something in my mind about movie: "The Beast And The Beatiful"Serge wrote:
You have woken up a beast... !
S
Relax.... One more thing about movie: "I know What You Did Last Summer"Esgici wrote:
+1
A monster never surrender
Many-many thanks for your attention.
Agil Abdullah Albatati (just call me Agil)
Programmer Never Surrender
Programmer Never Surrender
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Project Free HRD & Payroll Application
At first, there is NETIO samples in HMG and Harbour distributions, that you can check.
NETIO is very simple
Minimal example:
In client application:
Server app (console, multi-threaded in this sample):
Of course, in real world, you will not return an entire table. You should send to server, an expression to select desired records to return.
This scheme is EXTREMELY FAST over the internet.
This is very reliable too, since the server app and the dbf files are in the same PC (The server). So, from the server app POV, all the files are local.
I'm using this scheme without any problem for the last years.
The best way to get server app built, is to download Harbour binaries and work from NETIO samples folder. It will built ok there.
NETIO is very simple
Minimal example:
In client application:
Code: Select all
cNetServer := '127.0.0.1' // local server or any addres (even Internet)
nNetPort := 65000 // you can choose any you want
cNetPass := 'secret' // Idem
lConnect := netio_connect( cNetServer , nNetPort ,, cNetPass, 9 )
IF .Not. lConnect
MSGSTOP('NETIO Connect Error!')
RETURN
ENDIF
aQuery := netio_funcexec( "remote_query" )
netio_disconnect( cNetServer , nNetPort )
FOR I := 1 TO LEN (aQuery)
Form.Grid.Additem(aQuery[i])
NEXT I
Code: Select all
proc main()
local pSockSrv , nPort , cIfAddr, cRootDir, lRPC, cPasswd, nCompressionLevel, nStrategy
cls
nPort := 65000 // or anyone you like
cIfAddr := '0.0.0.0'
cRootDir := '.'
lRPC := .T.
cPasswd := 'secret'
nCompressionLevel := 9
nStrategy := NIL
pSockSrv := NETIO_MTSERVER( nPort , cIfAddr , cRootDir , lRPC , cPasswd , nCompressionLevel , nStrategy )
if empty( pSockSrv )
? "Can't startl server !!!"
wait "Press any key to exit..."
quit
endif
? 'NETIO Server Started!'
hb_idleSleep( 0.1 )
DO WHILE .T.
INKEY(0)
IF LASTKEY() == 27 // Esc
? 'Stopping...'
netio_serverstop( pSockSrv, .t. )
EXIT
ELSE
LOOP
ENDIF
ENDDO
CLS
ALERT('SERVER STOPPED!')
return
*************************************************************************************************
Function remote_query()
Local aRecordset := {}
use test shared
do while .not. eof()
aadd( aRecordset , { field01 , field02 , field03 ] )
skip
enddo
use
return aRecordset
************************************************************************************************
This scheme is EXTREMELY FAST over the internet.
This is very reliable too, since the server app and the dbf files are in the same PC (The server). So, from the server app POV, all the files are local.
I'm using this scheme without any problem for the last years.
The best way to get server app built, is to download Harbour binaries and work from NETIO samples folder. It will built ok there.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- serge_girard
- Posts: 3161
- Joined: Sun Nov 25, 2012 2:44 pm
- DBs Used: 1 MySQL - MariaDB
2 DBF - Location: Belgium
- Contact:
Re: Project Free HRD & Payroll Application
Thanks Roberto!
Serge
Serge
There's nothing you can do that can't be done...
Re: Project Free HRD & Payroll Application
Hola Roberto:
Tal como lo haz explicado es realmente muy sencillo el uso de NetIO.
Mis dudas están por el lado de la aplicación del servidor, en el ejemplo que haz descrito no utilizas el hbnetio.exe que viene con la distribución de harbour, en su lugar haz creado tu propia aplicación servidora.
¿Qué ventajas y/o desventajas implica el uso del servidor que viene con la distribución de harbour?
[Google]
Hi Roberto:
As explained beam is actually very simple to use netio.
My doubts are on the side of the server application, in the example you've described does not use the hbnetio.exe that comes with the distribution of harbour, in the beam spot created your own application server.
What advantages and / or disadvantages associated with using the server that comes with the distribution of harbor?
TIA
BestRegards
GVS
Tal como lo haz explicado es realmente muy sencillo el uso de NetIO.
Mis dudas están por el lado de la aplicación del servidor, en el ejemplo que haz descrito no utilizas el hbnetio.exe que viene con la distribución de harbour, en su lugar haz creado tu propia aplicación servidora.
¿Qué ventajas y/o desventajas implica el uso del servidor que viene con la distribución de harbour?
[Google]
Hi Roberto:
As explained beam is actually very simple to use netio.
My doubts are on the side of the server application, in the example you've described does not use the hbnetio.exe that comes with the distribution of harbour, in the beam spot created your own application server.
What advantages and / or disadvantages associated with using the server that comes with the distribution of harbor?
TIA
BestRegards
GVS
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Project Free HRD & Payroll Application
I've not tested NETIO server included with Harbour, but I'm sure that it is ok.gvaronas wrote:Hola Roberto:
Tal como lo haz explicado es realmente muy sencillo el uso de NetIO.
Mis dudas están por el lado de la aplicación del servidor, en el ejemplo que haz descrito no utilizas el hbnetio.exe que viene con la distribución de harbour, en su lugar haz creado tu propia aplicación servidora.
¿Qué ventajas y/o desventajas implica el uso del servidor que viene con la distribución de harbour?
[Google]
Hi Roberto:
As explained beam is actually very simple to use netio.
My doubts are on the side of the server application, in the example you've described does not use the hbnetio.exe that comes with the distribution of harbour, in the beam spot created your own application server.
What advantages and / or disadvantages associated with using the server that comes with the distribution of harbor?
TIA
BestRegards
GVS
Simply, I like to have more control over things, so, I've preferred to create my own server, to add to it a customized logs, interface, etc.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)