In comp.lang.java.advocacy, Roedy Green
<see_website@[EMAIL PROTECTED]
>
wrote
on Fri, 23 Nov 2007 12:12:31 GMT
<gpgdk3p73t1l3u7s1gjlcph7smtegtkcck@[EMAIL PROTECTED]
>:
> On Thu, 22 Nov 2007 13:27:26 -0800, The Ghost In The Machine
> <ewill@[EMAIL PROTECTED]
> wrote, quoted or indirectly quoted
> someone who said :
>
>>
>>HTTP already has a caching mechanism. What visuals are you discussing?
>>HTML is always rendered locally.
>
> caching works on a page level. I am thinking more of a client side
> program that composes pages out of elements. Now we cache images, but
> I would like to cache any slowly changing parts of pages
> independently.
>
> Imagine if there were no HTML, just Applets that gather raw binary
> data from the hosts to display. This gives the direction I want to
> head.
>
One could contemplate an odd mix here. The framework would
be specified as a high-level page, which would detail what
webwidgets to load -- something along the lines of the
output of glade-3. (It is possible a separate sheet would
detail placement and style, or placement and style would
be specified by the user once the main page is loaded;
the user interface would simply have the user click,
drag, and drop. Note that glade-3 assumes GTK, which is
not web-capable.)
The webwidgets proper might be loaded from a central
server, or a designated distributor thereof. The main
page would also configure the webwidgets, to allow for
flexibility; among other things, the webwidgets can be
told from where to load their data (think RSS feeds for
one example). Webwidgets might also load no data (e.g.,
a clock widget).
Webwidgets can edit the page by adding or removing themselves
or other webwidgets, and reconfiguring them.
Note that this is close to AJAX, but not quite; AJAX does
not do webwidgets but does allow Javascript to edit the HTML
after loading server instructions.
--
#191, ewill3@[EMAIL PROTECTED]
was an optimist.
--
Posted via a free Usenet account from http://www.teranews.com
|
