This is intresting post of Steffen F. Pirsig of Alaska Software Inc
------------------------------------------------
i think Bruce ment client/server technology in a more general sense
not strictly related to c/s databases.
Regarding your browse/incompatiblity issue. I totally agree with you,
we have been experimented with the YUI too but found it to heavy
and waggly if you are using CSS and JS code coming from other
third parties. It always ended up with sideeffects or broken features.
In fact we used YUI to develop the first prototype of our new
www applications, unfortunately we realized that the knowledge
needed to create rich functional UI for the browser is to complex
and involves to many different technologies. While this can be handled
by people willing to invest into learning CSS, Javascript, Cross-Browser
issues, we realized, that this approach is far to complex for your
our customer base or target audience in terms of Xbase++.
Our second attempt was to use prototype only, simple clean
CSS and for the forms pure HTML markup. Parts of this web
application prototype are right now the foundation of the
current www application serving customer login, download,
role-base-authentification and so on. However we still feel this
is a to complex technology specifically bec. if you are developing
web applications related to data-entry, such as an ERP
over the web you are forced to learn JavaScript inside out.
Our last attempt was to create a simple transpiler, so
you can create a validation-method for a www form
element in Xbase++ and the Xbase++ code gets transpiled
into Javascript code. Therefore the developer has only to deal
with Xbase++ and some new Classes without any need for
Javascript or Ajax or Prototype knowledge. While this attempt
is the most promising right now it is also an attempt with an huge
investment on our side - so we put that on hold until SL1 is
released and Artica technologies are in community preview
stage.
> YUI is not bad - but the learning curve is quite steep if you do not
> already know javascript to the same level as Xbase++ - especially with
> customers at your back, urging you to deliver results instead of promises
> <g>
Yes thats exactly the point, using YUI makes things in the first step easy,
but
if you are working on a larger project, and if you are forced to use
javascript code
from other sources to add a feature YUI does not provide you are always
ending
up with the need to understand how YUI works inside out. Changing then
the 3rd-party javascript code or CSS to conform with YUI is a difficult and
time
consuming task. We invested into that as our first idea was to create a
Xbase++
infrastructure to support YUI as the standard web interface for Web 2.0
Xbase++ applications but we learned the knowledge to really deliver results,
and to do that in time under customers pressure is not possible without
being
a Javascript, YUI + CSS expert. So finally we decided to drop that idea,
simple because we don't want our customers to be JS + CS + YUI
experts - thats not the idea of a tool like Xbase++.
> Nice idea - I like that. Please send it to me as soon as it is ready <g>
It was an experiment, just to get a proof of concept if that approach will
work better. It worked far better than anything else but we put that on hold
as we our current priorities are different.
> BTW - is there a (undocumented) way to shut down WAA in a "clean" way from
> the inside (from package level code). Currently I'm using QUIT, but I
> don't
> think this waits for all worker threads to be finished.
Not really, but what you can try is the following - i haven't testet it but
IMO it should work -:)
// This function queries the servers main window and
// sends a close message. This is just like you are sitting
// in front of the server and quitting it with a click on
// close icon.
//
FUNCTION MyPersonalShutdown()
LOCAL oDlg := &("GetRootDialog")()
PostAppEvent( xbeP_Close,,oDlg)
RETURN
> Apparently it looks like we will have more n more ActiveX support in
> coming versions of Xb++. Right ?
Not necessarily, we will fix issues and work on performance enhancements.
Other than that is not on our schedule. With Roger , Alaska Software
has agreed to
investigate and resolve issues related to CodeJock as this is what
Rogers and Alaska
Softwares customers want.
http://www.codejock.com/
---------------------------
I agree with you in terms of Terminal Server solutions,
specifically with respect to the positive sideeffect of
increased reliability and performance of dbf/ntx/cdx based
applications deloyed for a larger scale of end-users
without any database server.
However, the Terminal Server use-case is only good
if you have a reliable and "fast" permanent connection.
The neat thing with the web is that it is stateless so
connection drops, bad connections do not affect single
client experience in the same scale as it is with Terminal
Server. In addition Terminal Server may involve huge
Licensing costs plus require that all users are know by
the Servers account-mgmt or LDAP/ActiveDirectory.
I agree with you in terms of the UI experience for end-users
in terms of Web 2.0 applications, they lack a lot of usability
features. However I feel that the current emerging RIA
(Rich Internet Application) platforms such as Adobe Flex
or Silverlight are more likely to reach the level of UI
experience customers await from professional looking
and working data-entry ERP/CRM apps.
Unfortunately, Adobe Flex has to live with a lot of historical
burden in terms of its roots (Flash & ActionScript), while
Silverlight is right now too buggy and the workload in
means of memory consumption is far from being
acceptable. Anyway, both technologies look to me
very promising to delivery a rich end user experience
to the customer over the browser.
Therefore I think, that Terminal Server plays an important
role to provide remote application access for Windows Clients,
PDAs, Windows Mobile. But I also believe that not all deployment
scenarios can be fullfilled with Terminal Server.
Just a few thoughts on that subject,
Steffen F. Pirsig
Alaska Software Inc.
BTW: Sever 2008 allows application virtualization which is a
great feature to deploy only the application not a complete
desktop using Terminal Server. This way the remote application
behaves such as any other local-running windows application
on the remote desktop.
----------------------------
It is our goal to outperform any multi-user scenario in an network. However
it should
be clear that the PostgreSQL ISAM DatabaseEngine can not outperform
- single-user exclusive local file-access
- multi-processes/users shared local file-acess
use cases. As a matter of fact, a great deal of research has been put into
the PostgreSQL DatabaseEngine to provide best possible compatibility with
your existing soure code and business logic - optimized for navigational
data-access.
Again, our goal is to deliver increased performance and better
scaleability in multi user scenarios based on your existing source code.
--------------------------------
The PostgreSQL ISAM DatabaseEngine supports all Xbase++ navigational
commands and functions. This includes also all Index related operations,
including
compound indexes and user-defined-functions in index expression. A migration
tool is included, allowing you to transfer your data and data-model from
table/index
definition to a PostgreSQL Database
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
