On Jun 23, 2005, at 12:38 PM, Scott Rossi wrote:
If you want to deliver a media player now, the only way around this
is to
have your app duplicate the user's media somewhere on their drive,
rename
it, and then make sure to delete the duplicate when you're done.
For a few
files, one by one, this might be OK, but I question whether this is
a valid
workaround for potentially dozens of multi-megabyte files.
Exactly my precise predicament "potentially dozens of multi-megabyte
files."
How about in the range of 2000! (I'm not kidding, we have a huge
audio library archival project in process...)
My "Audio Transcriber.rev" is deployed now to about 15 people on
remote locations around the world, this app downloads files from our
server on the LAN in Hawaii, transcripts are done locally, these are
sent back here with a POST to a CGI on our server here and later,
when ready for public, transfered to our distribution web server in
Connecticutt. Meanwhile I have inhouse apps in the works that will
catalog and make all these sound files and their
transcriptsaccessible. I set a new standard here for file names where
[2-ltr abbreviation for the author-speaker]_[international-date the
talk is given]_[some unique subjectwords].mp3
e.g. we record Scott Rossi describing his work flow for software
development, the file is named
sr_2005-06-05_RevConWorkFlowPresentation.mp3
and the XML transcript becomes
sr_2005-07-23_RevConWorkFlowPresentation.xml
because I got fed up with an earlier model we developed for reasons
long ago for reasons I won't get into here: based on paths
past/2005/July/July_23_05/sounclip.mp3 where a data base was an
absolute requirement to make any sense out of these files. The new
model, which may also have a database for query work, is more
accessible... we need our editors to be able to simply go to the
server on the LAN and make some sense out of what they see from the
Finder...
My whole functional spec was envisioned with the expectation that the
long file name issue, was no longer an issue. A mistake on my part...
a little hacking in the early stages can be really critical to the
development path. I think you can see the kind of nightmare I'm
headed for... Right, sure it's not a blocker, we can still "develop"
but if x Number of hours are used to implement a workaround, instead
of making progress, in my book, as a production manager for
publications that must get out the door on real time schedules,
that's a blocker...
Sivakatirswami
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
