Add published but uncommited Site updates post
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
This commit is contained in:
parent
842837dbb3
commit
1a26f68e09
48
posts/site-updates.markdown
Normal file
48
posts/site-updates.markdown
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: Site Updates and AppCache depreciation
|
||||||
|
author: Collin J. Doering
|
||||||
|
date: Feb 08, 2016
|
||||||
|
description: Stabilized site and removed javascript requirement
|
||||||
|
tags: general
|
||||||
|
---
|
||||||
|
|
||||||
|
I am happy to announce that this site is nearly complete. There are a few additional features I
|
||||||
|
still intend to add, mainly to do with offline viewing and user experience, but all-in-all I am
|
||||||
|
quiet happy with it. Now I intend to mainly focus on populating this blog with more content and
|
||||||
|
writing a little more frequently. Also for those of you wondering if pagination is working, it
|
||||||
|
is, completely! Both on the tag pages and the blog page, however currently I don't have enough
|
||||||
|
articles to trigger multiple pages (greater then 6 is required), so the pagination
|
||||||
|
next/prev/first/last page links at the bottom of the page are plain text. I at some point may
|
||||||
|
address this but it will only really be an issue for another few articles and could be resolved
|
||||||
|
quiet easily in the case of 6 or less articles.
|
||||||
|
|
||||||
|
Recently, I came across an article saying to my dismay that the Application Cache API is being
|
||||||
|
depreciated in firefox. I say to my dismay because this site uses Application Cache so it can
|
||||||
|
be viewed offline, which means I'm going to have to refactor my site for Application Caches
|
||||||
|
replacement. Some would say offline viewing is overkill for a blog but initially I attempted it
|
||||||
|
as a learning exercise, but am pretty happy with the end result of a pretty smooth offline
|
||||||
|
viewing experience.
|
||||||
|
|
||||||
|
<!--more-->
|
||||||
|
|
||||||
|
Needless to say, while setting up Application Cache, it seemed like it wasn't a very flexible
|
||||||
|
technology. I was able to make it do what I wanted (for the most part) but things like
|
||||||
|
selectively caching an article wasn't doable with Application Cache. I still intend on offering
|
||||||
|
this feature, however I was going to implement it via offline storage as it couldn't be done
|
||||||
|
dynamically on the client side with Application Cache. There is a better alternative though,
|
||||||
|
ServiceWorkers which replaces Application Cache provides the flexibility to provide just this;
|
||||||
|
dynamic caching based on whatever conditions the developer sees fit. In a nut shell,
|
||||||
|
ServiceWorkers act as a proxy running in a Worker (thus in its own thread) between your web
|
||||||
|
application and the browser.
|
||||||
|
|
||||||
|
Anyways, as I read through the documentation for ServiceWorkers I'll be sure to update my blog
|
||||||
|
to use them in place of Application Cache. I'm looking forward to experimenting with this new
|
||||||
|
web spec, and thinks it hold great promise for the future.
|
||||||
|
|
||||||
|
As a closing note: one thing that worries me about web applications becoming able to deliver
|
||||||
|
similar experiences to classical native programs is that of freedom and availability of source
|
||||||
|
code. Of course, this is why the [AGPL](http://www.gnu.org/licenses/agpl-3.0.html) exists, but
|
||||||
|
none-the-less, I fear the day when the majority of users simply use a web browser to do their
|
||||||
|
computing. It will leave them locked to a particular service without the ability to even
|
||||||
|
reverse engineer the application because all communication can take place via an encrypted
|
||||||
|
connection.
|
Loading…
Reference in New Issue
Block a user