On Mon, Jan 6, 2014 at 10:15 AM, Rick Lyman <lyman.r...@gmail.com> wrote:
> 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 ("http://www.kegel.com/c10k.html"), is by executing a much as
> possible on the client. See also: "http://www.generalinterface.org/".
> (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: "http://getfri.es/" and "
> https://github.com/jaunesarmiento/fries". 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: http://ricklyman.net/gi4.html
> On Mon, Jan 6, 2014 at 2:19 AM, Alexander Burger <a...@software-lab.de>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
>> > It seems contrary to what most companies are pursuing, e.g.: "
>> > http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story"
>> 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_
>> 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
>> UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe