[CalendarServer-users] Web Documents off the Web (was Web Archives)

Tyler Keating tylerkeating at mac.com
Mon Apr 16 13:38:39 PDT 2007


WHOOPS!!  Emailed this to the wrong mailing list...

Silly me.

On 16-Apr-07, at 1:36 PM, Tyler Keating wrote:

> Hi,
>
> I'm bringing this up again with a different tact, because the more  
> that I think about it, the more I believe it has the ability to  
> significantly change the perception and application of HTML and I  
> would really like to keep the discussion alive.  In the previous  
> thread, I proposed a standard for archiving web sites into a single  
> ZIP archive with a unique file extension and although it didn't get  
> any outright negative feedback, it didn't drum up too much  
> excitement either.  If you can bear with me, I'd like to describe  
> the idea again in a slightly different light.
>
> Take for example, web-based presentations vs. PowerPoint from an  
> average user's point-of-view.  I can create an incredibly dynamic  
> presentation based on HTML, JavaScript, CSS, SVG, etc., but I can't  
> easily share it with anyone unless it is served (I can't easily  
> send it to them).  On the other hand, I can create an incredibly  
> dynamic presentation using PowerPoint, but I can't easily share it  
> with anyone unless I send them the file and they also have  
> PowerPoint (I can't easily serve it).*
>
> For another example, which relates to my modest experience, I've  
> created a simple Quotes/Sales/Invoices web app for a friend and  
> have come across similar issues trying to resolve the served file  
> model with the local file model.  Without going into too much  
> detail, assume that there is sufficient reason why a file copy of  
> the web page is needed (in this case because my friend's customers  
> can't use the app directly).  How should the user get copies of web  
> documents to be sent or saved to disk?  Instead of describing all  
> of the various options of saving it to some kind of browser  
> proprietary archive, sending HTML email, creating an HTML-to-PDF  
> converter or some other time-consuming non-user friendly method,  
> let's look at an ideal solution.
>
> Imagine this:  An HTML based document ZIP compressed into a single  
> file could be uploaded as is to the server.  Clicking on a link to  
> the file would probably download, decompress and open the file in  
> the browser seamlessly and, even better, right-clicking on the link  
> instead and choosing "Download Linked File" would download the same  
> nice small single file.**  Double clicking that file would open it  
> in any browser identically as to the served version.  The identical  
> format and behaviour of the web document and the file document  
> presents the best user experience.  Instead of saving a  
> representation of the web document, you are saving THE web document.
>
> The question is, why do we only think of HTML with respect to the  
> web and why are HTML-based documents constrained to being served?   
> This is the meat of my argument.  Browsers have no issue opening a  
> file URI, but humans have an issue dealing with a directory  
> of .html files versus, say, a single .ppt file.  Humans will soon  
> also have issues viewing and serving ODF and OOXML files, I might  
> add, but still won't have issues viewing and serving HTML files.   
> After the little bit of discussion from the first thread, I believe  
> that the solution is indeed a near clone and more complete version  
> of the Widgets 1.0 specification ( http://www.w3.org/TR/WAPF-REQ/ )  
> as something different and as part of HTML, specifying how to  
> package entire web documents as zip compressed archives using a  
> unique file extension.  In reality, compared to all of the other  
> work being done on HTML, I believe this would be very simple to  
> specify and should be very simple to implement.
>
> Please give this some thought.  I appreciate your comments.
>
>
> Tyler Keating
> CEO Concept Digital Inc.  -- don't be impressed, it's just me
>
>
> * I could export an HTML version to be served, but I can't share  
> both ways with the same file and this means I have two versions of  
> the same presentation to work with.  Again, the average user (my  
> mom) isn't going to be serving files created on their desktop any  
> time too soon, since she has just barely grasped email attachments.
> ** Containing any number of HTML, XHTML, CSS, image or other files  
> inside of it invisible to the average user.
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/calendarserver-users



More information about the calendarserver-users mailing list