dbpack-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dbpack-devel] browsing the files.


From: John 'el asesino del pollo' Harrold
Subject: [Dbpack-devel] browsing the files.
Date: Wed, 12 Jun 2002 15:28:29 -0400 (EDT)

ok after emailing with joe, i started mulling over a way to "browse"
through files. i sent a description of my thought to joe and i talked to
brian. this is more of a compilation of how i can implement it.

ok each "user" in dbpack can create lists. i was thinking that i could
have system wide lists that were accessable to all users. an easy way to do
this would be to make lists owned by the admin user available to everyone.

then joe said he would like to "browse" through the files. i started
thinking about how i could make the information in the database browseable,
and then i thought i could create something like the open directory project
(http://dmoz.org). an implementation you guys might be more familiar with
is google's directory (http://directory.google.com). 


# one type of directory listing.
this would require the development of some type of higharchy with
subcatagories and files sprinkled beneath. an example of this would be
something like the following: say i have an mp3 of a techno artist
(goatbeat.mp3). this would probably fall under the toplevel category of
"audio". it would also fall under the sub catagories of "techno" and
"artist::artist name". so the file goatbeat.mp3 could be found in the
following two directories:

audio::artist::artist name
audio::techno

the choice of the top level catagories can be site specific with a
suggested list packaged with dbpack. for me it seems logical to break the
files down by application (eg. audio, books, multimedia, images, etc.).
this logic might not be the same for each site. for example brandon might
find it useful to make the top level catagories consist of manufacturers
whos products they will be advertising.

# another type of directory
i could also break the files down based on mime types. all images would be
found in "image" for example. and all gifs would be found in "image::gif".
these directories could be generated based on the mime types of the files
which is currently being stored.

another feature i would like to implement is that when you find yourself
somewhere within the directory hiarchy you can run queries that only search
from that point down.


#my first question:
does the above sound like a good way to implement the browsing? any
suggestions?

#drawbacks
one drawback is that random insertion of files would be inefficent with
respect to directory browsing. this is not a big problem considering some
type of preprocessing would be needed to find the files through searching.



#say the above sounds good, now i want to implement it
i think i could implement this and i have an idea that might not be the
most efficent way of doing this. since everyone has a list, i could just
use the list names to generate the trees. so for the example above, all
admin lists would start with (books, audio, multimedia, images, etc). and
every subcatagory would be added by adding "::subcat" to the list name.
then these names could be chomped up in perl to create the directory tree.

there would also be a couple standard top level directories. one would be
"personal" for example. when you enter this directory you see all of your
personal lists chopped up in a similar fashion to those in the top level
directory. another top level directory would be mime types. here you could
search through all of the different mime types and sub catagories described
above in "another type of directory".

now this probably isnt the most efficent way to store and parse tree
information. this brings me to my second question:

#my second question:
say the directory  methods mentioned above sound like they are good ideas.
is there a better way to store the tree info?

anyway let me know what you guys think.
-- 
/"\                        | john harrold
\ / ASCII ribbon campaign  | address@hidden
 X  against HTML mail      | 
/ \                        | "have algorithm-will travel"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]