If I understand the OP correctly, they are trying to use RTF files pointing to each other. I may of course be wrong, as the posts are very vague and non-technical.
But assuming that I didn’t misunderstand them: they’d have to convert these RTFs to HTML, which would roughly double the size.
You’re right (and I didn’t think properly) that a static site of 1 or 2TB doesn’t put much burden on the web server.
I still think that 1TB of more or less flat files is an unmanageable heap. At least for a human, and if it’s all dumped into a single directory.
Thank you for your reply.
Your opening if very close to what I’m trying to achieve “If I understand correctly, what you are seeking to do is to create a sort of digital scrapbook or archive for others to use at some time in the future, and independent of DEVONthink” I was hoping to use DEVONthink to build what I thought would be a simple structure. Imagine, for a specific folder, you create a simple text file with commentary, information and context about the files in that folder. Now, further imagine that within the text, you could build bi-directional links between the text and the referenced file within the folder. That’s the concept. I was trying to accomplish that objective with DT indexes to minimize database size and stay away from a proprietary solution. I love DT for my personal use. I’ve just had a lot of experiences with applications that either shut down, sold out or ceased. Case in point, in order to maintain support, I needed to upgrade from DT3 to DT4. No problem for me, but I’m trying to prepare for legacy users 5 or 10 years down the road. A server based solution is probably most robust, but I really didn’t think I needed to go down that road for my “simple” needs.
I’ll check into Obsidian to compare and contrast with DT. I did come across the Hookmarks app. which is intended to provide a way to link files in OSx, seems pretty powerful and simple, but I suppose those links would be in the proprietary format also.
For some clarification on scope and objectives, please refer to my post to https://discourse.devontechnologies.com/u/mbbntu I’ve only been working with one of my directories but the largest contributors to the dataset size are my media files; video, music, presentations, etc. Which would be in separate directories.
Going into an extensive library and trying to find references is an “unmanageable heap” without a decent database of the library’s volumes. I suppose I’m trying to create that decent database of my personal library of information.
Good point. A static site would be all I would need. I don’t plan on any web based distribution
The responses to this question have been numerous with excellent feedback. After sifting through the replies, I conclude that DT is not an appropriate interface for OSx content. While it’s an excellent application for working with OSx content, exploring and documenting relationships within that content, it’s intended as a platform for building and maintaining a personal database and to reliably handle personal content. Yes, it can be used to document my OSx content. But it’s more intended for managing my information on a personal level. Not for sharing that information with my legacy. I want to thank all of the contributors who provided input to this question.
I agree that’s probably the right call. DT indexing is a fantastic interface to the filesystem for those who are already working with DT, but its unfamiliarity would be a barrier to those who aren’t. I’d suggest looking more closely into Hookmark as the next option; its linking is very DT-like, but within and across documents’ individual native apps. Note that Hookmark works very well within DT, so you can still use DT (including automation features, if you want to go there) to set the system up; one of the massive advantages of DT is the ability to work with document types from many different apps in a single window.
Sound advice. I’ll look into Hookmarks in more detail. Perhaps more robust than some of my attempts within DT. But uncertain about the long term legacy it may provide.