[Allegro] Altes von Janas

[Anando Eger]

Hallo Herr Berger,

Sie schrieben u.a.:

> Am besten waere wohl ein Janas, das etwas mit allegro zu tun hat:
> Laengere Aktionen haetten dann Fortschrittsanzeigen und die
> scriptbare Ablauflogik in Janas haette quasi direkten Zugriff
> auf die Datenbank. In die Richtung ging das ActiveX-Plugin, das
> Herr Hoeppner vor 10 Jahren einmal vorgeschlagen und versuchsweise
> implementiert hatte (ich weiss jetzt nicht, ob das wirklich direkt
> zugriff oder ueber a99 als Mittler, das ist dann aber egal, wenn
> die vom Plugin bereitgestellten Methoden stimmen).

Diese Methodik (OCX-Controls mit direkten DB-Zugriff) wird von der 
Büchereizentrale Niedersachsen jetzt schon in der 2. Generation 
(.NET-Assemblies) eingesetzt. Bedauerlich finde ich es, dass dazu 
keine offiziellen Dokumentationen bereitgestellt werden, wodurch 
die vom Braunschweiger Allegro gewohnte Offenheit der Anwendung 
verlorengegangen ist - wodurch es für unabhängige Entwicker zunehmend
uninteressanter wird. "Überlebt" hat bisher noch die Exportsprache
auf dem Stand von etwa V13.1.

> Am zweitbesten waere, wenn Janas ueberhaupt nichts mit allegro
> zu tun haette: a99 haette einen eingebauten (single-threaded)
> HTTP-Server und koennte einfache Dateien ausliefern sowie das
> Ausfuehren von Flexen veranlassen. ...

genau - das Protokoll wird von a99 (transparent für den Flex-
Schreiber) behandelt, Standard-Ausgabe-Kanal für Write oder Export 
im Server-Kontext wäre dann der TCP-Socket zum HTTP-Client.

Die Verwendung von HTTP statt eines eigenen Protokoll hätte ja den 
Vorteil, dass man es beispielsweise 1:1 mit ajax nutzen könnte.

Viele Grüße
Anando Eger



On 7 Oct 2011 at 11:51, Thomas Berger wrote:

> Lieber Herr Eger,
> 
> > Unter http://support.microsoft.com/kb/95900 findet man diese schöne Aufstellung:
> > 
> > IPC Mechanism   Win2000  WinNT  Win9x   Win32s(1)  Win16(2)  MS-DOS(2)  POSIX  OS/2
> >    -------------  -----  -----  ------  --------   --------  --------   -----  -----
> > 
> >              DDE  YES     YES    YES      YES        YES       NO        NO     NO
> >          OLE 1.0  YES     YES    YES      YES        YES       NO        NO     NO
> >          OLE 2.0  YES     YES    YES      YES        YES       NO        NO     NO
> >          NetBIOS  YES     YES    YES      YES        YES       YES       NO     YES
> >      Named pipes  YES     YES    YES(3)   YES(3)     YES(3)    YES(3)    YES(4) YES
> >  Windows sockets  YES(5)  YES(5) YES      YES        YES(5)    NO        NO(6)  NO
> >        Mailslots  YES     YES    YES      YES(3)     NO        NO        NO     YES
> >       Semaphores  YES     YES    YES      NO         NO        NO        YES    YES
> >              RPC  YES     YES    YES(7)   YES(8)     YES       YES       NO     NO
> >  Mem-Mapped File  YES     YES    YES      YES        NO        NO        NO     NO
> >      WM_COPYDATA  YES     YES    YES      YES(9)     YES       NO        NO     NO
> > 				
> > Da müßte doch etwas für a99-JanaS verwendbares dabei sein ;-)
> 
> z.B. anonyme Pipes, denn named Pipes koennen m.E. nur vom Administrator
> aufgesetzt werden...
> 
> 
> > Z.B. könnte eine Named Pipe nebenbei dazu dienen, genau eine a99-Instanz mit 
> > genau einem JanaS-Prozess zu verheiraten. 'janas 0' wäre dann die Scheidung, 
> > eingereicht durch a99.
> > 
> > Um das weiter zu spinnen: Wenn JanaS "an" ist, könnten ja write-Ausgaben direkt 
> > in die pipe zu Janas umgeleitet werden - und als flex:-Request-Anwort ankommen.
> > 
> > Wenn das ginge, hätte man das Paradies in JanaS ;-)
> 
> Am besten waere wohl ein Janas, das etwas mit allegro zu tun hat:
> Laengere Aktionen haetten dann Fortschrittsanzeigen und die
> scriptbare Ablauflogik in Janas haette quasi direkten Zugriff
> auf die Datenbank. In die Richtung ging das ActiveX-Plugin, das
> Herr Hoeppner vor 10 Jahren einmal vorgeschlagen und versuchsweise
> implementiert hatte (ich weiss jetzt nicht, ob das wirklich direkt
> zugriff oder ueber a99 als Mittler, das ist dann aber egal, wenn
> die vom Plugin bereitgestellten Methoden stimmen).
> 
> Am zweitbesten waere, wenn Janas ueberhaupt nichts mit allegro
> zu tun haette: a99 haette einen eingebauten (single-threaded)
> HTTP-Server und koennte einfache Dateien ausliefern sowie das
> Ausfuehren von Flexen veranlassen. Das ist insofern aehnlich
> der alten "Ruckzuck"-Methodik von 2001, als a99 erforderlich
> ist, kommt aber ohne separaten Webserver und das als cgi.exe
> verbraemte exflex.exe aus. Die eingebaute http-Library sollte
> dabei auch den wuenschenswerten Nebeneffekt haben, dass
> Escaping und Konstruktion von HTTP-Headern nicht den Flex-
> Dateien ueberlassen wird. Mit allegro-OpenSource sollte es
> lizenztechnisch moeglich sein, sich staerker als vorher an
> existierenden Loesungen zu bedienen, also als Komponenten *in*
> allegro-Modulen zu verbauen.
> Warum das a99 sein sollte, weiss ich uebrigens gar nicht, vgl.
> meine Auesserungen neulich, dass man avanti eigentlich nicht
> mehr braucht, wenn acon einen HTTP-Server eingebaut haette
> (o.k., fuer echtes Client/Server brauchen wir etwas asynchrones
> oder multithreadiges, fuer Janas koennte das aber auch nicht
> schaden, wenn vom Nachbarbuero oder Handy aus ohne lokal
> installierte Allegro-Module aus katalogisiert werden kann).
> 
> Vom derzeitigen Janas ist wie beim derzeitigen avanti eigentlich
> gar nicht klar, was es denn wirklich tut und ob nicht das, was
> es tut, den Weg fuer vernuenftige Loesungen blockiert:
> 1. Es kann ein Signal vom "zugehoerigen" a99 empfangen und laedt
>    daraufhin "seine" HTML-Datei neu (bzw. ueber eine Pointer-
>    Datei ist das etwas indirekter und damit flexibler geregelt)
> 2. Es kann gewisse URLs ("flex:" statt "javascript:" oder "http:")
>    behandeln und schreibt die zugehoerigen Daten aus GET- oder
>    POST-Requests in eine Datei, dabei wird alles noch mit einigen,
>    oft wenig hilfreichen Flex-Kommandos garniert, und signalisiert
>    dann dem "zugehoerigen" a99, diese Datei nach der Exflex-Methode
>    zu aktivieren.
> D.h. hier wird clientseitig dafuer gesorgt, die Kommunikation
> von etablierten Mechanismen (HTTP ueber TCP/IP) auf "flex ueber
> on-the-fly geschriebenen Dateien plus Windows-Interne Wecksignale"
> umzubiegen, ich halte das fuer keinen besonders tragfaehigen
> Ansatz.
> 
> viele Gruesse
> Thomas Berger
> 
>