


Sembrowser
System Software by siv 3 comments
A similar concept to Bayesian filtering overall.
- Jan 02 2010

Sembrowser
System Software by siv 3 comments
I wonder if following prototype design initiative, a backend paradigm shift might be wise for semantic storage;
A way of using policykit to restrict the ability to (from example) index the root filesystem thereby allowing a deselection of what should have been indexed for semantic crawling.
It should allow to drop a dependency of not looking at a filesystem (in explicics) as accorded by Microsoft drive letters, instead passing by the root and sub-directory model of Unix to everything homedir including mounts and possibly /usr should policy be altered so.
A semaphoric return to C prompt intentions with a semantic bent. Non-explicit user access to root by acl in the semantic engine, which then crawls the entire filesystem.
Kind of like union-fs or reverse-bind mounts where the indexer can not index system directories.
I can actually then see a pervasive use for ACL keys as opposite lists in policy-based machine setups inclusive with semantic layer. x_attrs can be easily targetted as an engage-able technology by the storage backend.
Also the door is left open for a dropoff of responsibilities to the VFS layer over handling of x_attrs and acl depending on underlying filesystem.
A roll-up of attributes can be done from the database and dumped through the VFS layer to platter.
x_attrs copy is assured for file copies between devices by technology like sem_browser irregardless of underlying VFS layer.
A stipulation for actually storing and retrieving x_attrs on pluggable media via
Akonadi for filesystems that don't honour acls and x_attrs. (policy)
I don't know enough about acls/x_attrs to say whether it would be seamless and elegant but from my perspective it follows in gui userspace what Hans did attempt in kernel-land, and it has the benefits of scale ability within limits of reason. With a shift to exlusions rather than inclusions for the advent of the sematic method of storage it's easier to see what isn't required in-mind (such as /) vs. what's required to avoid information overload. In between is obviously a method to balance demands on time, hence why the computer was invented. - Dec 31 2009
A way of using policykit to restrict the ability to (from example) index the root filesystem thereby allowing a deselection of what should have been indexed for semantic crawling.
It should allow to drop a dependency of not looking at a filesystem (in explicics) as accorded by Microsoft drive letters, instead passing by the root and sub-directory model of Unix to everything homedir including mounts and possibly /usr should policy be altered so.
A semaphoric return to C prompt intentions with a semantic bent. Non-explicit user access to root by acl in the semantic engine, which then crawls the entire filesystem.
Kind of like union-fs or reverse-bind mounts where the indexer can not index system directories.
I can actually then see a pervasive use for ACL keys as opposite lists in policy-based machine setups inclusive with semantic layer. x_attrs can be easily targetted as an engage-able technology by the storage backend.
Also the door is left open for a dropoff of responsibilities to the VFS layer over handling of x_attrs and acl depending on underlying filesystem.
A roll-up of attributes can be done from the database and dumped through the VFS layer to platter.
x_attrs copy is assured for file copies between devices by technology like sem_browser irregardless of underlying VFS layer.
A stipulation for actually storing and retrieving x_attrs on pluggable media via
Akonadi for filesystems that don't honour acls and x_attrs. (policy)
I don't know enough about acls/x_attrs to say whether it would be seamless and elegant but from my perspective it follows in gui userspace what Hans did attempt in kernel-land, and it has the benefits of scale ability within limits of reason. With a shift to exlusions rather than inclusions for the advent of the sematic method of storage it's easier to see what isn't required in-mind (such as /) vs. what's required to avoid information overload. In between is obviously a method to balance demands on time, hence why the computer was invented. - Dec 31 2009