Thanks Henrik and Alex,

This came in my email this morning: "

It seems to me that the easiest way to overcome server volume(1)
limitations ("";), is by executing a much as
possible on the client. See also: "";.
(Disclosure: my at work architecture is Oracle/Microsoft SQL Server and
net. Sometimes General Interface is the UI.)

I will create, and share, some (HTML5 and/or General Interface and/or
TiddlyWiki)+PicoLisp examples; hopefully soon.(2)

Alex, thanks for pointing me to: ""; and "";. Do you use this for testing; or,
for production?



(1) Not that I have this problem (no volume, ha ha).
(2) A non PicoLisp experiment:

On Mon, Jan 6, 2014 at 2:19 AM, Alexander Burger <>wrote:

> Hi Rick,
> a Happy New Year to you too! And to everybody else, of course! :)
> And thanks for the feedback and links.
> > I have mixed feelings about: "this would break the fundamental rule that
> > the GUI should also work in an environment without JavaScript"
> >
> > It seems contrary to what most companies are pursuing, e.g.: "
> >";
> Sure, that's true. And in fact we are currently also using Phonegap and
> fries.js in the same project.
> Still it is an important feature for me if an application works _also_
> without JavaScript and cookies, running in plain text browsers or
> scrape-script-driven, without any limits to handicapped persons (screen
> readers) or in otherwise restricted environments. Another gain is
> performance because of the lightweight.
> > Under Windows I have used nodeJS so that localhost can query PicoLisp,
> in a
> > psuedo RESTful manner (i.e., no app session...)
> Yes, and you can use PicoLisp in that way also in the standard setup. I
> do this for simple static pages.
> But I strongly disagree in non-trivial cases. The session-oriented
> protocol of a PicoLisp app is a must for me. A stateless paradigm like
> REST (keeping the state in the client instead of the server) would IMHO
> be by far inferior for the kind of applications I'm dealing with. As a
> matter of principle some state must be hold in the database on the
> server, and therefore also most decisions concerning the flow, so
> delegating some part of the state to the client gives a very unmodular
> program structure.
> ♪♫ Alex
> --

Reply via email to