1 Dec
2005
1 Dec
'05
12:37 a.m.
I was thinking more of a self-optimizing database service that would
allow indexing of files, submitting and retreiving metadata
information, extended file permissions and DRM (evil) if needed. Also
it could be built on something small like MySQL with an InnoDB
backend or even sleepycats or perhaps MaxDB from Mysql because they
provide the XML indexing engine which could prove very useful when
modifying data through notepad. Also the service could be controlled
like Spotlight in Mac OS X Tiger. This indexing service could index
different file types also and symbolic links would hold higher
privilege that indexed files. Using the registry is illogical because
the system goes through each of those keys on startup and loading...
Also with a new explorer interface the XML engine could interact with
explorer and the desktop in an attempt to create a better ReactOS
interface.
On Nov 30, 2005, at 5:57 PM, Richard wrote:
Use the registry? For symbolic links? Extra file
info? Are you
kidding me? You DO know why Windows tends to slow down over time
right? Over the months/years the registry gets more and more
cluttered with...junk. What happens when you delete a file? What
happens if the file gets nuked via a disk error? What happens if a
user doesn't WANT symbolic links taking up precious memory (and
just because you can get a GB of RAM for $70, a 200 GB HD for
under $100, doesn't mean you should try and use all that space on
operating system code. See Vista for an example*)
A service with an integrated db engine is the best way to go if you
want to do that, but please remember that NTFS already has support
for symbolic links.
Not to say that your idea isn't a good one...it's just better off
as a system service, as suggested earlier.
David Hinz wrote:
Why should I implement a service that provides me
a db if I could
just use the registry, that works perfectly?
This service would make sense if we would use it for other
purposes like additional informations about files and so on, but I
think my idea is much more easier to implement.
I don't say, it's the best for the future, but it is capable of
what I want it to be, doesn't need many resources and adds a nice
feature to ROS, NT was always lacking.
And I don't want to wait until an NTFS port comes into works,
because that might be in 3 or 4 years and who knows what
filesystems we are using then... maybe already our own, created by
Hans Reiser, because I hates Linus Torvalds for not integrating
Reiser4 into the Linux kernel and wants revenge... who knows, but
such a FS would be very fast...
Enough ot...
What I wanted to say is, I want ROS to be capable of symlinks and
this completely independent of the FS it is using.
I think theres no need to implement this into the FS, maybe wo
could write a backup of these regkeys to the harddisk, so they can
be imported into other ROS-installations, but that's not that
important now.
Greets,
David Hinz
Rick Langschultz schrieb:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev Why not include a system service that implements
a metadata
server to create the symlinks for you. It would be simple to do
with a sleepycat db or embedded mysql engine. Of course the links
would have to be accessible by other processes and applications
to be add to the whole experience. Or wait until an NTFS port
comes into works and then implement symlinks then... Either way
they are going to have to be written into the filesystem one way
or the other.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev