Dev Blog 20 / Feature Creep: Snatching defeat from the jaws of victory.
Stage 4 hay-fever at the end of last week and the weekend sadly prevented me making the hoped-for DocTree video. Toward the end of Sunday I managed to get Multiview pretty much complete, ready for the implementation of cut-and-paste between different moments or trousers-of-time of your document.
And then I had a much better idea.
I'm not going to call it a good idea. I would characterise a good idea as one that presents itself in a timely fashion - say, within moments of having a similar but less good idea rather than after three miserable sniffling brain-fogged weeks of implementing it.
The therefore-not-good-but-definitely-still-better idea runs as follows:
Rather than press on with Multiview (which has made things that were simple, clean and functional awkward, messy and bug-prone), I'm going to implement Davenport as a client/server database, and allow multiple instances of the app to connect and edit the same document simultaneously.
In hindsight this was the obvious route to have taken. Normally, allowing multiple connections to the same document makes things very complicated. Not so here, although explaining why demands that I elaborate a little on the DocTree format of Davenport documents.
Essentially, DocTree records the individual edits you make rather than the final form of the document. So you can boot your computer from cold, load up a project from last week and immediately start hitting 'undo' as though you had never left off - all the way to the very beginning. Not only that, but you can browse back to an earlier state of the document and start editing again from that point, creating a new 'branch'. Nothing is ever destroyed.
That makes Davenport more or less uniquely suited to a client/server database architecture, since edits from different clients literally cannot conflict with each other.
So, why is this a better idea?
Well, first of all it means you can open as many views of your document as you need. "Multiview" was always overselling the previous solution - "Dualview" would be more accurate. And you can spread these views out across multiple monitors, rather than having views fighting for the same on-screen real-estate.
Secondly it keeps the client code simple, robust and fast.
Thirdly and most importantly it actively anticipates future cloud support and collaborative tools, which were stretch goals at best before.
So there's a lot to be excited about. Unfortunately it does mean that the last couple of weeks have been rather a waste of dev-time, for which I can only apologise.
Thus I'm mothballing the multiview build (see: it's already lost its proper noun status) and reverting to an earlier version. I'll use that to demonstrate the existing DocTree functionality in a video at the end of this week, and turn my full attention in the meantime to the client-server architecture.
And then I had a much better idea.
I'm not going to call it a good idea. I would characterise a good idea as one that presents itself in a timely fashion - say, within moments of having a similar but less good idea rather than after three miserable sniffling brain-fogged weeks of implementing it.
The therefore-not-good-but-definitely-still-better idea runs as follows:
Rather than press on with Multiview (which has made things that were simple, clean and functional awkward, messy and bug-prone), I'm going to implement Davenport as a client/server database, and allow multiple instances of the app to connect and edit the same document simultaneously.
In hindsight this was the obvious route to have taken. Normally, allowing multiple connections to the same document makes things very complicated. Not so here, although explaining why demands that I elaborate a little on the DocTree format of Davenport documents.
Essentially, DocTree records the individual edits you make rather than the final form of the document. So you can boot your computer from cold, load up a project from last week and immediately start hitting 'undo' as though you had never left off - all the way to the very beginning. Not only that, but you can browse back to an earlier state of the document and start editing again from that point, creating a new 'branch'. Nothing is ever destroyed.
That makes Davenport more or less uniquely suited to a client/server database architecture, since edits from different clients literally cannot conflict with each other.
So, why is this a better idea?
Well, first of all it means you can open as many views of your document as you need. "Multiview" was always overselling the previous solution - "Dualview" would be more accurate. And you can spread these views out across multiple monitors, rather than having views fighting for the same on-screen real-estate.
Secondly it keeps the client code simple, robust and fast.
Thirdly and most importantly it actively anticipates future cloud support and collaborative tools, which were stretch goals at best before.
So there's a lot to be excited about. Unfortunately it does mean that the last couple of weeks have been rather a waste of dev-time, for which I can only apologise.
Thus I'm mothballing the multiview build (see: it's already lost its proper noun status) and reverting to an earlier version. I'll use that to demonstrate the existing DocTree functionality in a video at the end of this week, and turn my full attention in the meantime to the client-server architecture.
Comments
Post a Comment