Wapp

[ver 2 considerations] cookies, headers, params
Login

[ver 2 considerations] cookies, headers, params

(1) By Oleg (oleg4tcltk) on 2020-06-08 13:36:30 [link]

Hi.

Shouldn't it would be better to use separate dicts for headers, cookies and params? Thus, we can avoid names clash and forget about case restictions.

(2) By D. Richard Hipp (drh) on 2020-06-08 14:06:48 in reply to 1 [link]

No.

My purpose in writing Wapp is that I wanted a system for putting together
web pages (such as the [SQLite checklist][1]) that was first and foremost:
"*simple*".

[1]: https://www.sqlite.org/src/ext/checklist/top/index

Developing webpages is not my primary job.  It is just something I do out
of necessity in order to facilitate my primary job.  And for that reason,
I want a framework that is very, very simple.  I don't want to have to remember
a lot of arcane rules and interfaces.  I want to be able to write scripts that
work on multiple platforms, without modification, that are easy to trouble-shoot
and maintain, and that I don't have to look at or worry with constantly in
order to keep them up with the latest new technology.  

I don't touch my scripts except very rarely.  In between edits, I will
typically have forgotten how the script works.  For that matter, I won't
even remember how the Wapp interface works.  Each time I make an edit, I
have to relearn all this stuff.

That's why I wrote Wapp to begin with.  None of the other available
frameworks (that I know of) come anything close to my ideal of
minimalism.  I want to focus on keeping Wapp very easy to learn,
Very easy to understand, and with the smallest possible API surface.

You seem to be wanting to push Wapp towards a richer, more featureful, and
more standards-compliant system.  I appreciate your input.  I'm sure you
efforts will meet somebody's needs somewhere.  But they do not meet my
needs.  I am *very* content to have Wapp accept a subset of what the
standards allow with respect to cookies and query parameters and whatnot,
as long as that keeps the interface simple.

If you want to work on Wapp++ or `[incr Wapp]` or something like that that
uses Wapp as a foundation, but adds additional features and standards
compliance, I think that would be great.  I'll set up a website for you if
it helps.  Just let me know.

But let's leave the core Wapp as simple as possible.  Focus your enhancements
on removing code and deleting interfaces, not adding code or adding
interfaces.

(3) By Oleg (oleg4tcltk) on 2020-06-09 10:03:45 in reply to 2

> Developing webpages is not my primary job. It is just something I do out of necessity in order to facilitate my primary job. And for that reason, I want a framework that is very, very simple. I don't want to have to remember a lot of arcane rules and interfaces. I want to be able to write scripts that work on multiple platforms, without modification, that are easy to trouble-shoot and maintain, and that I don't have to look at or worry with constantly in order to keep them up with the latest new technology. 

I like this approach and i try to stick it too. I think that separating cookies, headers and params simplify wapp, but i understood your position.

> If you want to work on Wapp++ or [incr Wapp] or something like that that uses Wapp as a foundation, but adds additional features and standards compliance, I think that would be great. I'll set up a website for you if it helps. Just let me know.

If it will be useful for anyone, i think it would be great if you can place somewhere a link to a repo - https://github.com/lego12239/wapp .