Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:0

File Management System?

posted by Krow on 12:59 AM March 9th, 2003   Printer-friendly   Email story
Krow added Blob support for stories. That is great, however, it stores all the info into a database. How hard would it be to design a plugin that works more like the gallery plugin for slash. IE: To be able to add PDF/Mp3s/Images, etc, into a story or comment, but have it stored in a directory or something rather than the database.
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.
  • Not planned to do it. Dishing files from the DB works very well, so I don't see any reason why we would bother doing anything else.

    BTW if I can finish up with a few bits of code here in a bit I will probably be committing image support stuff to Slash this evening or tomorrow.

    You can't grep a dead tree.
    • > Dishing files from the DB works very well,

      what about the overhead of it?

      It just seems, well, for lack of a better word at the moment, wasteful, to store it in the DB.

      Granted, I can see 2 advantages:

      1) You don't have to modify your theme. Just put the file into the db, and it's in.

      2) If you want to make something downloadable, and you want to make sure someone's hit/read the documentation/story/info for it, this is the definitely the way to do it. If the file's not in the filesystem, then someone can't necessarily get/use a direct link to the file/image.

      But the overhead is what concerns me....

      lottadot []
      • You grab the blob via a primary key and shove it out the socket.

        Which means adding more image servers is cake (aka put up MySQL and just replicate). This solves a number of issues for server farm as far as making sure things are synced. Plus since we store our files a certain way we know there is never more then one copy of them. Plus we can do reference counting and deleted blobs when needed from the DB.

        You can't grep a dead tree.
      • Yeah, overhead has me concerned too. When Krow gets it working we'll see.

        I know when I did Oracle DBAing a few years ago (4) they were working on this Internet File System, which basically would allow you to store everything to a database, and you could search/sort/file etc on it. Don't know if they ever pulled it off though....

        I'm very interested in trying this when it's ready. I'd like to be able to restrict access to registered users and make them do a READ MORE to get access to a file.


        It's either on the beat or off the beat, it's that easy.
    • It'd probably make integrating with old systems easier.

      I'm trying to build a slashsite on the intranet of a company
      who has been using ftp service for a while. It seems nice
      to have `attachments' in stories, yet can access those
      attached files in the ftp server at the same time.

      Publish the ftp service on the web, provide an url for each
      file, and attach the urls in stories, is one way to do this,
      but it seems much better if one can simply submit the story
      and the files and they will all go to the expected places.
      Storing blobs in file systems gives another choice to implement
      this feature.
  • I had an idea for a plugin, I thought up a name 'Renderer' for it.

    The idea would be that you would manage a list of files in it. Each file would have

    file {uniqueid,filenname,section,topic,type,seclev and acl}

    You'd add/remove files at will, depending on if you had the access (seclev and/or acl) to do so.

    The idea behind is that the content of the file would be held in a template, in slash's template system. So when you editted it, you'd use the template editor.

    All the renderer would do, is either at the time of saving, or at an interval (via a task) it'd write it to .shtml, or .tmpl (your choice) though .tmpl's are still rendered via apache versus .shtml's are just served out.

    This would work with the assumption that it could attach to Slash::Blob and pull in whatever file/information you wanted for it. But the overhead would be low, because it'd be writing to files once, hence one sql lookup, and that's it. After that, the httpd is dishing out the content.

    I don't know if something like that would be useful. It was something I thought up when Krow first mentioned the Blob plugin.

    lottadot []