Newsgroup: it.comp.os.dos
Titolo: Internet

Fra i vari prodotti disponibili sapreste consigliarmi dei programmi per la
spedizione e ricezione di Mail da DOS (6.22):
software di connessione + Mail + (eventuale) Browser
magari free.
Grazie a tutti

Ciao!
Ti consiglio di scaricarti il "pacchetto rete" da
digilander.iol.it/arti2000
: sono 3 mb ed Š facilmente configurabile perch‚
come forse sai, configurare i packet drivers a mano, non Š poi cos  semplice
:-))))
Se hai problemi sono a tua disposizione, Š molto tempo che lo uso io :-)
Ciao
Html-man - ICQ 70825171
http://www.htmlman.net
 

 Se hai problemi sono a tua disposizione, S molto tempo che lo uso io :-)


semplice 
usi un newsreader di dos? se sì, evita le accentate... il 99% di Usenet ti
ricoprirà di sputacchi

On 2000-12-30 
jul...@z.com
(KJK::Juliet) said:
   >Newsgroups: it.comp.os.dos
   >usi un newsreader di dos? se si`, evita le accentate... il 99% di
   >Usenet ti ricoprira` di sputacchi
Rotfl!!!
OK, hai ragione! Grazie :-))))


spedizione e ricezione di Mail da DOS (6.22):
Provato Arachne?
http://arachne.cz/
Ormai e' arrivato da tempo alla versione stabile, occupa poca memoria
ed e' un browser decente (tenendo presente la fottutissima moda di
infarcire di javascript ogni pagina).
Fabrizio

 infarcire di javascript ogni pagina).
Rendere dinamiche le pagine spesso non e' una moda ma una
necessita'... se si vogliono fare determinate cose il solo HTML non
basta.
-- 
Alessandro
-------------------------------------------
"There is no dark side of the moon, really...
as a matter of fact it's all dark."
PinK FloYd
-------------------------------------------

basta.
Si, certo, viva l'innovazione, ma quando il sito si rifiuta di spedirti
una mazza se non accetti java o, peggio, activeX, allora viene da
chiedersi se il sito stesso ha contenuti, oppure se e' solo apparenza.
Un sito troppo "pesante" a me fa prudere il tasto rosso di stop... ;-)
Fabrizio

BowlingBPSL ha scritto:

Anche a me, pero'
Delle soluzioni ci sarebbero...
Innanzitutto Javascript, Java, DHTML sono sottoposti a standard (e per
standard intendo delle specifiche Pubbliche ratificate da organismi
di controllo SUPER PARTES), basterebbe attenersi a quelli e gia' si
sarebbe a buon punto. Persino Arachne mi pare suporti il Javascript
(mi pare...).
Tanto per capirsi non esiste uno standard ActiveX... e le
implementazioni Javascript e Java di Microsoft spesso sviano dagli
standard (per non parlare dei tools di sviluppo M$ che generano
applicazioni in modo non standard anche se basate su linguaggi
ufficialmente standardizzati) ma quasi tutti quelli che con questi ci
lavorano quasi mai ci pensano e credono che siano gli altri a
sbagliare o a essere "deficitari" (della serie:  "...non sono IO che
ho qualcosa di diverso ma e' a TE che manca qualcosa...", questioni di
punti di vista e di CULTURA).
Poi permettere sempre delle alternative tipo pagine NOFRAMES per chi
non puo' visualizzare i frames (ma questo valeva un tempo...) oppure
pagine senza applet java ecc. pero' con la consapevolezza di perdere
delle funzioni.
Bisogna pero' distinguere le applicazini che aggiungono FUNZIONALITA'
da quelle puramente estetiche: delle prime spesso non si puo' fare a
meno, delle seconde ne abbiamo troppo spesso un' ABUSO (tieni conto
pero' che ad appesantire le pagine ci possono anche essere delle
semplici GIF o JPG troppo grosse ).
Altra soluzione sarebbe quella di rendere le pagine dinamiche tramite
programmi "server side" cioe' che dipendono solo dal server, tipo PHP,
ASP, CGI e che producono pagine HTML funzionanti allo stesso modo su
(quasi)tutti i Browsers ma l'inconveniente e' che se anche qui' si
esagera si finisce per caricare mediamente troppo il server con
conseguente rallentamento del servizio per cui il compromesso migliore
sarebbe quello di lasciare al Server solo quello che il Client NON
puo' fare (il Javascript non puo' accedere ai database ad esempio). E'
(IMHO) poco utile fare le "validation forms" oppure il programmino che
calcola i mutui sul sito delì' AG.Immobiliare in PHP quando potrebbero
gestirle benissimo i Client in Javascript. Lasciamo al PHP la gestione
di quelle pagine interattive direttamente collegate al database.
Tutto questo se si vuol dare un servizio.
Quanto a Java... la vera palla al piede per i naviganti, (dopo
ActiveX, noto tra l'altro per essere un formidabile veicolo di
"infezione"), dipende molto da come l'applet viene scritta e con quale
vers. del JDK. la 1.2 e soprattutto la 1.3 sono sensibilmente
migliorate in efficenza e velocita' pero' sono troppo recenti. 
Per ottenere le migliori prestazioni bisognerebbe che il Runtime delle
JVM sul client e
l'applet che riceve siano almeno al Livello 1.2; purtroppo la
stragrande maggioranza delle applet sono ottimizate per vers.
precedenti, andrebbero riscritte tutte e tutti dovrebbero aggiornare
il proprio runtime.... quando la maggiorparte degli utenti l'avra'
fatto ci sara' ormai la vers. 3 di Java.  
A tal proposito ho trovato un'articolo interessante a questo URL:
http://www.programmazione.it/index.php?entity=earticle&idArticle=197&idArea=36
sul problema della pesantezza delle applet JAVA.
