Newsgroup: it.comp.java
Titolo: [NEWBIE] Java, Derby e client su terminali VT220

Salve a tutti,
premetto che so poco o niente di Java e quel poco che so è ben
confuso,ma non sono io il programmatore,quindi... :-) .
Stiamo realizzando un'applicazione server in Java che importa dati da un
database SQL, costruisce con essi un database in Derby (JavaDB) e rende
disponibili tali dati alla manipolazione attraverso un'interfaccia
implementata nell'applicazione server stessa o attraverso un'
applicazione client(sempre in Java).Sostanzialmente si tratta di un
gestionale di produzione che acquisisce dati da un ERP.
La domanda è questa:
vogliamo scrivere nel database JavaDB partendo da un programma client
(presumibilmente sempre in Java) che gira in DOS.
Questo programma deve  per forza usare un'emulazione di terminale ANSI
VT220 e trasmettere via radio al server dove risiede il database Derby i
dati raccolti.
Da lato client probabilmente non è un problema implementare
l'applicazione DOS capace di girare in un terminale VT220, ma da lato
server...
Non sappiamo da che punto partire perché non abbiamo esperienza di
terminali VT220 e roba simile.
Qualche anima pia che ci dia un'imbeccata?
Grazie
Lorenzo

 Qualche anima pia che ci dia un'imbeccata?
Ciao, non ho capito una parte della domanda : voi dovete scrivere un
programma _server_ che scriva (sul System.out o su un socket) in formato
vt220, giusto ?
Cioè "qualcuno" (un programma o un umano) apre una sessione di emulatore
vt 200 verso un server linux-unix, lancia il vs. programma Java e gli
"parla" in formato vt220 (campi, gestione dei tasti cursore, ...).
Io lavoro su programmi java che fanno (apparentemente) il contrario,
cioè aprono una connessione tcp-ip verso un server telnet (5250, 3270),
"leggono" la struttura della videata e ne fanno il rendering in XHTML,
poi aspettano che l'utente compili i campi e li riportano sulla sessione
telnet sottostante.
Mi sembra quindi che voi dovreste cercare una libreria per implementare
il protocollo vt220 (
http://vt100.net
) lato server ... o altrimenti vi
sciroppate le specifiche del protocollo e ve lo reimplementate .
Chiaro che se poi sulla connessione ci fossero DUE programmi java che si
parlano direttamente ... buttte a mare il vt220 e vi parlate riga per
riga o via XML.
Ciao, in bocca al lupo e... fate sapere al ng com'è andata a finire.
    Davide
--
Ing. Davide Grandi
davide...@mclink.it

il 16/02/2009 19.52, Scrive Lorenzo 38534696:

Il paletto del DOS e' bello grosso. Per quanto ne sappia io, lo stack 
TCP/IP che esisteva in DOS era molto ridotto, praticamente 
inutilizzabile, in quanto il DOS, non essendo multi-threading, non 
permette la stratificazione delle applicazioni secondo la pila TCP.
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

 Ciao, in bocca al lupo e... fate sapere al ng com'è andata a finire.
Certamente!
P.S.: il nostro mantainer del gestionale proprietario ha visto il lavoro
e vuole assumerci... :-)
Lorenzo

 
Ma dai! Lo sparaflashatore :) Però mi viene un dubbio. Io utilizzai anni
fa uno di questi cosi (se ho capito bene le specifiche) per un magazzino
di una "nota_ditta_elettronica_consumer". Ma gli aggeggi in questione
facevano solo da terminale stupido. Quindi
1) Si connettevano (non so come, per la verità) ad un server unix come
terminali (tipo i vt100/220, appunto) che li vedeva come "tty"
2) Il programma (in C) girava sul server, non sui terminalini. Quindi da
terminale era come se, tanto per chiarire (speriamo) facessi telnet al
server e mi si aprisse l'applicazione specificata (che naturalmente
usava i caratteri di controllo vt100 e le dimensioni del video
corrette). Il vantaggio era naturalmente che il magazziniere potesse
leggere i codici a barre col laser quando da programma veniva richiesto
un input.
Noi sviluppatori invece facevamo, per testare, proprio telnet al server
in questione e lui apriva una sessione del programma
Quindi perché tu vuoi mettere un programma sul terminale? Non ho capito
un ciuppo? ;)
-- 
bye
DKano

 permette la stratificazione delle applicazioni secondo la pila TCP.
Purtroppo sono ignorante in materia, ma so che il terminale che voglio
usare è collegabile in rete Ethernet , e quindi presumo che il TCP/IP
sia implementato per default.
Ciao
Lorenzo

 Lorenzo
Ciò conferma il mio dubbio di prima... sei sicuro di dover mettere della
roba sw nel terminale?
-- 
bye
DKano

 un ciuppo? ;)
Non era chiaro a me.
Grazie!
Lorenzo

 
Si a parte l'ssh su cui ho dei dubbi, sinceramente della parte
'collegamento' non mi ero occupato, ma vedendola sempre da un server
unix, i teminali erano visti come connessioni 'tty' in pratica come se
si collegasse direttamente una tastiera e un monitor oppure un terminale
vt100 originale ad una porta seriale (o dove si attaccavano).
Ti serve che la connessione sia protetta/criptata? Allora non credo ci
si fosse posto il problema in quanto intercettare dei Part Number non è
che potesse fare gran danno
-- 
bye
DKano

 Ti serve che la connessione sia protetta/criptata?
sarebbe più bello per fare una cosa ganza, ma non è che mi interessi
proprio...
Ciao e grazie delle dritte!
Lorenzo

 provvederò a pensare a come connettermi.
Secondo me si. L'unica cosa è che ovviamente ti può esser utile è un
terminale vt100. Direi che basta un "export TERM=vt100; telnet
tuoserver" su un qualche linux
-- 
bye
DKano