[Pdx-pm] browser as kitchen sink?

Eric Wilhelm scratchcomputing at gmail.com
Wed Mar 28 01:23:38 PDT 2007

# from Michael G Schwern
# on Tuesday 27 March 2007 11:29 pm:

>Eric Wilhelm wrote:
>> But, then I wonder why we don't just use subversion.  (And,
>> honestly, I don't like to edit much of anything outside of vim.)  If
>> the layout engine could play nice with dotReader, a plugin might be
>> able to serve as a client-side preview tool.  That, or I could get
>> over my desire to preview and just write everything in unmarked
>> text.
>There's the rub.  If you're editing content on your local filesystem
> and can't see how its going to look rendered until AFTER you push it
> then you've got a problem.  Its like doing your crossword with a pen.

Why can't I see how it will look until after I upload it?  Does the 
server only run on unicorns?


On 3/27/07, Eric Wilhelm wrote:
> ...and a RESTful API would enable a thick-client mode.

Thick-client software has some surmountable issues in deployment, but 
<textarea> and POST have insurmountable issues in richness of 
interface, responsiveness, etc.  That, and the cross-browser 
compatibility issues which are basically just deployment troubles 
percolating into runtime.  And how are we going to have real-time 
collaboration if everybody is unaware of other users currently editing 
the page?  How about: "hey joe, I see you are also editing this page, 
want to work together?"  I suppose you could cobble that together in 
javascript, but why not peer-to-peer?

>To the "I hate editing in a web browser textarea" folks I say don't
> downgrade the world you Luddites, GET BETTER TECHNOLOGY!

A browser is for browsing.

I do wish the kvim -> kpart thing had panned out though.

"Matter will be damaged in direct proportion to its value."
--Murphy's Constant

More information about the Pdx-pm-list mailing list