[dev] [cvs] commit: incubator/oscar/config conf.xml incubator/oscar/lib Oscar.php

Michael Rubinsky mike at theupstairsroom.com
Tue Sep 11 03:31:51 UTC 2007


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>>>>>
>>>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>>>
>>>>>>> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>>>>>>>
>>>>>>>> mrubinsk    2007-09-09 23:51:06 EDT
>>>>>>>>
>>>>>>>> Modified files:
>>>>>>>>  oscar/config         conf.xml
>>>>>>>>  oscar/lib            Oscar.php
>>>>>>>> Log:
>>>>>>>> We should use a configuration parameter for an alias to oscar's
>>>>>>>> VFS dir (like we do in Ansel). This make it more obvious that you 1)
>>>>>>>> need a file based vfs, and 2) that you must create an alias to the
>>>>>>>> proper dir in the VFS for oscar to function.
>>>>>>>
>>>>>>> Actually we should not require a file based VFS.
>>>>>>
>>>>>> Agreed, although we will still need a web accessable directory to
>>>>>> store the flv files out of though, correct?  Should I just re-word
>>>>>> the  configuration description then...maybe make it a fully
>>>>>> qualified url  in the case the VFS represents a directory on another
>>>>>> web server? I'm  still not clear on how viewing the flash files out
>>>>>> of a sql based vfs  would work, though that is just probably my own
>>>>>> lack of understanding :)
>>>>>
>>>>> It's the same like in Ansel. Files are generally provided through a
>>>>> script, so the VFS backend doesn't matter. Having an alias that points
>>>>> directly to VFS_file directory is only an exception.
>>>>
>>>> OK. Sorry for being so dense about this, but in Ansel, if we don't
>>>> use  the direct vfs method, then don't we have to pass the actual
>>>> raw image  data to the browser, instead of outputing an <img> tag?
>>>> Can something  similar be done with flash files?  I thought you had
>>>> to provide a src  for the file when embedding the plugin?  Again,
>>>> sorry for being so  dense about this, as I don't have a whole lot of
>>>> experience with using  this plugin...
>>>
>>> Take a look at Ansel::getImageUrl() which is taking care of proving
>>> the correct url anywhere we need to reference it in a src attribute.
>>
>> Ok.  After digging around in the code some more, I'm still not
>> convinced that we can do this without some sort of file based vfs.
>> Yes, in Ansel we can do it becuase everywhere in Ansel we need an
>> image url, we can use the url to the img/*.php script that will
>> return  the raw image data to the browser...not the textual URL.
>>
>> In Oscar, however, the Scrubber plugin that plays the movie needs a
>> path to the movie file passed into it...it won't work tyring to
>> output  the raw movie data...it would get dumped into the HTML for
>> the  <object> tag etc... (see templates/video/lighttpd.php).
>
> Maybe I'm missing something, but the movie player is taking an url to
> load the movie from, no? It doesn't matter if this url points to a php
> script that streams the raw movie data, or to a movie that is directly
> sent from the web server.

Yea. It finally sunk in to my head after I send this....one of those  
emails I wish I could have recalled after I sent it ;)

Thanks for sticking it out with me.

>> That, plus the fact that all the shell commands we do for processing
>>  the video need a file path to the input and output files...I'd hate
>> to  see all those files being dumped in a tmp directory to be
>> processed,  and then moved to the vfs etc...
>
> This is a good point, but since all the processing probably happens
> right after the upload, it's mayb not that good after all. :) And I
> don't why processing files in a temp dir might not be a good idea.

I guess it's not, I was just thinking about disk I/O...


> If for some reason we have to rely on the file backend, then we should
> not use the VFS library at all. It just adds an unnecessary overhead
> in this case.

Well, currently, it doesn't use the VFS library at all...which is  
really what led me to think it was planned to be only local file based  
storage.  It just assumes there is a file based VFS, and gets the  
directory from Horde's VFS config...and before I added the alias  
config, it was just assumed the entire VFS directory was aliased to  
/horde/vfs.  I'll dig around the code some more and try to make  
everything work through the VFS library and see what kind of  
performance it costs...

I'm just happy I finally got it working on my machine all the way from  
upload to viewing :)

BTW, I can't figure out why the configswitch for the 'converting'  
section doesn't reload the configstring values when changing from  
ffmpeg -> Mplayer or back?  Spent way too much time trying to  
troubleshoot that....is anyone else seeing that?

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: PGP Digital Signature
Url : http://lists.horde.org/archives/dev/attachments/20070910/12c75ecb/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2013 bytes
Desc: PGP Public Key
Url : http://lists.horde.org/archives/dev/attachments/20070910/12c75ecb/attachment-0001.bin 


More information about the dev mailing list