darrelopry.com

It may be interesting in drupal to have a cck node type of content-folder, then either use a filefield on the 'content-folder' node or a nodereference with a link to a 'content-file' with a filefield. You could create file hierarchies / file management workflows....

Now if only actions.module provided some way to have actions target an object type like 'node, file, comment, user, none'.... Then we could get supah funky...

Today I got imagefield pretty happy I think. The outstanding ui bugs from the switch to using content.module to store the fid are closed. The views integration works properly, at least for single imagefields...

I extend my thanks to The New America Foundation (http://www.newamerica.net/) and Lullabot (http://www.lullabot.com) for supporting the work.

.darrel.

Documentation for drupal modules. I'm developing.

filesystem
imagecache

There are lots of really cool social networking applications out there. Each is unique in its marketing, but central in what it does. Host an online persona, allow members to associate & 'link' to each other, allow people to search for site members.

However, I don't like the thought of opening social networks to the gain of third parties. It makes me feel like Orwell is hiding in my closet next to Ms. Atwood and Mr. Zemyatin. trying to figure out why I wear an XL shirt when a large would fit me...

So I started thinking of openIndividual, a distributed social network protocol. Its only a hazy vision right now. At its core is the individual record. Which states a users home base on the internet, and the users public key, and the information the user wishes to share about himself.

as usual I have to remind myself of what I want to do this year...

• gl and accounting modules.
• hook_file(yet again).
• datamining... I want the datamining book from elsevier.
• radio archive... (mod to the station module)..

Goals for drupal 4.8 file handling...

• sink all file related DB activity to fileapi
• introduce hook_file
• drop temp files... either upload it or dont. No more messy previews.
• files are associated to a uid not a node.
• limit base file api to four functions upload, copy, move, delete.
• fast path private file downloads
  • download key is created and prefixed to path when url is themed.
  • touch /tmp/dlkeys/key
  • files.php get url, parses key, if (is_file(tmp/dlkeys/key)) { send file } else { check file extension and send appropriate denied file }
    

Neato multiple file uploads

Just documenting for myself later.

I've discovered upload.module is a totally whack piece of code... reading through it I feel like someone was trying to win a code obfuscation contest...

Through the process of osmosis(passing out on my laptop with vi open), I've think I've seen a light. Not necessarily a bright one, but a light none the less. There needs to be a way for modules to dependably interact with the file upload and management process, and hopefully without the overhead of a whole new hook... My disparate thoughts go something like....

if $node->files[$fid] is just an array of properties for a node/file relationship, and $node->filedata[$fid] is what we get from the actual file itself, we can decouple a lot of things... (list, description, properties added by other modules)...

I've been planning on writing a management control panel and billing system for thing.net for a while. I've tried a few commercial ones, but I'm not really happy with them. They tend to be limited to managing a single server with a single application stack and closed source, cost way to much if they can manage a heterogenous environment, and generally aren't all that usable if they're open source. The closest to ideal I've found is Psoft's H-Spere, Currenlty I'm using clientexec, but only as a billing tool.

So I've come up with a list of requirements: