Newsgroup: it.comp.programmare
Titolo: Da Web a Visuale

In azienda le applicazioni accessibili da tutti i dipendenti (circa 8000)
sono sempre (anche da me) state sviluppate su piattaforma intranet.
Una di queste applicazioni comincia a diventare un po' complessa per la
piattaforma utilizzata. Ritengo che non si possono fare tante cose che
invece vorrei fare solo perche' il web non lo permette.
A questo punto ho pensato, visto che se ne vale la pena nessuno me lo vieta,
di convertire il tutto in ambiente visuale (Visual C++). Il discorso pero'
e' che non ho mai sviluppato un applicazione visuale accessibile da tanti
utenti. Secondo me fatto il pacchetto... bisognerebbe fare circa 8000
installazioni su tutti i client. Qualcuno pero' mi ha detto che ci sono modi
che permettono di creare una sola versione dell'applicativo a far puntare
tutti allo stesso eseguibile.
Oggi il vantaggio del web e' che se io faccio una modifica al tool... tutti
lo troveranno aggiornato sul loro browser senza dover fare niente. E'
possibile fare la stessa cosa con Visual C++? E sarebbe comunque semplice
per un utente finale accedere alla mia applicazione cosi' come digitare un
indirizzo internet?
La cosa sarebbe davvero comoda... sempre se indolore (a parte la stesura del
codice!!)
Attendo e ringrazio tutti.

 codice!!)
Scusami su che base sviluppate al momento il vostro codice? Cosa ne pensi 
magari di sviluppare il tutto in ambiente CGI con il C++?
--
Edgar Laudito                 21TORR AGENCY gmbh
e.la...@21torr.com
          Engineering
tel: 
+49-7121-348-222
         Heinestrasse 72
fax: 
+49-7121-348-259
         D-72762 Reutlingen

 magari di sviluppare il tutto in ambiente CGI con il C++?
I CGI sono molto lenti...magari con delle ISAPI...o delle servlet JAVA...
Ciao
        Riccardo

 ha scritto


I CGI in C++ sono veloci, piu' dei servlet JAVA.
Forse ti stai confondendo con i CGI in Perl (che sono sempre veloci,ma...)
quello che e' lento e' avviare tutte le volte l'interprete Perl. Se il
processo dura poco e' tempo buttato via, se dura molto e' ben investito. Per
evitare questo problema esistono parecchie soluzioni. Ad esempio su Apache
per il Perl esistono FastCGI, mod_perl etc... Questi fanno si che
l'interprette perl sia sempre attivo e pronto. Per eseguibili veri e proprio
compilati (C++) questo problema non si pone nemmeno.
Alex

Il problema e' un altro!
Non ho mai esposto problemi di velocita'...
Personalmente sviluppo in ASP ma molte persone sviluppano ISAPI Server
Extension... ed e' cio' che dovrei fare anche io molto presto.
Il discorso e' che ci sono dei limiti relativi al web che volevo superare.
Se ho una pagina web avanti agli occhi... qualcuno dall'altra parte modifica
i record di un database... io vedro' la modifica slo quando faro' un refresh
della pagina. Una vera e propria applicazione forse mi farebbe scavalcare il
problema. Ed ho fatto il primo esempio che mi veniva in mente...
Che ne dite?
Cio' che mi preoccupa e' solo la distribuzione...
Attendo... ringrazio e saluto.
Alex <nom...@bow.wow> wrote in message
bfTf7.10351$i9.4...@news.infostrada.it...


problema. 
No, perche' il problema e' a monte. Quell'altra modifica ai records NON
DEVE ESSERE PERMESSA. Dopo che un utente ha chiesto un check-in per una
serie di dati, quei dati devono essere inaccessibili in scrittura salvo
check-out o "morte" della sessione.
Leonardo
-- 
".signature": bad command or file name

 compilati (C++) questo problema non si pone nemmeno.
Non ho specificato che parlavo di sistemi Windows...forse i CGI in C++
saranno più veloci dei servlet...ma non sicuramente delle ISAPI...
Ciao
        Riccardo

 saranno più veloci dei servlet...ma non sicuramente delle ISAPI...
Apache esiste anche per windows infatti, ho preso apache ad esempio proprio
per essere "portabile" !!! (il mio discorso rimane quindi valido)
Riguardo alle ISAPI, si, hai ragione, queste sono piu' performanti dei CGI !
Alex

Io credo che l'applicazione che hanno sviluppato sia già un qualche tipo di
scripting.
Il problema credo sia nell'interfaccia WEB che non è più adatta alle tue
esigenze.
Per il pacchetto visuale, puoi fare benissimo una installazione sul server o
su un computer apposito e poi
mandare tutti i client a caricare quell'applicazione da una cartella
condivisa.
Tutti i dll devono essere nella cartella programma.
Nello sviluppo del software inoltre dovresti evitare di salvare un qualche
tipo di dato in locale sui pc-
L'ideale sarebbe fare riferimento per tutte le operazioni ad un percorso di
rete ben definito tramite URI.
Se utilizzi un DB, ti conviene utilizzare un DB SQL.
Io l'ho fatto. Poi per ogni aggiornamento devi agiornare solo
l'installazione condivisa.
Una pecca di questo tipo di approccio è che la tua rete deve reggere il
carico di traffico generato dallo startup di 8000 processi.
In pratica se iniziate tutti a lavorare alle 9:00, e la tua applicazione
pesa 1MB di più qualche DLL.
8000 accessi al server per lo startup dell'applicazione generano 8GB di
traffico.
Con una FastEthernet ci vogliono (8000/(100/8))/60=10.8 da 10 a 20 minuti
prima che tutti i PC siano operativi.
Oppure potresti utilizzare i cab.
Mi spiego. Prepari la tua applicazione e prepari una installazione tramite
CAB.
Nell'installazione assegni un tipo di file alla tua applicazione poi sempre
dall'installazione inserisci un link ad una pagina Web sul tuo server.
Fatta la prima installazione, il programma dovrà essere sempre avviato dal
link alla pagina Web. IE controllerà se ci sono aggiornamenti, in caso
contrario eseguirà la copia del software installata in precedenza. In questo
modo tutti hanno sempre la copia del software aggiornata in locale,
che viene autoaggiornata ad ogni avvio.
Eviti gli 8G di traffico quotidiani per lo startup, che verranno comunque
generati al momento dell'aggiornamento del software.
Buona fortuna-

Riccardo Pellegrini wrote:

perche' sono lenti? C'e' qualche ragione intrinseca nella natura del 
protocolli CGI che lo rende lento?
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 Riguardo alle ISAPI, si, hai ragione, queste sono piu' performanti dei CGI
cosa sono le ISAPI?
Ciao Anto


 wrote in message
81k0otcdvq9kfoq3u...@4ax.com...


 un'applicazione NON Web... tutti d'accordo?
   Non necessariamente. Posto che anche l'applicazione piu` "visuale" 
del mondo rimane comunque in /poll/ sul database per conoscerne le 
variazioni, e` possibile forzare il /refresh/ periodico della pagina 
Html, per esempio mediante JavaScript:
<code>
	setTimeout("history.go(0);",refresh_period);
</code>
   Un'altra alternativa, ultimamente molto /a/ /la/ /page/ in ambiente 
Intranet, e` l'utilizzo di applet Java.
--
Alla prossima,
Marco

Cio' che mi preoccupa e' solo la distribuzione...
mi verrebbe da consigliarti delle applet Java collegate ad
un'applicazione (server di controllo) sul server;
in questo modo non hai problemi di gestione degli aggiornamenti,
di sicurezza (Java e' abbastanza fornito di classi), di modularita',
di interfacciamento con database, di sincronizzazione dei dati, di
portabilita'... solo di lentezza (forse), ma se c'e' un DB di mezzo...
e di compatibilità con i vecchi metodi, ma comunque non ti sarebbe
vietato l'uso di servlet, e pure ASP o ISAPI, se proprio si vuole fare
il papocchio.
Teòria
-- 
(unprotect to reply by mail)
2001 Odissea al cimitero: Win98 nelle tombe
...ma dove andremo a finire
(sulla mia almeno metteteci Linux ;))

un'applicazione NON Web... tutti d'accordo?
Si', sono d'accordo che sia risolvibile con una app NON web.
Non sono d'accordo, che NON sia risolvibile con una app web.
Anche perche' il problema e' di data flow e NON di protocollo. Una app "non
web" si limita a fare un polling a grandine o usa dei triggers. E nel primo
caso non e' diverso da <META HTTP-EQUIV="REFRESH" CONTENT="5;URL=...">, nel
secondo caso e' _de facto_ la soluzione che ho adottato io :-)


Assolutamnte no!
Contrario alle applet Java!
Lentissime.
Teoria <teo...@katamail.c-ond-om> wrote in message
48t3b82ca...@teoria.libero.it...


 wrote in message
hcp5otsm6hiec9810...@4ax.com...


Lentissime.
:)
Beh allora ti svelo che per me il C++ e' il top,
che sia visuale o meno...  ma devo ammettere che
certe volte la lentezza di Java dipende solo dal
"ritardo mentale" del programmatore.  Superato
questo scoglio, sono solo vantaggi, specialmente
se vuoi fare applicazioni basate su CORBA o roba
del genere.


Potrei usarla anche io?
E come no? Mica e' copyright 8-)
Sostanzialmente, non e' che tu faccia nulla di TROPPO diverso da quello
che farebbe una applicazione visuale astuta: cioe', chiedi al server di
"darti una sveglia" quando e se le cose cambiano, e anziche' martellare
il server di richieste, aspetti che LUI ti dica che fare.
In pratica il tuo server invia la prima pagina Web usando il protocollo
multipart-mixed-replace, che e' un sottoinsieme del "mixed-alternative"
usato nella posta elettronica.
In quello si invia la mail in DUE formati (plain e HTML) e si lascia al
MUA il compito di decidere quale usare. Nel primo invece si usa solo un
formato dati, ma questo formato e' inviato in "fotogrammi". Fra l'uno e
l'altro, il browser interrompe il flusso dati, pero' mantiene aperta la
connessione. E se c'e' necessita' di aggiornare i dati, il server invia
la nuova pagina.
Source: 
http://wizard.dvia.com/webmasterbooks/HTML/CH14_03.HTM
Server-push example application for NCSA and Apache httpd
The NCSA and Apache httpd servers run on most UNIX systems. Administrators
usually configure the server to run server-side applications stored in a
directory named cgi-bin. 
The following is a simple UNIX shell script that illustrates how to send a
multipart document to a Netscape client via NCSA or Apache httpd:[3] 
[3] It is an idiosyncrasy of NCSA httpd that no spaces are allowed in the
Content-type field that precedes your multipart document. Some authors like
to place a space after the semicolon and before the boundary keyword. Don't
do this with NCSA httpd; run the whole Content-type together without spaces
to get the server to recognize the correct multipart content type. 
#!/bin/sh
#
# Let the client know we are sending a multipart document
# with a boundary string of "NEXT"
#
echo "HTTP/1.0 200"
echo "Content-type: multipart/x-mixed-replace;boundary=NEXT"
echo ""
echo "--NEXT"
while true
do
#
# Send the next part, followed by a boundary string
# Then sleep five seconds before repeating
#
 echo "Content-type: text/html"
 echo ""
 echo "<html>"
 echo "<head>"
 echo "<title>Processes On This Server</title>"
 echo "</head>"
 echo "<body>"
 echo "<h3> Processes On This Server</h3>"
 echo "Date:"
 date
 echo "<p>"
 echo "<pre>"
 ps -el
 echo "</pre>"
 echo "</body>"
 echo "</html>"
 echo "--NEXT"
 sleep 5
done
Aggiungo io che il file si deve chiamare "nph-qualcosa", altrimenti il
server effettua lui lo header parsing, e succede un bordello :-)
Ci sono altre informazioni sul sito di Netscape.
Ma basta cercare "multipart-mixed-replace" su 
www.google.com
 :-)
