i am beginning the process of creating a new version of 'videolist' for elgg and would appreciate assistance from anyone who can assist me.
features i intend to include:
other features can be added too, however, these are my current list.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
No, you're mixing up making a HTTP request and loading the Elgg engine.
you wrote:
so i wrote:
...
when i referred to the 2nd request (for the video) i was referencing that you wrote that the 2nd request requires the elgg engine to be loaded for a 2nd time. hence my surprise when you drew in the loading of css/js files too. i think you are the one who is mixing up the context here.. ;)
fyi, there is an nginx webinar starting shortly on the exact topic of serving/streaming videos.. it's still listed on the nginx website i think. i will listen and possibly record it.
the nginx webinar was nearly entirely to cover the commercial licensed nginx-plus media features.
@Ura Browser caching mostly eliminates the CSS/JS requests. The video responses are probably much less likely to use cache. The size of the video isn't the big issue (readfile efficiently streams from disk to output), it's that the PHP request can be expensive (if you have to boot Elgg for every range request) and readfile must hold open the Apache process until the video completes/client disconnects. Google "X-Sendfile".
One way to make that video request lighter: if the video is public, embed in the stream request a timestamp and MAC of the URL. Then your stream request endpoint can verify the resource is public without ever checking the DB (though you need to get the MAC key and path to the video somehow). But the basic idea is to use the HTML page to fetch info you'd normally need to look up in the stream responses.
so are you saying that an instance of the the engine is loaded for every css/js request, except that due to caching schemas this rarely occurs?
i am not certain, though i think that nginx handles the process of serving streaming video differently to apache - i don't know all the details presently, however there are flv and mp4 modules pre-packaged with standard nginx and these do effect the way streaming of these formats is performed.
i appreciate that booting elgg for every range request would be highly inefficient.
i am not comrehending your idea regarding the MAC address here. i thought MAC addresses were for physical hardware only.. so not clear on what 'MAC of the URL' translates to.
i might be mistaken, but i suspect that projekktor handles the http pseudostreaming functions in a way that is not being appreciated fully here - since i have not heard of anyone in the forums there needing to address the types of issues being raised here.
Yes
oh ok, so clearly i have no idea of the process schema of the elgg engine.. i have never seen this documented much anywhere. i searched the old and new docs pages.. didn't find anything helpful yet.
Can reloading the engine (with all plugins) for css and js ony be avoided if you use simple_cache ?
Yes, how else would you get js/css files from cobbled together views? You need the elgg engine to stitch those views together into a js/css file. That's why simplecache is recommended for production environments.
Hmm, this is a serious issue. Why is elgg_register_js and elgg_register_css than not fixing this ? Instead of recommending it, it should be doing it for us.
At least I know what I will be doing the coming days. Check a 100+ plugins for following the recommendation.
- Previous
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- Next
You must log in to post replies.