History of the name vs library history

The origin of GranPrimo name was for a relation with Gran Hermano (in spanish) that is Big Brother (in English):

Gran=Big, Primo=Cousin : GranPrimo = BigCousin. (It was a little joke of words)

The first idea was to do a "observation portal for a desktop pc" like a big brother Tv, showing the image of the pc. The first intencion was not very clear, maybe only an experiment to learn more about how to do a program which actue as web server. I hadn't idea about what socket library to use: But the first I used was ICS, then i tried with winshoes. But looking for a compact socket version and looking for play more at low level with sockets, I finally start to use a own implementation of a basic socket unit with the minimal functions necesary for the "game".

The first objetive was to obtain the desktop image as a HTML page with graphics. It was really easy to obtain the Desktop image (first in BMP), and make the "hello world" html page version with a graphic showing the image of desktop. It was funny!

The First observation was about the size of the BMP image optained was too much big to run in internet. The next steep was to compress it in jpej (by TJPEG component in delphi), but even than have so much size to run in a slow connection . Then I tried to strech the image (By streching the 70% of the image I obtain a very more little graphic.). and changing the jpeg quality I reduced the side too. I was surprised than there was not any good (and public) strech function in windows API without deforming the image, (then I did one)

It start to be posible to see the remote image. And refresing the page, the image refreshed too.

I start to look for more actions, like donwload files and show directory information, and look for interactue with the image graphics (to interactue with the screen). Then I started to understand than the problem was more complex than I imagine. It was necesary to handle different calls with params in pararell, there was very much things to understand about the HTTP at low level, understand the browser comunication with the server, and start to use the JavaScript in the HTML page too ( to try to refresh the image content without refreshing all the page). Because it was needed to use threads of process to handle simultatinus http calls It was difficult to syncronice the events proccesed by the threads (specially with the desktop). It was necesary to have any password protection to "login" so was necesary to include "user session" support.

The first version was ready encapsulated only in one component. The first objetive was finished. But the result was not very special (because the screen refresh was slow and with an ugly flick effect because "strange" effects in the html browser).

I finally end frustated when I see VNC program running in the browser as a Java applet (refreshing the connent in "intelligent" way, by transfering only the bits changed on the screen image) . It was the end of Gp ?

I start to look for other features than was not implemented in other components or progams. The first "good idea" was to do a remote objects inspector for the program where the component was running. So by adding the component in a "normal" delphi application, it was possible to have remote acces to the files, to see and click the remote desktop, and inspect and change the objects properties of the application. I added other things like display the list of active running process ( and posibility of stop it).

The only one component, was now a very big component (with some childs with different purposes), But start to be difficult to add more services and it was some constant HTML code in the program not so much structurated , It was difficult to handle composed pages, add new features start to be difficult. Even more, it was not so good idea to have all the features in only one component, ( because the potencial users maybe want to have only some of this features).

Then I refactored the library to have the different features (files, desktop,object, process...) in different child objects (with same inheritance) than plug in a "central" component which handle the comunication between the http calls to this child objects. So we have a more structurated library where is more easy to add new features by using new child classes with specific and encapsulated functions. I start to use a component to render the html code (it was more easy to contruct the pages in a structurated way than using constant HTML code. See THtm object )

Because the Desktop HTML access was not very good result. I start to implement a java applet which refresh the image in more pretty way. It was not easy to touch the comunication between the java applet and delphi server (I was a novice in this area). The firt java prototype refreshed the entire screen without the flick effect of the HTML browser. The second steep was to do than only the changed portions of screen was refreshed. Really this was one of the more difficult feature of the library, because have lot of problematics to be solved in a compact solution. The applet work with different size zooms of the screen, it interchange the events with the server, and obtain screen pieces in blocks of jpeg images. It must to be pure HTTP oriented and proxy friendly. Implement drag and drop and more...

My interest for other librarys was growing. Specially IntraWeb (Because it was/is a wonderfull web application builder). And I tried the posibility to have my job compatible with IntraWeb. But again it was a problem, because more changed in the library must to be done. (For the "special way" than intraweb works, specially in comunicate between page and server by using "complex" javascript functions. Imposible to use by java). Really, the system used to refresh the remote desktop applet is that now is named as AJAX.

I start to think in use other "transport" socket library for the components ( because it can be usefull to use the Gp features in different user library). Indy was my first election, because it is integrated in delphi, and I was loved winshoes too (the antecesor of Indy) . See GpIndy for more.

The possibility of use https ( SSL connections) finally won in the decision to integrate Gp in Indy library. Now Gp was adapted to use in Intraweb and Indy ( with SSL) , and in my "indepent" socket implementation. Then was easy to "translate" it to other librarys too. I adapted it to Synapse, becuase is very good, very used, open source, and very compact and really concrete. ( Maybe the only one problem is the poor thread infraestructure). But as it is very thread independent, it was easy to integrate with Gp.

An ActiveX "experiment" was done too. (activex.htm).

It was necesay any solution for case where was imposible to contact with the application ( because was closed the incomming connections ports). See Bridge connection.

It be done a new feature called "Spyce" than is a way to do web page forms by using desktop delphi forms. Is usefull to add features to Gp by using easy delphi standart controls.

Other additions was done to the Gp library:

Now. I'm focused to integrate more AJAX support. to build a "multi-purpose" and "multi-tear" remote control library. With very "special" features than was not f

Maybe GranPrimo was a very old name now, because the first purpose was only wach the remote screen, but now Gp is a "multi-purpose" and "multi-tear" remote control library.

I just decided to change the name of the library in the new release: By by GranPrimo, and wellcome GranPuente.










Teléfono: 978-610539 - Fax: 978-610861 -Trav.Agustina Aragón 1,1e 44002 Teruel ( España ).webmaster

Copyright © 1997-2004 , [Multi-Informatica Teruel, S.L].La información contenida en este documento está sujeta a modificaciones sin previo aviso. Otros productos u organizaciones mencionadas aquí son marcas comerciales o marcas registradas propiedad de sus respectivas organizaciones o propietarios.