structures, usage namespaces, promotion/demotion
Well, I've done (and released) all the structures now. Usages are:
- Ark
- Cabinet
- Drawer
- File
- Page
- Ledger and
- Remark.
Each usage has its own color (but I probably need better colors).
So, next is usage namespaces. When you select a topic displayed by the ledger or remarks commands, for example, you don't want the option of a page by the same name.
Also, a ccp command (works like cc, but restricted to matching with a page) would be handy. And if I'm in a LedgerEntry, a ccp with no arguments should take me to the Page the LedgerEntry is a part of. (Or the Folder, Drawer, Cabinet or Ark the LedgerEntry is a part of.)
My expectation is that names will generally be short, and resolved by context. So being able to further restrict a selection by usage should be handy.
After that I'd like to look into promotion/demotion. Promotion would convert a LedgerEntry to a Page or a Drawer to a Cabinet.
A bit further out, I should be able to post (copy) a LedgerEntry/Page/Remark/etc to another part of the Ark.
Backfilling a bit, I still need a move command to move things between Cabinets. (Should also serve as a shortcut for add/rm.)
Still so much to do to wrap up CompStrm1.
posted by Bill la Forge @ 5:05 PM
4 comments
4 Comments:
Greetings Bill, et. al.,
Something is bothering me about the complexity inherent in the Ark, cabinet, drawer, folder, file model. Is there some compelling reason not to simply model a tree, with all nodes being "equal", at least equally able to contain data, including child nodes? With Promotion, Demotion, etc. it starts to look like those nodes needed to be flexible enough to have these capabilities from the moment they were created. Why not just build it that way?
The only missing piece then is the ability to add "virtual links", a la Unix File System, to add references between branches. The model becomes more organic, and "fractal". I realize that you run the risk of generating comentaries on the commentaries of the commentaries, Talmudic-like, but is that a real risk, or just theoretical? My guess is that in practise, the problem will be minimal.
Just wondering,
Jerry S.
Greetings Bill, et. al.,
Something is bothering me about the complexity inherent in the Ark, cabinet, drawer, folder, file model. Is there some compelling reason not to simply model a tree, with all nodes being "equal", at least equally able to contain data, including child nodes? With Promotion, Demotion, etc. it starts to look like those nodes needed to be flexible enough to have these capabilities from the moment they were created. Why not just build it that way?
The only missing piece then is the ability to add "virtual links", a la Unix File System, to add references between branches. The model becomes more organic, and "fractal". I realize that you run the risk of generating comentaries on the commentaries of the commentaries, Talmudic-like, but is that a real risk, or just theoretical? My guess is that in practise, the problem will be minimal.
Just wondering,
Jerry S.
Why not sitck with a simple implementation? Three reasons: Users, Usage and Access.
Users
Introducing Cabinets, drawers et all makes it much more concrete than a recursive data structure. Easier to relate to, too.
And easy to remain oriented in. Navigating a link to a folder means you are in a folder that is probably in a drawer you are already familiar with. Very quickly you learn which cabinets you are interested in, and which drawers in those cabinets. So in short order you can find those folders/pages of interest.
Usage
Cabinets are moderately decoupled, so can move them easily between arks, put them in a product, cut a CD with selected cabinets, etc. You can even (later) define cabinets that exist on different arks, allowing you to navigate seemlessly between arks/websites.
Pages and ledger entries can be ordered, and sometimes that is very helpful. Comments are always in reverse chronological order.
Currently all these things are implemented using the same base class. Later we will have multiple types built on that base class, making the ark an application server.
Usage is independent of type.
Access
Access controls also differ by granularity. For example, generally anyone can add a comment to anything. But for some applications/usages, you will want to restrict the ability to update a ledger entry based on who created the page.
Cabinets should only be created by the sysadmin, while drawers are defined by (knowledge) domain specialists.
Again, because cabinets are relatively decoupled, it is easy to implement tight security for particular cabinets.
Does this help?
Sure!
Thanks for taking the time to explain. It will be interesting to see how it all shakes out. I'm used to "infinitely" nested folders as a representation of a (computer) file system, so I guess that just feels "normal" to me. On the other hand, it is pretty obvious that the model doesn't match a physical system for hard copy storage. Some finite heirarchy may be ideal for meeting the needs of typical users to see clear limits in their environment.
Thanks again,
Jerry S.
Post a Comment
<< Home