Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

universal application platform

3 posts in Appeon (partner product) Last posting was on 2006-12-05 18:02:39.0Z
vlad.vladutzu Posted on 2006-12-03 18:28:45.0Z
From: vlad.vladutzu@gmail.com
Newsgroups: sybase.public.appeon
Subject: universal application platform
Date: 3 Dec 2006 10:28:45 -0800
Organization: http://groups.google.com
Lines: 94
Message-ID: <1165170525.608125.251660@73g2000cwn.googlegroups.com>
NNTP-Posting-Host: 86.121.137.213
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1165170531 27555 127.0.0.1 (3 Dec 2006 18:28:51 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 3 Dec 2006 18:28:51 +0000 (UTC)
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: 73g2000cwn.googlegroups.com; posting-host=86.121.137.213; posting-account=YR6QPg0AAACTVSn5NeAokKgH2h46bhxj
Path: forums-1-dub!forums-master!newswest.sybase.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!73g2000cwn.googlegroups.com!not-for-mail
Xref: forums-1-dub sybase.public.appeon:1691
Article PK: 21315

Here is an ordinary day in the IT department of a big company. Boss
says: "Hey, Jack, we have a new application. Is written in
PowerBuilder and is has to be installed on all our 300 workstations
!". "Great, says Jack. Another pain in the ass. Last month was a
Java Swing application, three months ago was a Visual Basic... And I
have to do all the work. Damn, I think I am gonna switch to a taxi
driver job !".
Swell, isn't it ? Well, there are a few techniques to improve the
installation procedure of a classic two tier application, but why not
solve the problem from it's root ? "Hey, Jack, we have the solution
!", we say to poor Jack. "Ah, yes, I know, web applications of
course. Workstations only have to have a browser. But man, they are so
clumsy ! They are slow and not easy to develop. And it's stupid to
use internet technologies inside a LAN. And the users always complain
about graphical interface. And you know how it is when end users
complain about graphical interface !", says Jack, showing his teeth.
We smile condescendingly. We have a better solution.

Why not have them all ? Why not combine the best parts from both worlds
? This is what we propose now: a Universal Applications Platform. It is
a "thing" that will allow LAN applications to be installed on a
sever and to be accessed from a sort of browser, just like web
applications, but the speed will be just like in 2-tier applications.
And they will be easy to develop, with a RAD IDE. And the beauty of the
interface will make women cry.

Now seriously. Here is the idea: in a web application, we have a data
server which holds data, an application server which performs business
computation and a web server which presents the data to its client -
the web browser. This is good for an internet application, no doubt
about it. But...
There are not many organizations who run web applications, compared to
those which have classic 2-tier applications running. The need for this
kind of applications was and will continue to be HUGE !
That is why we think it worth to develop a cool mechanism for LAN
applications. It will be similar to normal browser-HTTP-web server
mechanism, only the browser will be more cool, the protocol will be
heavier (since data will not have to swim across the Internet ocean),
faster and more powerful in order to achieve the performance of a
2-tier system. Instead of a web server there will be a "presentation
server", which will generate the "view" part (as in MVC pattern)
and will deliver it to its cool browser.

Now let's put all the pieces together. We have:
- a data layer which, by the way, would be nice to be obiectual instead
of relational;
- a business layer;
- a presentation layer: this would be one of the four parts of our cool
mechanism;
- a connection & deliver manager - the second part of our cool
mechanism;
- a cool protocol for local area network communication - the third part
of our cool mechanism;
- a cool "browser" used to access the applications on the server:
the final piece.

The presentation layer: this layer will generate the visual format of
the data to be displayed to the end user. This layer will have to
overcome the limitations of the HTML/CSS/JavaScript/AJAX and to provide
a native-like interface and joy of living to end-users.
The connection & delivery manager: this will be something like a web
server. It will manage connections and will deliver the requested
content to each client.
The protocol for local area network communication: this will not be
stateless like HTTP, it will be specially designed for LAN
communication, for easy development and also for the performance needed
by enterprise class applications. The communication could also be done
by messages like in the old PeopleSoft architecture.
The "Browser", or maybe is better to call it "executer": this
will be platform dependent. It will receive from the presentation layer
a "description" of the page to be displayed and will build/render
the page based on the underlying operating system capabilities. That
description will contain both the structure of the page and the data.

The four layers - data, business, presentation layers and the
connection manager - may be part of the same server program if best
performance is desired, or they can be different programs, as they are
now in web applications. The business layer could be represented by a
stored procedures engine inside the data server, or it can be a regular
J2EE server. The cool browser can be a regular browser updated to
support the new cool protocol, but it better be totally new.

Of course this new devices will have to be widely accepted and become a
de-facto industry standard, otherwise the goal of Universal Platform
will not be achieved.

A few words about terminal software solution. We do not like this
solution because this software is complicated and the network traffic
increases unacceptably. And a word about applets: it is not a bad idea,
still there is place for serious improvement. And Flash ? Not bad.

This was my idea. I hope you like it. If not, let forgotness lay above
it...


Dean Jones Posted on 2006-12-04 14:17:46.0Z
From: "Dean Jones" <dean_dot_jones_at_powerobjects_dot_com>
Newsgroups: sybase.public.appeon
References: <1165170525.608125.251660@73g2000cwn.googlegroups.com>
Subject: Re: universal application platform
Lines: 111
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
NNTP-Posting-Host: 216.207.144.172
X-Original-NNTP-Posting-Host: 216.207.144.172
Message-ID: <45743c1a$1@forums-1-dub>
Date: 4 Dec 2006 07:17:46 -0700
X-Trace: forums-1-dub 1165245466 216.207.144.172 (4 Dec 2006 07:17:46 -0700)
X-Original-Trace: 4 Dec 2006 07:17:46 -0700, 216.207.144.172
X-Authenticated-User: teamsybase
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.appeon:1693
Article PK: 13104

I don't understand this post. Was it an ad for Appeon? Was there a question?

--
Dean Jones
CEO
PowerObjects
http://www.powerobjects.com
(612) 339-3355 Ext. 112

TeamSybase
* * Think Sybase * *

<vlad.vladutzu@gmail.com> wrote in message
news:1165170525.608125.251660@73g2000cwn.googlegroups.com...
> Here is an ordinary day in the IT department of a big company. Boss
> says: "Hey, Jack, we have a new application. Is written in
> PowerBuilder and is has to be installed on all our 300 workstations
> !". "Great, says Jack. Another pain in the ass. Last month was a
> Java Swing application, three months ago was a Visual Basic... And I
> have to do all the work. Damn, I think I am gonna switch to a taxi
> driver job !".
> Swell, isn't it ? Well, there are a few techniques to improve the
> installation procedure of a classic two tier application, but why not
> solve the problem from it's root ? "Hey, Jack, we have the solution
> !", we say to poor Jack. "Ah, yes, I know, web applications of
> course. Workstations only have to have a browser. But man, they are so
> clumsy ! They are slow and not easy to develop. And it's stupid to
> use internet technologies inside a LAN. And the users always complain
> about graphical interface. And you know how it is when end users
> complain about graphical interface !", says Jack, showing his teeth.
> We smile condescendingly. We have a better solution.
>
> Why not have them all ? Why not combine the best parts from both worlds
> ? This is what we propose now: a Universal Applications Platform. It is
> a "thing" that will allow LAN applications to be installed on a
> sever and to be accessed from a sort of browser, just like web
> applications, but the speed will be just like in 2-tier applications.
> And they will be easy to develop, with a RAD IDE. And the beauty of the
> interface will make women cry.
>
> Now seriously. Here is the idea: in a web application, we have a data
> server which holds data, an application server which performs business
> computation and a web server which presents the data to its client -
> the web browser. This is good for an internet application, no doubt
> about it. But...
> There are not many organizations who run web applications, compared to
> those which have classic 2-tier applications running. The need for this
> kind of applications was and will continue to be HUGE !
> That is why we think it worth to develop a cool mechanism for LAN
> applications. It will be similar to normal browser-HTTP-web server
> mechanism, only the browser will be more cool, the protocol will be
> heavier (since data will not have to swim across the Internet ocean),
> faster and more powerful in order to achieve the performance of a
> 2-tier system. Instead of a web server there will be a "presentation
> server", which will generate the "view" part (as in MVC pattern)
> and will deliver it to its cool browser.
>
> Now let's put all the pieces together. We have:
> - a data layer which, by the way, would be nice to be obiectual instead
> of relational;
> - a business layer;
> - a presentation layer: this would be one of the four parts of our cool
> mechanism;
> - a connection & deliver manager - the second part of our cool
> mechanism;
> - a cool protocol for local area network communication - the third part
> of our cool mechanism;
> - a cool "browser" used to access the applications on the server:
> the final piece.
>
> The presentation layer: this layer will generate the visual format of
> the data to be displayed to the end user. This layer will have to
> overcome the limitations of the HTML/CSS/JavaScript/AJAX and to provide
> a native-like interface and joy of living to end-users.
> The connection & delivery manager: this will be something like a web
> server. It will manage connections and will deliver the requested
> content to each client.
> The protocol for local area network communication: this will not be
> stateless like HTTP, it will be specially designed for LAN
> communication, for easy development and also for the performance needed
> by enterprise class applications. The communication could also be done
> by messages like in the old PeopleSoft architecture.
> The "Browser", or maybe is better to call it "executer": this
> will be platform dependent. It will receive from the presentation layer
> a "description" of the page to be displayed and will build/render
> the page based on the underlying operating system capabilities. That
> description will contain both the structure of the page and the data.
>
> The four layers - data, business, presentation layers and the
> connection manager - may be part of the same server program if best
> performance is desired, or they can be different programs, as they are
> now in web applications. The business layer could be represented by a
> stored procedures engine inside the data server, or it can be a regular
> J2EE server. The cool browser can be a regular browser updated to
> support the new cool protocol, but it better be totally new.
>
> Of course this new devices will have to be widely accepted and become a
> de-facto industry standard, otherwise the goal of Universal Platform
> will not be achieved.
>
> A few words about terminal software solution. We do not like this
> solution because this software is complicated and the network traffic
> increases unacceptably. And a word about applets: it is not a bad idea,
> still there is place for serious improvement. And Flash ? Not bad.
>
> This was my idea. I hope you like it. If not, let forgotness lay above
> it...
>


vlad.vladutzu Posted on 2006-12-05 18:02:39.0Z
From: vlad.vladutzu@gmail.com
Newsgroups: sybase.public.appeon
Subject: Re: universal application platform
Date: 5 Dec 2006 10:02:39 -0800
Organization: http://groups.google.com
Lines: 113
Message-ID: <1165341759.558831.111900@n67g2000cwd.googlegroups.com>
References: <1165170525.608125.251660@73g2000cwn.googlegroups.com> <45743c1a$1@forums-1-dub>
NNTP-Posting-Host: 86.121.135.58
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1165341765 455 127.0.0.1 (5 Dec 2006 18:02:45 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 5 Dec 2006 18:02:45 +0000 (UTC)
In-Reply-To: <45743c1a$1@forums-1-dub>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: n67g2000cwd.googlegroups.com; posting-host=86.121.135.58; posting-account=YR6QPg0AAACTVSn5NeAokKgH2h46bhxj
Path: forums-1-dub!forums-master!newswest.sybase.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!n67g2000cwd.googlegroups.com!not-for-mail
Xref: forums-1-dub sybase.public.appeon:1696
Article PK: 13106

No, it is not an ad and there is no question. It was an idea of mine
which I wanted to make public, to see how people apreciate it. I did
not know where else to post it.

On Dec 4, 4:17 pm, "Dean Jones"

<dean_dot_jones_at_powerobjects_dot_com> wrote:
> I don't understand this post. Was it an ad for Appeon? Was there a question?
>
> --
> Dean Jones
> CEO
> PowerObjectshttp://www.powerobjects.com
> (612) 339-3355 Ext. 112
>
> TeamSybase
> * * Think Sybase * *
>
> <vlad.vladu...@gmail.com> wrote in messagenews:1165170525.608125.251660@73g2000cwn.googlegroups.com...
>
> > Here is an ordinary day in the IT department of a big company. Boss
> > says: "Hey, Jack, we have a new application. Is written in
> > PowerBuilder and is has to be installed on all our 300 workstations
> > !". "Great, says Jack. Another pain in the ass. Last month was a
> > Java Swing application, three months ago was a Visual Basic... And I
> > have to do all the work. Damn, I think I am gonna switch to a taxi
> > driver job !".
> > Swell, isn't it ? Well, there are a few techniques to improve the
> > installation procedure of a classic two tier application, but why not
> > solve the problem from it's root ? "Hey, Jack, we have the solution
> > !", we say to poor Jack. "Ah, yes, I know, web applications of
> > course. Workstations only have to have a browser. But man, they are so
> > clumsy ! They are slow and not easy to develop. And it's stupid to
> > use internet technologies inside a LAN. And the users always complain
> > about graphical interface. And you know how it is when end users
> > complain about graphical interface !", says Jack, showing his teeth.
> > We smile condescendingly. We have a better solution.
>
> > Why not have them all ? Why not combine the best parts from both worlds
> > ? This is what we propose now: a Universal Applications Platform. It is
> > a "thing" that will allow LAN applications to be installed on a
> > sever and to be accessed from a sort of browser, just like web
> > applications, but the speed will be just like in 2-tier applications.
> > And they will be easy to develop, with a RAD IDE. And the beauty of the
> > interface will make women cry.
>
> > Now seriously. Here is the idea: in a web application, we have a data
> > server which holds data, an application server which performs business
> > computation and a web server which presents the data to its client -
> > the web browser. This is good for an internet application, no doubt
> > about it. But...
> > There are not many organizations who run web applications, compared to
> > those which have classic 2-tier applications running. The need for this
> > kind of applications was and will continue to be HUGE !
> > That is why we think it worth to develop a cool mechanism for LAN
> > applications. It will be similar to normal browser-HTTP-web server
> > mechanism, only the browser will be more cool, the protocol will be
> > heavier (since data will not have to swim across the Internet ocean),
> > faster and more powerful in order to achieve the performance of a
> > 2-tier system. Instead of a web server there will be a "presentation
> > server", which will generate the "view" part (as in MVC pattern)
> > and will deliver it to its cool browser.
>
> > Now let's put all the pieces together. We have:
> > - a data layer which, by the way, would be nice to be obiectual instead
> > of relational;
> > - a business layer;
> > - a presentation layer: this would be one of the four parts of our cool
> > mechanism;
> > - a connection & deliver manager - the second part of our cool
> > mechanism;
> > - a cool protocol for local area network communication - the third part
> > of our cool mechanism;
> > - a cool "browser" used to access the applications on the server:
> > the final piece.
>
> > The presentation layer: this layer will generate the visual format of
> > the data to be displayed to the end user. This layer will have to
> > overcome the limitations of the HTML/CSS/JavaScript/AJAX and to provide
> > a native-like interface and joy of living to end-users.
> > The connection & delivery manager: this will be something like a web
> > server. It will manage connections and will deliver the requested
> > content to each client.
> > The protocol for local area network communication: this will not be
> > stateless like HTTP, it will be specially designed for LAN
> > communication, for easy development and also for the performance needed
> > by enterprise class applications. The communication could also be done
> > by messages like in the old PeopleSoft architecture.
> > The "Browser", or maybe is better to call it "executer": this
> > will be platform dependent. It will receive from the presentation layer
> > a "description" of the page to be displayed and will build/render
> > the page based on the underlying operating system capabilities. That
> > description will contain both the structure of the page and the data.
>
> > The four layers - data, business, presentation layers and the
> > connection manager - may be part of the same server program if best
> > performance is desired, or they can be different programs, as they are
> > now in web applications. The business layer could be represented by a
> > stored procedures engine inside the data server, or it can be a regular
> > J2EE server. The cool browser can be a regular browser updated to
> > support the new cool protocol, but it better be totally new.
>
> > Of course this new devices will have to be widely accepted and become a
> > de-facto industry standard, otherwise the goal of Universal Platform
> > will not be achieved.
>
> > A few words about terminal software solution. We do not like this
> > solution because this software is complicated and the network traffic
> > increases unacceptably. And a word about applets: it is not a bad idea,
> > still there is place for serious improvement. And Flash ? Not bad.
>
> > This was my idea. I hope you like it. If not, let forgotness lay above
> > it...