Just a note from the UI side of things here, since you're all doing a good
job with the other bits:

On Sun, Sep 5, 2010 at 11:10 AM, Hanno Schlichting <ha...@hannosch.eu>wrote:

> On Sun, Sep 5, 2010 at 7:17 PM, Martin Aspeli 
> <optilude+li...@gmail.com<optilude%2bli...@gmail.com>>
> wrote:
> > On 5 September 2010 15:29, Hanno Schlichting <ha...@hannosch.eu>
> wrote:>> This
> >> should get us out of the business of maintaining a web server, but
> >> will also likely mean the loss of FTP and WebDAV support.
> >
> > I don't think that's a good option. We may not need to support both, but
> > supporting one is probably quite important. For one thing, it'd kill
> Enfold
> > Desktop and similar integrations. WebDAV is also very useful for bulk
> > movement of images and documents.
> I haven't ever seen an actual good and working WebDAV client for
> normal content editors. The WebDAV standard is dead and the big
> operating systems have no interest in fixing it or their
> implementations. FTP is even less user friendly and I've only seen
> WebFTP implementations that work for mortals. I think we should focus
> on better web-based upload and batch functionality and give up on
> those other protocols. As I said, there's some customers that want
> this, but it's a tiny minority and thus best served by an add-on. Just
> because FTP and WebDAV have been cool in 1998 doesn't mean we need to
> keep them in 2010. With HTML5 and AJAX UI's we have better answers to
> these use-cases now.

Yes, at this point I personally think it's fair to consider anything that
isn't part of the web as dead to us.

In actual use, people are much more comfortable with doing everything
through a web browser these days than they were in 1998, both because web
browsers have become more capable, and because we have more and more users
with less sophistication and capability to keep track of abstractions like a
WebDAV/FTP representation of their content — it's bad enough in most systems
that separate the admin interface from the actual content interface, adding
another abstraction on top of this isn't going to work for the average
content author.

Besides, few people are willing to edit HTML by hand on the file system
anymore, and people are increasingly moving away from "blobby" formats like
.doc and are comfortable with doing editing through the web browser as long
as we can supply proper formatting + layout support (via Deco) and a good
autosave-to-draft implementation — and with the IndexedDB/localStorage
options on the horizon for the web in the near future, we can even support
offline editing in a proper, standards-based manner.

I've been pretty bullish on dropping WebDAV and FTP for a while now, and I
think it's time to get serious about it. It siphons away our focus on
proper, TTW solutions when there's always the "you can use WebDAV for batch
operations" option that isn't really maintained by anyone — no disrespect to
Enfold et al, of course, this is a client-side WebDAV issue that is unlikely
to be particularly good in any OS, ever.

I think we should envision a future without WebDAV and FTP as core
components of our stack. They never worked well in practice, and are
unlikely to ever reach mainstream usage because of the extra steps, concept
abstraction, and setup knowledge required.

The browser should be our only deployment target on the client side.

Alexander Limi · http://twitter.com/limi · http://limi.net
Framework-Team mailing list

Reply via email to