1 Dec
2005
1 Dec
'05
3:15 p.m.
It is a very good idea to implement symbolic links in the registry;
however, i do find it very difficult to navigate a registry key with
hundreds of subkeys. Instead I would rather the system choose how to
index the data. Understandibly CPU load and RAM are key factors in
implementing such a service but until system services are implemented
i find it difficult to complete my part of the feature. Using the
registry now is a great place to start. However without rewriting
Explorer to interpret those links it will take some amount of time.
On Dec 1, 2005, at 7:08 AM, David Hinz wrote:
Well, if you add these features or plan to add them in
the near
future, the service with the MySQL or whatever db would be better
for this, I just said that I like my idea more than yours, because
it is easier to implement.
It is true, that the registry would become larger by this, but how
many symbolic links do you want to use? 10000?
I think there wouldn't be much more than 100 of those links (and if
there were many more, it would just show, how important this
feature was...), so how slow would a PC have to be that this
feature would slow it measurably down?
To say it again, the idea with the db is good, but it is only
better than mine, if you really want to implement the features you
mentioned, because otherwise it would waste a lot of cpu-time and RAM.
@Richard: Windows doesn't slow down because of the registry (the
german pc-magazine c't prooved that some months ago), I think it is
because of full and very fragmented harddisks...
Greets,
David Hinz
Rick Langschultz schrieb:
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.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev