As KarenS predicted, there have been many Drupal-free nights from me this summer, while my household adjusts to its newest member. Though thanks to Advomatic, my days have continued to be filled with Drupal.
For instance, I've been hard at work on Node Reference / Embed Media Browser (nrembrowser), the perhaps unfortunately named, but descriptive, module that does just what it says. I did a session for it in an earlier incarnation at Drupal Dojo, and have banged at it incessantly, until it's now just about ready for prime time! As I said in the session, that project is, I believe, a reasonable alternative for folks who want Media-like functionality for Drupal 6.
What makes it viable is its integration with WYSIWYG and Styles. Styles is a brainstorm I had during the development of Media, in which I tackled how to display wildly differing data (such as photos and videos) with a single field formatter. I've been refining the model in version 2 of the Drupal 6 version, where I've moved it into a class structure and made lots of improvements. Coming soon to Drupal 7...
And then there's Views Slideshow: Galleria, which makes it easy to create a Galleria slideshow in Drupal. And some refactoring of Embedded Media Field, version 3, in which we begin the migration to Drupal 7's Media, and bring some of its magic (of a unified storage system) back to 6...
But what I've been dying to tell you all is about my few, but precious, Drupal nights. Though it's gone from 12 hours or more a week to three, in the wee hours of the morning at that, I've still been banging away. However, I've changed directions entirely, following another passion of mine: games! And no, not playing them, making them... I've said too much already, as it's not quite ready for release. But suffice to say, I think it'll be fun, and of course, it'll be available through the good ol' GPL...
Father's Day is on June 20. Of course, with a second precious daughter in my life, this day will have even more meaning for me. Gwen recently asked me what I would like, which is always (for me) a difficult question to answer. So I gave it some thought, and came up with a list. In retrospect, I realized it all had to do with my endless pursuit of Drupal, so I thought I'd share that here for other Drupal Dads and their families to contemplate...
A diver's slate - What does that have to do with Drupal, you ask? Well, some of my best ideas come when I'm in the shower. Many of those have been lost forever, because I often promptly forget them by the time I've dried off. This particular gadget has an "infinite scroll", and (presumably with a USB connection) allows its entries to be scanned into a computer later. And if you get your best ideas when diving, its "phosphorescent writing surface illuminates notes during night dives".
Laptop glare guard - This one is obvious. Would go great with a coupon for lunch at your favorite wireless hotspot...
A second montor (albeit a pricey gift) would help with any serious Drupaler's efficiency.
As I sit here in the wee hours of the morning composing this post with Sabina, hoping that 8Tracks will help her sleep, I'm also thinking a white noise generator might be a fantastic gift for new dads. I know we could have used one this month...
Though I have a full Drupal library, I need to finally list the obvious gift for Drupal Dads who might not have read some of the best Drupal books:
and, of course,
What other ideas do you have for the perfect Drupal Dad's Day gift?

Sabina Rose
May 22, 2010
2:28 AM
8 lbs, 2 oz
I'm actually posting this as a question. If you're looking for the answer, sorry I don't have it yet.
How can we reasonably handle large file uploads? I'm talking in the >100MB range; YouTube, for instance, now supports 2GB files, and this will become increasingly the norm. I don't think that most servers are up to that yet, particularly if you need an application to scale.
Currently, using PHP, you need to set memory_limit to more than twice the upload_max_filesize, which as you can see would be prohibitive in the example of 2GB uploads; you'd need to set your PHP memory to >4GB (adding the buffer of 64M or whatever you need to run Drupal). EDIT: Looks like I was incorrect in my assumption; if you're not going to process the file, you don't need a huge memory footprint just to handle the raw uploads. Thanks Nate and Jamie!
Even if you manage to have that kind of resource available, you can probably expect things to splode with concurrent uploads...
So I spent some time yesterday looking at SWFUpload yesterday (module here), as I'd misunderstood its claims. Yes, it handles large file uploads (from the browser's standpoint), but you still need to set PHP memory accordingly. Not suitable for what I'm looking for, but it is a really nice way to handle multiple uploads. WARNING: I also learned from experience and much head-scratching that it doesn't work if you have Apache authentication on your server...
Now I'm looking at node.js as a possibility. This looks really great, and might do the job. Basically, it's a JavaScript application that sits on your server. Yes, you heard that right. Turns out that as JS has evolved, it's turned into a really tight language, and should be quite suitable for concurrent tasks.
Sorry if you came to this post looking for answers; I've simply postulated more questions. But I'm hoping that someone with more experience with this issue might be able to comment, and we'll all benefit from it. Additionally, this might turn out to be a handy addition to the Media suite, perhaps as a fancy stream wrapper for handling large files? And I'll definitely follow-up when I figure out how best to tackle this.
Thanks,
Aaron
MDX 2010 FTW!
With a Drupal Beta planned for May 21, the time is coming for a Media Beta as well! Before we can do that, however, there are a few loose ends to tie up. I've identified two critical pieces for a happy Developer's eXperience (DX) before I'll be happy doing that. There are certainly more: see the Media issue queue for more.
MetaData Handling
The Media module creates Media entity objects, which are fieldable. That means we can already attach any fields or taxonomy to any media object, which goes a long way towards handling metadata. However, Media metadata needs are variable and complex. For instance, a field might be fine for adding a taxonomy vocabulary for Video genre or Bird species, but you would need something better if you want to automatically add video duration, YouTube categories, or grab a music file's getID3 data. Basically, we need a larger discussion of what's necessary, what's possible, and how we get there. See this Media metadata issue for more background.
Display Formatting
Currently, we're using the Styles module to power display formatting. We may or may not continue using that. In any case, we'll need to ensure the formatters more closely follow Media Types, and we'll need to offer a pluggable UI for changing formatter style presets, similar to Image Styles (Imagecache in core, for those not yet familiar).
Media DX Summit 2010?
I'd love to lock up some fellow developers for a couple of days in a room to bang on these ideas. At the same time, my partner Gwen is due on May 22 for our second child, so firstly, I can't really travel any time in the foreseeable future, and secondly, even if we had a summit here in Harrisburg, it would either have to be like this week, or in mid-summer. Considering the deadlines involved for this, we need to get cranking. Thus, the summit I would love to see happen will probably either have to happen remotely, or perhaps without my involvement. :(
Anything Else?
Are there any other issues you would suggest to be critical beta-blockers? Do you have any thoughts to add to the issues I've suggested? Please add to this thread!
Thanks,
Aaron Winborn
(Cross-posted at g.d.o.)
It's at http://groups.drupal.org/node/58198 if you're interested in learning more about the future of XMPP integration with Drupal. The event will be on Friday, March 26, at 12PM EST (17:00 CET).
Kristof wrote:
Recently a lot of people started are working concurrently on XMPP and Drupal integration. So I thought it would be a good idea to share our ideas so we can work on top of a common platform.
We are going to have the meeting on Dimdim. You can join the event at http://my.dimdim.com/all/openlearninglabs/default/
Yes, you heard it right! I'm not going to Drupalcon after all -- it's too close to the due date of our next baby. As much as I'd like to go (Drupalcons really are all that), I would be mortified to miss the birth of a daughter, if she decided to come in to the world a little early.
I'm going to give my ticket to a worthy participant in exchange for a couple of hours of review of the Media module. (Don't worry if you're not a developer or know how to patch or anything -- many of the issues are around usability, so we appreciate all levels of review.) Just contact me off-list if you're interested. You'll still be responsible for travel, though you might be able to find sponsorship for that as well if you act quickly.
That means that, obviously, I'm not going to be able to come present the awesome work from the team developing that module in SF. Don't worry -- there is a panel in the works with some of the biggest names in Drupal multimedia development. I'll make sure to let you know here when the details of that have been settled!
Thanks to some fine work by Jacob Singh, Dipen Chaudhary and myself over the past month, we've gotten Media working fairly well with WYSIWYG, with Media: YouTube and Media: Flickr to boot.
If you haven't looked recently, there's been some huge progress recently for Drupal's Media module. Jacob Singh from Acquia has jumped on board, paving the way for fieldable entities! This allows Media asset objects to be a first class Drupal citizen, alongside Nodes, Users, Taxonomy, and Comments. (Hopefully in core for Drupal 8!) Also, Dipen Chaudhary has been hard at work providing WYSIWYG support!
The final chapter of that section, "Automated Security Testing", explores some currently available modules that should be in the bag of tricks for not only module developers
"Drupal's User and Permissions System", begins the section most exciting to me as a developer, by describing the API and hooks offered by Drupal to help create more secure code.
"Anatomy of Vulnerabilities", offers an extensive overview of the predominate routes of attack that may be taken against a site.
Thanks a lot for article. If you use Rapidshare, you must know Rapidshare Search Engine ( http://filecraft.com ) - Easy Way To Find Files!
what does that have to do with this post?
sarees