About Harbour Future...
Moderator: Rathinagiri
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
About Harbour Future...
Hi All,
A couple of hours ago I've posted the following message in the Harbour developers mailing list.
////////////////////////////////////////////////////////////////////////
Hi All,
I'm developing an application right now, but, since the application must be accessible to the general public via the web, I've decided to use HTML+PHP+MYSQL.
As an xBase programmer I feel very bad.
I could use Harbour CGI but, run binaries on web servers are not always possible and not available at some hosting services (and IMHO a 'dying' technology anyway).
Some time ago, in this list, someone (I not remember exactly who) said something like that more important that GUIs for different platforms, the web development must be one of the main interest in the future Harbour development.
I absolutely agree with that, but I think that the approach should be a quite different from the ones proposed here.
I guess that the web browsers should be considered as operating systems (or platforms) by itself and that Harbour should be capable of creating 'executables' for such platforms.
That means that Harbour should be capable of create JavaScript code.
I know that It could be tremendous effort to do such thing, that JavaScript is extremely weak and limited compared with C, but as a first goal for this project, only subset of current Harbour features could be supported.
I'm not thinking in a VM wrote in JavaScript, but perhaps, a Harbour to JavaScript translator could be a good idea.
Regarding GUI, interface objects defined via the Clipper 5.3 syntax should be enough to satisfy most of usual needs on web development, so old code could be reused with few changes.
Please, prior to consider this as a 'weird' idea, take a look at Google web toolkit. It translates Java to JavaScript to create web applications, so a Harbour to JavaScript translator could be not an impossible task.
JavaScript run on any browser and browsers run on any operating system (current and future) so the possibilities are unlimited, so we could have our Harbour apps running on any device, current or future.
There was just some random thoughts from a Harbour user... I'll continue writing my PHP app
Regards,
Roberto.
////////////////////////////////////////////////////////////////////////////
Any comments are welcome:
Regards,
Roberto.
A couple of hours ago I've posted the following message in the Harbour developers mailing list.
////////////////////////////////////////////////////////////////////////
Hi All,
I'm developing an application right now, but, since the application must be accessible to the general public via the web, I've decided to use HTML+PHP+MYSQL.
As an xBase programmer I feel very bad.
I could use Harbour CGI but, run binaries on web servers are not always possible and not available at some hosting services (and IMHO a 'dying' technology anyway).
Some time ago, in this list, someone (I not remember exactly who) said something like that more important that GUIs for different platforms, the web development must be one of the main interest in the future Harbour development.
I absolutely agree with that, but I think that the approach should be a quite different from the ones proposed here.
I guess that the web browsers should be considered as operating systems (or platforms) by itself and that Harbour should be capable of creating 'executables' for such platforms.
That means that Harbour should be capable of create JavaScript code.
I know that It could be tremendous effort to do such thing, that JavaScript is extremely weak and limited compared with C, but as a first goal for this project, only subset of current Harbour features could be supported.
I'm not thinking in a VM wrote in JavaScript, but perhaps, a Harbour to JavaScript translator could be a good idea.
Regarding GUI, interface objects defined via the Clipper 5.3 syntax should be enough to satisfy most of usual needs on web development, so old code could be reused with few changes.
Please, prior to consider this as a 'weird' idea, take a look at Google web toolkit. It translates Java to JavaScript to create web applications, so a Harbour to JavaScript translator could be not an impossible task.
JavaScript run on any browser and browsers run on any operating system (current and future) so the possibilities are unlimited, so we could have our Harbour apps running on any device, current or future.
There was just some random thoughts from a Harbour user... I'll continue writing my PHP app
Regards,
Roberto.
////////////////////////////////////////////////////////////////////////////
Any comments are welcome:
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: About Harbour Future...
Rightly said.
Now, may be a silly question.
Is there any possibility to club HMG & GTK? (GTK - either Google web Tool Kit or Gimp Tool Kit.)
Now, may be a silly question.
Is there any possibility to club HMG & GTK? (GTK - either Google web Tool Kit or Gimp Tool Kit.)
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
South or North HMG is worth.
...the possibilities are endless.
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
I'm not sure of fully understand the question, but I'll try to answer.rathinagiri wrote:Rightly said.
Now, may be a silly question.
Is there any possibility to club HMG & GTK? (GTK - either Google web Tool Kit or Gimp Tool Kit.)
GTK is a GUI toolkit. GNOME (Linux desktop) and its applications are based on GTK. GTK is similar to Win32 API (Experimental HMG for Linux is based on GTK).
By the other hand, Google web toolkit is a very different tool.
It allows to create applications capable of run 'inside' a web browser.
You can learn about that here: http://code.google.com/webtoolkit/overview.html
Google docs, gmail, etc are samples of this technology.
Regards,
Roberto
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: About Harbour Future...
Personally,Roberto Lopez wrote:
...
By the other hand, Google web toolkit is a very different tool.
It allows to create applications capable of run 'inside' a web browser.
...
Google docs, gmail, etc are samples of this technology.
I am very worn-out by rushing in pursuit new technologies
Too late for learn, too early for die
Regards
--
esgici
Viva INTERNATIONAL HMG
Re: About Harbour Future...
Hola Roberto et all...
You mean running an interpreter over another interpreter? Harbour pcode over javascript interpreted code...
I don`t know, today's hardware admits all kinds of beasts no mather how many layers of execution they have (see .NET).
Programming is all about metaphores but...
The main difference among a web interface and a gui/cui one is how-when data is accessed and how we keep the program status.
When we open a dfb in a browse the program remembers a lot of things-settings about itself. A web server knows nothing about you each time you send a request to it. All this new javascript-ajax hype is a new try to reinvent the wheel by trying to convert a stateless paradigm into a statefull one again.
When you think of it, we are trying to use the web server program as a data server and a web browser as a desktop.
But as I said earlier it all about how many layers of execution our hardware is capable of.
Who will be the first one to handle that stone ?
Sorry, late night thoughts made public
Cheers to you all.
Angel Pais
Amigo Software
Montevideo-Uruguay
You mean running an interpreter over another interpreter? Harbour pcode over javascript interpreted code...
I don`t know, today's hardware admits all kinds of beasts no mather how many layers of execution they have (see .NET).
Programming is all about metaphores but...
The main difference among a web interface and a gui/cui one is how-when data is accessed and how we keep the program status.
When we open a dfb in a browse the program remembers a lot of things-settings about itself. A web server knows nothing about you each time you send a request to it. All this new javascript-ajax hype is a new try to reinvent the wheel by trying to convert a stateless paradigm into a statefull one again.
When you think of it, we are trying to use the web server program as a data server and a web browser as a desktop.
But as I said earlier it all about how many layers of execution our hardware is capable of.
Who will be the first one to handle that stone ?
Sorry, late night thoughts made public
Cheers to you all.
Angel Pais
Amigo Software
Montevideo-Uruguay
Angel Pais
Web Apps consultant/architect/developer.
Web Apps consultant/architect/developer.
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
Is not 'rush'.esgici wrote:Personally,Roberto Lopez wrote:
...
By the other hand, Google web toolkit is a very different tool.
It allows to create applications capable of run 'inside' a web browser.
...
Google docs, gmail, etc are samples of this technology.
I am very worn-out by rushing in pursuit new technologies
Too late for learn, too early for die
Regards
--
esgici
Because the lack of a 'Harbour For Web Applications' I must use alternative languages like PHP, right now.
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
No. I mean a translator, capable to support a subset of current Harbour features.apais wrote:Hola Roberto et all...
You mean running an interpreter over another interpreter? Harbour pcode over javascript interpreted code...
In other words, I'm talking about a tool that from a .prg Harbour program can generate an equivalent JavaScript program, translating source .prg line by line and adding necessary support functions to emulate Harbour functions used in original Harbour source program.
This way, there is not a double interpretation of the code.
As I've said I'm talking about a translator, so there is not double interpretation.apais wrote:
I don`t know, today's hardware admits all kinds of beasts no mather how many layers of execution they have (see .NET).
Programming is all about metaphores but...
I agree with you, but the web is here and is all around. It is not nice thing for programmers, but, more and more is only way to go.apais wrote:
The main difference among a web interface and a gui/cui one is how-when data is accessed and how we keep the program status.
When we open a dfb in a browse the program remembers a lot of things-settings about itself. A web server knows nothing about you each time you send a request to it. All this new javascript-ajax hype is a new try to reinvent the wheel by trying to convert a stateless paradigm into a statefull one again.
I'm not talking about web sites only. More on more people want to access their applications from wi-fi connected notebooks, public machines or from any other device connected to Internet.
My idea is related to try to keep (as far as possible) the xBase coding style and 'thinking' in this new world.
Exactly yes.apais wrote:
When you think of it, we are trying to use the web server program as a data server and a web browser as a desktop.
Google Web Toolkit is here.apais wrote:
But as I said earlier it all about how many layers of execution our hardware is capable of.
Who will be the first one to handle that stone ?
You can download and test yourself.
http://code.google.com/webtoolkit/
But (again) remember that there is not a new 'interpretation layer' it is all about translation.
Google web toolkit takes Java sources and translates into JavaScript. My proposition is to take Harbour sources and translate into JavaScript.
Thanks!apais wrote:
Sorry, late night thoughts made public
Cheers to you all.
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
A lot of times I had very nice, great ideas, but later discovered that someone had the same idea a lot of time agoRoberto Lopez wrote: I'm not thinking in a VM wrote in JavaScript, but perhaps, a Harbour to JavaScript translator could be a good idea.
Well appears to be that someone had wrote a Basic to JavaScript Translator
The bad news are that I've not being original... the good news are that is possible do it.
http://www.codeproject.com/KB/recipes/JSBasic.aspx
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
And... http://homepages.tig.com.au/~garys/Roberto Lopez wrote:Roberto Lopez wrote: ...
A lot of times I had very nice, great ideas, but later discovered that someone had the same idea a lot of time ago
...
The next time that I have another 'original' idea, I'll google it to assure that it is really original
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About Harbour Future...
I'm talking about this:
- All our programs will run inside a web browser.
- Remember that web browsers are capable of run JavaScript programs (despite the underlying operating system).
- The JavaScript programs must be embedded into a web page (that we will copy to our web server or to local file system).
- The web pages containing our programs should look like this (copy this skeleton and save as 'Test.html'):
- Lets assume that we want to translate the following Harbour program (copy the following code and save as 'test.prg'):
- So, our problem is to automatically translate the '?' command to its JavaScript counterpart.
- Harbour preprocessor is a very powerful tool, so we could create an appropriate directive to handle this situation:
- And add it to the start of our program:
- As you can imagine, document.write is the JavaScript equivalent to Harbour '?' command.
- Finally we will use Harbour preprocessor to do the translation automatically (you'll find it at the Harbour binary distribution as '\bin\hbpp.exe')
- Copy hbpp.exe to our test folder and run the following command:
- A new file (test.ppo) has been created.
- Finally, you must copy the content of that file to the script section of out 'test.html' page. The result is the following:
And open with your web browser.
- Most of you must be wondering... Ok, but what about the data.
The data (of course) will be provided by an SQL server (probably MySql). There is a lot of ways to make the request and retrieve the data, but that is the 'easy' part anyway.
The hard thing here is to write equivalents for Harbour functions to be included in our scripts when required to make your programs work.
This is a huge work that will require thousands of hours of hard work.
More important is that you must not expect to have a 100% Clipper compatibility here. I'm talking about of a subset of Clipper/Harbour functionality, limited by the restrictions of destination platforms (web browsers).
The good news are that HTML and JavaScript are more powerful with each new version, and the computers more faster with each generation, so, the time is on our side.
The prize is very big. Our applications could run on almost any device having a web browser.
The end.
For those considering this ideas weird or silly, I'm sorry in advance if I disturbed you with this
But remember... MiniGUI was considered a silly idea for a lot of people and... we still here
Regards,
Roberto.
- All our programs will run inside a web browser.
- Remember that web browsers are capable of run JavaScript programs (despite the underlying operating system).
- The JavaScript programs must be embedded into a web page (that we will copy to our web server or to local file system).
- The web pages containing our programs should look like this (copy this skeleton and save as 'Test.html'):
Code: Select all
<html>
<body>
<script type="text/javascript">
... our Program must be here ...
</script>
</body>
</html>
Code: Select all
? "Hello World!"
- Harbour preprocessor is a very powerful tool, so we could create an appropriate directive to handle this situation:
Code: Select all
#xcommand ? <argument> ;
=>;
document.write(<argument>)
Code: Select all
* Harbour To JavaScript Translation Directives *
#xcommand ? <argument> ;
=>;
document.write(<argument>)
* Program *
? "Hello World!"
- Finally we will use Harbour preprocessor to do the translation automatically (you'll find it at the Harbour binary distribution as '\bin\hbpp.exe')
- Copy hbpp.exe to our test folder and run the following command:
Code: Select all
hbpp.exe test.prg
- Finally, you must copy the content of that file to the script section of out 'test.html' page. The result is the following:
Code: Select all
<html>
<body>
<script type="text/javascript">
document.write("Hello World!")
</script>
</body>
</html>
- Most of you must be wondering... Ok, but what about the data.
The data (of course) will be provided by an SQL server (probably MySql). There is a lot of ways to make the request and retrieve the data, but that is the 'easy' part anyway.
The hard thing here is to write equivalents for Harbour functions to be included in our scripts when required to make your programs work.
This is a huge work that will require thousands of hours of hard work.
More important is that you must not expect to have a 100% Clipper compatibility here. I'm talking about of a subset of Clipper/Harbour functionality, limited by the restrictions of destination platforms (web browsers).
The good news are that HTML and JavaScript are more powerful with each new version, and the computers more faster with each generation, so, the time is on our side.
The prize is very big. Our applications could run on almost any device having a web browser.
The end.
For those considering this ideas weird or silly, I'm sorry in advance if I disturbed you with this
But remember... MiniGUI was considered a silly idea for a lot of people and... we still here
Regards,
Roberto.
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)