Re: UI, Lisp, CLOS, MVC, design

On Wed, 2008-10-29 at 12:38 +0100, Lars Rune Nøstdal wrote:
On Wed, 2008-10-29 at 10:37 +0000, Marek Kubica wrote:
On Tue, 28 Oct 2008 10:45:45 -0700, Lars Rune Nøstdal wrote:

On Oct 28, 1:32 am, Marek Kubica <ma...@xxxxxxxxxxxxxxxx> wrote:
On Mon, 27 Oct 2008 03:19:40 +0100, Lars Rune Nøstdal wrote:
How do I install it?

How can I login? Why is it sending my passwords in clear text? Whats
this cookie thing?

HTTPS. Cookies and JS is enabled by default; if the user has disabled
(read: directly and knowingly) these things, I can detect this and
inform the user (and/or me).

But most apps don't bother, because it puts quite a load on the server.
Encrypted connections are more or less standard now, see SMTP+TLS, IMAP
+TLS and Jabber (which usually is encrypted per default). On the other
hand, when I type in some Web2.0 thingie and add a https before it, I
mostly get nothing to see.

Yeah, of course -- but it's there; it's up to me, the developer, to use
it. It's not like a C based client in Gtk+ can be written in a sloppy
way also.

...agh .. i meant "can't" .. i think; blah, tired.. :P




How do you distribute it? How do you distribude updates?

Point taken. How about XSS, CSRF, clickforging?

Not impossible to solve or deal with.

Most Web2.0 things don't and preventing this is quite a bit of work which
makes programming for the web which was once trivial pretty hard. And
then there might be new techniques that can be exploited, so you always
have to keep up with your app.

Yeah, good thing I don't have to worry about distributing upgrades etc.
then.


What happens to my config/settings etc. when I buy a new computer?

What happens to my data if the provide disappears?

General problem; the same thing applies to a client written in Gtk+, but
see what I write about running a HTTP-server on LAN/localhost below.

Local backups are possible and trivial. Even Apple ships a backup
solution as a part of their OS. Backupping online data only easy for the
provider, if you want to have an offsite-backup of your stuff, you need
to write a program which scrapes out your data and saves it.

PostgreSQL dump .. done.


Not that many people would bother anyway, but I believe data safety is still
important.

The combination web/browser (presentation/UI) and HTTP (communication)
is the only thing that has:

* Basically 99.9% (or so) ubiquity: IE6+(Windows), FF2+(Linux)
and Mac(Safari). I think the 0.1% missing is _way_ less
missing
coverage "globally" than anything based on, say, Gtk+ or Qt
-
_when_ combined with the points below. Aiming for the
largest
coverage (first) makes sense in so many ways.

Depends on what you write.

Sure.



* 0 install required. Show me anything else that allows me to
scribble down an 8 letter word (URL) on a post-it note and
invite the world (all 99.9% of it) _instantly_ and combine
this with
the other points. This, is real power - it has significance;
it
allows anyone and everyone to participate. People with low
technical skills (or low on time/patience there) can be very
strong in other areas.

Package managers are easy to use too, last time I looked installing a
Ubuntu package needed only some clicks which are no harder than clicking
on stuff on a web site to register.

* 100% real-time, full two-way/duplex (yes, really - I'm doing
this; no plugins), through all router/firewall/NAT thingies
--
with _no_ trouble. Globally(#2).

Two-way duplex with COMET is a toy, polling is just a bad joke. Been
there, tried that.

Nah, it works great. I don't care what ("you") people say about this
anymore at all 'cause I've heard it all before.

What matters is not the opinion of you "tech-people" with mental
barriers unable to see through even a _single_ layer of
abstraction/indirection (often, it seems, in both low- and high-level
areas!) to reach a goal; "it's not a _real_ socket" -- and that's the
end of that (for you).

What matters, is the result; and it works great. It is stable, reliable,
leads to very low latency -- and scalability is very good. My
non-threaded backend (epoll-based) scales to 10000++ concurrent
sessions/clients with _no_ trouble at all.

Toy? I think not. Go play with your Qt/Gtk+ toy-client in C. :)


For saving data from local applications one can also
use HTTP, see XML-RPC or plain old POST-ing of data to some remote
location.

Yeah, of course.


The user can, if he _really_ needs to, run a server on his LAN or even
on localhost (say, his laptop).

Sure, but where does he get the server from? Most web sites don't provide
sources,

This isn't about "them"; it's about what you or me would or could
do. ..heh.

You gotta think outside of the box here; it's impossible to explain
otherwise. Maybe you understand already though.


they don't need to and if they would, that might split the
community because it is centralized on one instance of the server.

Sure; that might be something they/I/we want. Same thing applies to any
client/server scenario here.


Interoperability with other instances is not built-in.

Uh, providing a text-input with a "Connect to new host:" label is not
impossible.


Most code is not AGPL-licensed, which would force people to publish their code (I'll leave
it up to the reader to decide whether this is good or bad).

Actually, it is the opposite; AGPL is what forces people to publish the
code of their networked applications.

...just ignore me.. lol


People have a tendency to think; server == some closed "Google thing" on
the "other end", but this is just a mental barrier. A "server" really is
just software(#1) also; it can run, right here. It's not impossible.
CLISP is quite portable (Win32) and it has a small overhead.

See, CLISP is portable so are other languages. So why not write the app
in CLISP/portable language? There are many and performance is *usually*
enough (most of the time better than with JS).

Because, the coverage wrt. targeting a browser is _huge_, _immense_ ..
compared to hoping the user will bother installing a custom client.

Even businesses seem to strongly prefer web-based clients these days.
(This might just be me of course; I pay more attention to this part of
the industry. )


While Ido agree that for some things it might be useful, I look around
and see what I and other people use (to get instantly in touch with
others). For example Usenet. For example Jabber. For example Email. For
example IRC. I wouldn't want to post via Gmane,

Me neither. But why?


chat via Meebo,

Me neither. But why?


mail via GMail etc.

I do, sometimes. I also use Google Groups UI at times -- because this
friggin thing does only seem to work 50% of the time (might be my ISP
though).


I do use web forums - true. But that are mostly plain HTML
with a little bit of application logic. Usually not somehow sophisticated
applications.

Yeah, usually. But why?

Because they all suck; that's why.

So fix it!

I would _love_ to have Open Source email-, irc-, msn/jabber-,
mailinglist- "UI-server-apps" running on my VPS at http://nostdal.org/
with _excellent_ UIs and features instantly accessible from anywhere.

I think this is possible; maybe that's the difference between you and
me.


.

Relevant Pages

  • Re: UI, Lisp, CLOS, MVC, design
    ... this cookie thing? ... hand, when I type in some Web2.0 thingie and add a https before it, I ... It's not like a C based client in Gtk+ can be written in a sloppy ... Yeah, good thing I don't have to worry about distributing upgrades etc. ...
    (comp.lang.lisp)
  • Re: Cookie encryption?
    ... It sounds like a good solution but the problem is that user enters some information on the client side and I need to have this information in a cookie because it is some kind of an authentication ticket. ... If I use a symmetric algorithm how do I send the encryption key? ... I think https in that case doesn't help. ...
    (comp.lang.javascript)
  • Re: What is the easiest way to query a remote XML file on someone elses Linux box using secure commu
    ... I'd recommend HTTPS then. ... The encryption strength depends on the browser. ... client does not support 128. ... Either SSH or something. ...
    (microsoft.public.dotnet.general)
  • Re: Mainframe & thin-client (was Re: Microsoft good press over Longhorn)
    ... > Client, maybe it has capabilities I'm not allowed to use. ... Win2K allows you to access more than 256MB RAM. ... Yeah, it looks like a toy to me, too. ... or because I can't modify it because the Thin Client ...
    (Debian-User)
  • Re: HTTPS durch ISA
    ... > Client die Verbindung aufbaust? ... jetzt NAT oder Route - vielleicht erinnerst Du dich. ... Jetzt geht halt nur kein HTTPS mehr. ... andere geht sauber durch den ISA, ...
    (microsoft.public.de.german.isaserver)
Loading