Home » Eclipse Projects » Technology Project and PMC » Use Eclipse as new generation web browser
|
| Re: Use Eclipse as new generation web browser [message #22042 is a reply to message #21997] |
Sun, 08 September 2002 22:34   |
Eclipse User |
|
|
|
Originally posted by: sg.media.-style.com
> One possibility could (why not) to use the eclipse framework as a new
> generation of web browser. A web browser is not obligatory a html
I'm not sure what you mean with the xml section. But i think the idea is a
good one.
I see a project that write a email client in eclipse. I see a project that
share tasks in a team, I see a project that show news in eclipse. and so
on..
I think a all in one tool, where you have only deploy a plugin, is the dream
of every administrator fighting with more than 10 office clerks machines.
And how wunderfull it system independent.
Anyways a browser that support advanced "internet services" is too useful
and the sucess story of opera show there is a market.
bye
|
|
|
| Re: Use Eclipse as new generation web browser [message #22086 is a reply to message #22042] |
Mon, 09 September 2002 06:19 |
 Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
Thanks Stephan for your comment..
What I mean in the "xml section" was simply to say that in a classical web
browser the presentation format is HTML. Maybe we can consider HTML a
little bit old from now to express all the developper needs. Instead of
using HTML we could define another format (extension of the xml format
used in the eclipse plugin development, XUL, or another one...) which will
be understand by the eclipse framework and send by a web server as answer
to net request like today with HTML... The advantage should be to be able
to define more complex api in aclient/server application, to allow more
complex ans structured controls in the client side, and to benefit of all
eclipse features too.
Obviously, the goal is not to replace classical web browsers, but to
enable the developper to create intranet or extranet applications easily
and efficiently without having to make the major controls on the server
side or to use javascripts components to make such things like listView,
panedWindows, toolbars, and so on...
regards
Xavier
Stefan Groschupf wrote:
> > One possibility could (why not) to use the eclipse framework as a new
> > generation of web browser. A web browser is not obligatory a html
> I'm not sure what you mean with the xml section. But i think the idea is a
> good one.
> I see a project that write a email client in eclipse. I see a project that
> share tasks in a team, I see a project that show news in eclipse. and so
> on..
> I think a all in one tool, where you have only deploy a plugin, is the dream
> of every administrator fighting with more than 10 office clerks machines.
> And how wunderfull it system independent.
> Anyways a browser that support advanced "internet services" is too useful
> and the sucess story of opera show there is a market.
> bye
|
|
|
| Eclipse and Design Patterns [message #22130 is a reply to message #21997] |
Mon, 09 September 2002 07:34 |
| Eclipse User |
|
|
|
Originally posted by: asimionoiu.attbi.com
What about writing a plugin for generating code based on design patterns ?.
I think that TogetherJ has something like this.
Maybe somebody already wrote it and I didn't find it.
/Alin
|
|
|
| Re: Eclipse and Design Patterns [message #22218 is a reply to message #22130] |
Mon, 09 September 2002 09:27 |
| Eclipse User |
|
|
|
Originally posted by: guehene.info.emn.fr
Hello Alin!
We develop, at the Ecole des Mines de Nantes, a tool for the description
and the manipulation of design patterns ("Solution" element from the GoF).
This tool is called PatternsBox (http://www.emn.fr/albin/patternbox.html).
In particular, from a description of a design pattern, PatternsBox can
generate the corresponding source code (either as an example of the design
pattern structure and static behavior or parameterized, to fit in a
particular context). We are currently working on an Eclipse-based and
enhanced version of PatternsBox.
We welcome any feedback (and participation ;-)
Regards,
Herv
|
|
|
| Re: Use Eclipse as new generation web browser [message #22324 is a reply to message #21997] |
Mon, 09 September 2002 11:05 |
| Eclipse User |
|
|
|
Originally posted by: Bram.Stieperaere.REMOVEskynet.be
Xavier,
I think that is a terrific idea, (I had it also :-) )
Reinventing the wheel would of course be stupid. So I would say: forget
about HTML, let's make instead something that is usefull for serving dynamic
content over the internet. I always found a browser interface a step back
qua user friendliness and efficiency if you compare it with a "classic"
fat-client interface.
Why not make something that has the best of both worlds:
- a GUI made of native widgets, with all functionality like dnd, MDI,
tabpages, custom controls
- but web-enabled,
The problem with HTML is you mix markup, layout and data. Also you have to
go back to the server each time you want to show a new page (imagine e.g. a
form that spans 2 tabpages, or two screens with a master-detail relation)
This results in a lot of extra traffic that can be avoided in custom GUI
applications. Also programming simple GUI scenarios like MDI , tabpages,
menus, master-detail, input verification are quite elabarous to implement
and typically require a mix of servlet programming, client scripting,
getting the browser to cough up the right URL. let's not even start about
backbuttons and other nightmares with keeping a correct application state.
Now, consider the following architecture.
- The client has a repository of beans (widgets). Each bean has a
descriptor. Let's say the basic set is the set of SWT widgets, wrapped in
some beans.
- The user does an action which result in a form being requested. The server
responds with
- an XML describing the form. This could be e.g. a XUL document. It
describes the set of beans that are needed to build up the form, how they
are hierarchically composed, wat the attributes are (size, colour, etc...).
The XUL document is used as an instruction by a form building component in
the client to create the form and present it to the user.
- an XML with the data of the form
- an XML with a mapping between the data and the form.
The protocol could have several optimizations and enhancements:
- the form XML and mapping XML could be cached. The protocol could foresee
in a mechanism to check whether a version in the client cache is still up to
date.
- layout and markup coulb be separated using XSL. The responsability of XSL
processing could be negotiated between server and client. (a more powerfull
- the data XML could span multiple screens. So, the user consults/edits 1
document spanning multiple screens using only 1 data XML request.
- HTML is scriptable (javascript etc...). However, the bulk of javascript
sent with a HTML page fall in two categories: input validation and
disabling/enabling
controls as a response to some input from the user. The (mapping?) XML
should contain instructions for these.
- user preferences (persisted personalisation)
- security model (login, user profiles, access control)
- installing / upgrading via webstart-like mechanism. installing new
(custom) cotrols on the fly
I found a product once that did about this. But it was in the pre-SWT days,
and also XML protocols and XSL where not so established at that time. I
would really like to see an application with this architecture written in
SWT and JFace.
my 2 EUR c,
Bram
"xavier" <xmehaut@apri-group.com> wrote in message
news:algbl7$qsu$1@rogue.oti.com...
> Hello,
> My idea is maybe totally stupid but I nevertheless write it here ;-)
> It seems that we try to build more and more n-tier applications which
> mimics rich-client applications. So many frameworks appeared which try to
> mask the lacks inherently found in the current web model : struts, JFaces,
> ASPx, and so on... Maybe we should try to attack the pb at its roots, ie
> to enhance the client browser to be richer in functionnalities than today,
> especially the kinds of available components, the ability to make controls
> in an easier manner on the client and in more structured way, and so on...
> One possibility could (why not) to use the eclipse framework as a new
> generation of web browser. A web browser is not obligatory a html
> browser!!! We could extend the plugin.xml format (or another one) to
> provide the user with more components. This format should be used by the
> server which would send commands in this format to the client which could
> interpret it in the eclipse framework. So we would have a means to program
> more sophisticated applications with the web philosophy...and it should be
> simpler to program and maintain than in the newt generation of frameworks
> in java or dotNet.
> regards
> Xavier
>
|
|
|
| Re: Use Eclipse as new generation web browser [message #22349 is a reply to message #22324] |
Mon, 09 September 2002 12:06 |
| Eclipse User |
|
|
|
Originally posted by: Bram.Stieperaere.REMOVEskynet.be
> The protocol could have several optimizations and enhancements:
> - the form XML and mapping XML could be cached. The protocol could
foresee
> in a mechanism to check whether a version in the client cache is still up
to
> date.
taking this even further: the forms accesible from the current could be
proactively build into the background.
> - HTML is scriptable (javascript etc...). However, the bulk of javascript
> sent with a HTML page fall in two categories: input validation and
> disabling/enabling
> controls as a response to some input from the user. The (mapping?) XML
2 additional remarks here.
- XSD has very enhanced type checking constructs.
- client side scripting should be "easy". The form XML provides a good DOM,
and bean scripting
exists (even in Eclipse if I recall well). I also heard of jython, AFAIK it
is a python to java bridge that supports bean scripting.
Anyone has an idea how these could fit in this picture?
> - user preferences (persisted personalisation)
built in multilingual support
|
|
| | |
| Re: Use Eclipse as new generation web browser [message #22577 is a reply to message #22491] |
Mon, 09 September 2002 15:44 |
| Eclipse User |
|
|
|
Originally posted by: Bram.Stieperaere.REMOVEskynet.be
Thomas,
the title of the postings of xavier (new generation web browser) is a bit
misleading if you read what he posts as "requirements" for this new type of
browser: n-tier, support intranet/extranet applications, replace HTML with
XUL-like content and rich controls, etc.. That's not a browser as we know
it today I think, but more like a web-enabled generic client which allows to
handle data in XML format and present them using a rich control set.
> intentions. Anyway - remember that the main benefit of using HTTP and
> browsers to serve a GUI is that literally everyone can access the
> application without installing a dedicated client.
good point. There is of course webstart etc.. So it could run on top of the
browser using the java plugin (i've seen on the wiki that it is possible to
webstart SWT app's ) Given the fact that this kind of framework would only
be usefull for intarnet/extranet apps, we could "afford" a one time download
of the framework (generic client)
Xavier, could you maybe specify a bit more precise what you envisioned?
Bram
"Thomas Jachmann" <thomas.jachmann@mindmatters.de> wrote in message
news:ali91c$jp3$1@rogue.oti.com...
> I definitely don't want to kill your enthusiasm; just notice that all
these
> thoughts lead you away from what the subject tells - building a new
> generation web browser. What you try to do is building an application
> framework for n-tier applications with semi-thin clients. I think there
are
> quite a few of such frameworks around, although I see the benefits of
> implementing one on top of eclipse quite well. Let alone the well known
> deficiencies of HTTP since it is stateless. So I clearly understand your
> intentions. Anyway - remember that the main benefit of using HTTP and
> browsers to serve a GUI is that literally everyone can access the
> application without installing a dedicated client.
>
> Regards,
> Thomas
>
>
|
|
| |
| Re: Use Eclipse as new generation web browser [message #22840 is a reply to message #22750] |
Mon, 09 September 2002 22:19 |
| Eclipse User |
|
|
|
Originally posted by: ecuellar.crosslogic.com
Bram Stieperaere wrote:
> Just founfd this on javalobby:
> http://swingml.sourceforge.net
> Bram
Thanks Bram for inviting me to this discussion.
I haven't had the time yet to go through all the previous posts so I will
focus this time only in SwingML.
The main information about SwingML can be found at the link listed above
(http://swingml.sourceforge.net) so I'll mention some informal details
about it.
The SwingML (Swing Markup Language) project is going after an alternative
to replace COMPLETELY the use of HTML in the creation of Web based
businees apps.
I'm not considering it to be intended to be used in J2ME yet.
Personally I like best the idea of creating a new specification, first of
all because I want it to be more readable than XUL and UIML and then
because I want it to be Swing specific so a person with good HTML and
Swing background can have an easy transition to it. Currently you can
download the SwingML applet Renderer and start creating web app prototypes
inmediately.
Bram said that the specification is mixing the data with the view just
like HTML. I totally agree. Basically my intention is that this separation
can be achieved in the server side component using a technology like XSLT.
The SwingML project a few months old and it currently has one developer
(me). So I'm in the process of recruiting people who would like to
contribute.
All comments are welcome.
Ezequiel
|
|
|
| Re: Use Eclipse as new generation web browser [message #22883 is a reply to message #22577] |
Tue, 10 September 2002 06:53 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
What I envisionned? I can't thing that I've envisionned anything ;-) As I
said , i think it could be very good to use the eclipse framework as a
browser not interpreting html returned by the HTTP server, but to
interpret eclipse XML format returned by this http server too... The
eclipse platform used should be as light as possible to be able to
download it easily and quickly on each platform (or maybe even as a ie ot
netscape plugin), and its task should be to interpret and build GUI from
data given by the server, and to make simple controls directly in the
client side (obviously eclipse should be used in client side, even if we
can envisage to be able to make communicate eclipse clients between
themselves directly by useing the server as bridge). We could also extend
the server principle which today interact with a client only on client
request. The server could also run in push mode to for instance regurlarly
the client by pushing toward it some data (for instance news, ...)
so it is a preliminary discussion... I thnik it is quite a lot of work to
achieve such a goal... I don"t know yet if it needed or if people can work
together to achieve such a goal...
regards
xavier
Bram Stieperaere wrote:
> Thomas,
> the title of the postings of xavier (new generation web browser) is a bit
> misleading if you read what he posts as "requirements" for this new type of
> browser: n-tier, support intranet/extranet applications, replace HTML with
> XUL-like content and rich controls, etc.. That's not a browser as we know
> it today I think, but more like a web-enabled generic client which allows to
> handle data in XML format and present them using a rich control set.
> > intentions. Anyway - remember that the main benefit of using HTTP and
> > browsers to serve a GUI is that literally everyone can access the
> > application without installing a dedicated client.
> good point. There is of course webstart etc.. So it could run on top of the
> browser using the java plugin (i've seen on the wiki that it is possible to
> webstart SWT app's ) Given the fact that this kind of framework would only
> be usefull for intarnet/extranet apps, we could "afford" a one time download
> of the framework (generic client)
> Xavier, could you maybe specify a bit more precise what you envisioned?
> Bram
> "Thomas Jachmann" <thomas.jachmann@mindmatters.de> wrote in message
> news:ali91c$jp3$1@rogue.oti.com...
> > I definitely don't want to kill your enthusiasm; just notice that all
> these
> > thoughts lead you away from what the subject tells - building a new
> > generation web browser. What you try to do is building an application
> > framework for n-tier applications with semi-thin clients. I think there
> are
> > quite a few of such frameworks around, although I see the benefits of
> > implementing one on top of eclipse quite well. Let alone the well known
> > deficiencies of HTTP since it is stateless. So I clearly understand your
> > intentions. Anyway - remember that the main benefit of using HTTP and
> > browsers to serve a GUI is that literally everyone can access the
> > application without installing a dedicated client.
> >
> > Regards,
> > Thomas
> >
> >
|
|
| | | |
| Re: Use Eclipse as new generation web browser [message #575846 is a reply to message #22042] |
Mon, 09 September 2002 06:19 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
Thanks Stephan for your comment..
What I mean in the "xml section" was simply to say that in a classical web
browser the presentation format is HTML. Maybe we can consider HTML a
little bit old from now to express all the developper needs. Instead of
using HTML we could define another format (extension of the xml format
used in the eclipse plugin development, XUL, or another one...) which will
be understand by the eclipse framework and send by a web server as answer
to net request like today with HTML... The advantage should be to be able
to define more complex api in aclient/server application, to allow more
complex ans structured controls in the client side, and to benefit of all
eclipse features too.
Obviously, the goal is not to replace classical web browsers, but to
enable the developper to create intranet or extranet applications easily
and efficiently without having to make the major controls on the server
side or to use javascripts components to make such things like listView,
panedWindows, toolbars, and so on...
regards
Xavier
Stefan Groschupf wrote:
> > One possibility could (why not) to use the eclipse framework as a new
> > generation of web browser. A web browser is not obligatory a html
> I'm not sure what you mean with the xml section. But i think the idea is a
> good one.
> I see a project that write a email client in eclipse. I see a project that
> share tasks in a team, I see a project that show news in eclipse. and so
> on..
> I think a all in one tool, where you have only deploy a plugin, is the dream
> of every administrator fighting with more than 10 office clerks machines.
> And how wunderfull it system independent.
> Anyways a browser that support advanced "internet services" is too useful
> and the sucess story of opera show there is a market.
> bye
|
|
| |
| Re: Eclipse and Design Patterns [message #575934 is a reply to message #22130] |
Mon, 09 September 2002 09:27 |
| Eclipse User |
|
|
|
Originally posted by: guehene.info.emn.fr
Hello Alin!
We develop, at the Ecole des Mines de Nantes, a tool for the description
and the manipulation of design patterns ("Solution" element from the GoF).
This tool is called PatternsBox (http://www.emn.fr/albin/patternbox.html).
In particular, from a description of a design pattern, PatternsBox can
generate the corresponding source code (either as an example of the design
pattern structure and static behavior or parameterized, to fit in a
particular context). We are currently working on an Eclipse-based and
enhanced version of PatternsBox.
We welcome any feedback (and participation ;-)
Regards,
Herv
|
|
|
| Re: Use Eclipse as new generation web browser [message #576022 is a reply to message #21997] |
Mon, 09 September 2002 11:05 |
Bram Stieperaere
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Xavier,
I think that is a terrific idea, (I had it also :-) )
Reinventing the wheel would of course be stupid. So I would say: forget
about HTML, let's make instead something that is usefull for serving dynamic
content over the internet. I always found a browser interface a step back
qua user friendliness and efficiency if you compare it with a "classic"
fat-client interface.
Why not make something that has the best of both worlds:
- a GUI made of native widgets, with all functionality like dnd, MDI,
tabpages, custom controls
- but web-enabled,
The problem with HTML is you mix markup, layout and data. Also you have to
go back to the server each time you want to show a new page (imagine e.g. a
form that spans 2 tabpages, or two screens with a master-detail relation)
This results in a lot of extra traffic that can be avoided in custom GUI
applications. Also programming simple GUI scenarios like MDI , tabpages,
menus, master-detail, input verification are quite elabarous to implement
and typically require a mix of servlet programming, client scripting,
getting the browser to cough up the right URL. let's not even start about
backbuttons and other nightmares with keeping a correct application state.
Now, consider the following architecture.
- The client has a repository of beans (widgets). Each bean has a
descriptor. Let's say the basic set is the set of SWT widgets, wrapped in
some beans.
- The user does an action which result in a form being requested. The server
responds with
- an XML describing the form. This could be e.g. a XUL document. It
describes the set of beans that are needed to build up the form, how they
are hierarchically composed, wat the attributes are (size, colour, etc...).
The XUL document is used as an instruction by a form building component in
the client to create the form and present it to the user.
- an XML with the data of the form
- an XML with a mapping between the data and the form.
The protocol could have several optimizations and enhancements:
- the form XML and mapping XML could be cached. The protocol could foresee
in a mechanism to check whether a version in the client cache is still up to
date.
- layout and markup coulb be separated using XSL. The responsability of XSL
processing could be negotiated between server and client. (a more powerfull
- the data XML could span multiple screens. So, the user consults/edits 1
document spanning multiple screens using only 1 data XML request.
- HTML is scriptable (javascript etc...). However, the bulk of javascript
sent with a HTML page fall in two categories: input validation and
disabling/enabling
controls as a response to some input from the user. The (mapping?) XML
should contain instructions for these.
- user preferences (persisted personalisation)
- security model (login, user profiles, access control)
- installing / upgrading via webstart-like mechanism. installing new
(custom) cotrols on the fly
I found a product once that did about this. But it was in the pre-SWT days,
and also XML protocols and XSL where not so established at that time. I
would really like to see an application with this architecture written in
SWT and JFace.
my 2 EUR c,
Bram
"xavier" <xmehaut@apri-group.com> wrote in message
news:algbl7$qsu$1@rogue.oti.com...
> Hello,
> My idea is maybe totally stupid but I nevertheless write it here ;-)
> It seems that we try to build more and more n-tier applications which
> mimics rich-client applications. So many frameworks appeared which try to
> mask the lacks inherently found in the current web model : struts, JFaces,
> ASPx, and so on... Maybe we should try to attack the pb at its roots, ie
> to enhance the client browser to be richer in functionnalities than today,
> especially the kinds of available components, the ability to make controls
> in an easier manner on the client and in more structured way, and so on...
> One possibility could (why not) to use the eclipse framework as a new
> generation of web browser. A web browser is not obligatory a html
> browser!!! We could extend the plugin.xml format (or another one) to
> provide the user with more components. This format should be used by the
> server which would send commands in this format to the client which could
> interpret it in the eclipse framework. So we would have a means to program
> more sophisticated applications with the web philosophy...and it should be
> simpler to program and maintain than in the newt generation of frameworks
> in java or dotNet.
> regards
> Xavier
>
|
|
| | | |
| Re: Use Eclipse as new generation web browser [message #576233 is a reply to message #22491] |
Mon, 09 September 2002 15:44 |
Bram Stieperaere
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Thomas,
the title of the postings of xavier (new generation web browser) is a bit
misleading if you read what he posts as "requirements" for this new type of
browser: n-tier, support intranet/extranet applications, replace HTML with
XUL-like content and rich controls, etc.. That's not a browser as we know
it today I think, but more like a web-enabled generic client which allows to
handle data in XML format and present them using a rich control set.
> intentions. Anyway - remember that the main benefit of using HTTP and
> browsers to serve a GUI is that literally everyone can access the
> application without installing a dedicated client.
good point. There is of course webstart etc.. So it could run on top of the
browser using the java plugin (i've seen on the wiki that it is possible to
webstart SWT app's ) Given the fact that this kind of framework would only
be usefull for intarnet/extranet apps, we could "afford" a one time download
of the framework (generic client)
Xavier, could you maybe specify a bit more precise what you envisioned?
Bram
"Thomas Jachmann" <thomas.jachmann@mindmatters.de> wrote in message
news:ali91c$jp3$1@rogue.oti.com...
> I definitely don't want to kill your enthusiasm; just notice that all
these
> thoughts lead you away from what the subject tells - building a new
> generation web browser. What you try to do is building an application
> framework for n-tier applications with semi-thin clients. I think there
are
> quite a few of such frameworks around, although I see the benefits of
> implementing one on top of eclipse quite well. Let alone the well known
> deficiencies of HTTP since it is stateless. So I clearly understand your
> intentions. Anyway - remember that the main benefit of using HTTP and
> browsers to serve a GUI is that literally everyone can access the
> application without installing a dedicated client.
>
> Regards,
> Thomas
>
>
|
|
| | |
| Re: Use Eclipse as new generation web browser [message #576478 is a reply to message #22577] |
Tue, 10 September 2002 06:53 |
Xavier Méhaut
Messages: 49
Registered: July 2009 |
Member |
|
|
What I envisionned? I can't thing that I've envisionned anything ;-) As I
said , i think it could be very good to use the eclipse framework as a
browser not interpreting html returned by the HTTP server, but to
interpret eclipse XML format returned by this http server too... The
eclipse platform used should be as light as possible to be able to
download it easily and quickly on each platform (or maybe even as a ie ot
netscape plugin), and its task should be to interpret and build GUI from
data given by the server, and to make simple controls directly in the
client side (obviously eclipse should be used in client side, even if we
can envisage to be able to make communicate eclipse clients between
themselves directly by useing the server as bridge). We could also extend
the server principle which today interact with a client only on client
request. The server could also run in push mode to for instance regurlarly
the client by pushing toward it some data (for instance news, ...)
so it is a preliminary discussion... I thnik it is quite a lot of work to
achieve such a goal... I don"t know yet if it needed or if people can work
together to achieve such a goal...
regards
xavier
Bram Stieperaere wrote:
> Thomas,
> the title of the postings of xavier (new generation web browser) is a bit
> misleading if you read what he posts as "requirements" for this new type of
> browser: n-tier, support intranet/extranet applications, replace HTML with
> XUL-like content and rich controls, etc.. That's not a browser as we know
> it today I think, but more like a web-enabled generic client which allows to
> handle data in XML format and present them using a rich control set.
> > intentions. Anyway - remember that the main benefit of using HTTP and
> > browsers to serve a GUI is that literally everyone can access the
> > application without installing a dedicated client.
> good point. There is of course webstart etc.. So it could run on top of the
> browser using the java plugin (i've seen on the wiki that it is possible to
> webstart SWT app's ) Given the fact that this kind of framework would only
> be usefull for intarnet/extranet apps, we could "afford" a one time download
> of the framework (generic client)
> Xavier, could you maybe specify a bit more precise what you envisioned?
> Bram
> "Thomas Jachmann" <thomas.jachmann@mindmatters.de> wrote in message
> news:ali91c$jp3$1@rogue.oti.com...
> > I definitely don't want to kill your enthusiasm; just notice that all
> these
> > thoughts lead you away from what the subject tells - building a new
> > generation web browser. What you try to do is building an application
> > framework for n-tier applications with semi-thin clients. I think there
> are
> > quite a few of such frameworks around, although I see the benefits of
> > implementing one on top of eclipse quite well. Let alone the well known
> > deficiencies of HTTP since it is stateless. So I clearly understand your
> > intentions. Anyway - remember that the main benefit of using HTTP and
> > browsers to serve a GUI is that literally everyone can access the
> > application without installing a dedicated client.
> >
> > Regards,
> > Thomas
> >
> >
|
|
| | |
Goto Forum:
Current Time: Sat Nov 09 03:21:19 GMT 2024
Powered by FUDForum. Page generated in 0.06025 seconds |
] 
Search
Help
Register
Login
Home
