#4 Album Download Functionality ( Interim )
Outside of the general compression class needed to create
archives ( encapsulate directories as well as allow
inclusion in existing archives etc ), I see the following
as a few of the requirements for an interim
implementation.
Currently I have a working ( non memory hogging )
compression
library working for downloads; following are a few
suggestions
of requirements needed to put it together cleanly...
Please add your thoughts/criticisms.
If you would like to add me, temporarily, to the dev group
on your project, I can go ahead and build this out and
check
it in, though as with all of us, my time is extremely
limited,
so I couldnt possibly promise a time frame ( ~month or
so? ).
Additionally, I have attached some quick mem tests
(as well as other system metrics under the compression
class
I am using...).
General config needs:
-n kb allowed per compression request.
-n files/kb allowed per user per session.
-User Profile based right to download.
-User Profile based priority over disk cache usage,
etc.
-User Profile based and/or site-wide concurrent
download/compression request limits.
Disk Cache functionality:
-FIFO; Pop off first-in if n kb threshold met.
-Promote files with higher "number of downloads"
metrics so they arent popped off ( smart FIFO ).
-Max number of compressed files allowed.
-Max total size.
-Poll download sessions: if session times out
before completion, promote from FIFO deletion
for n time to allow user to resume download -unless
some other cache priority arises, i.e. n blocked
requests
to a full cache, 'priority user' request time/space in
cache, etc.
Metrics:
-Track term Based ( how many times during n
days/weeks/months, or some such ) discrete
'Album download' frequency metrics.
-Track Per user/IP/file download metrics.
-Track number-of/size-of disk cached compressed
files ( by name or otherwise ) exist, for FIFO
operations.
User Interface:
-Provide per-album/per-song selection; by check box
or otherwise -revealed based on users profile rights.
-Provide real time alarm if/when user selects more
than n kb of data for compression/download.
-Real time error reporting.
-'Compression-processing' progress notification,
post download, to insure users dont continually
iterate the request.
Memory and system metrics...
Metric of 1 user compressing a ~155 MB album
1 user compressing a 1GB music compolation...
Logged In: YES
user_id=1058986
oops, that last statement in the User Interface section was
meant to be 'pre', _not_ 'post'.
---cut---
-'Compression-processing' progress notification,
_post_ download, to insure users dont continually
iterate the request
SLR-
Logged In: NO
I have been too busy to work on this until this past week-end-
I have finally started writing a
Greedy-Dual-Frequency-Recency caching class to manage smart
download, file retention and scheduling; additionally, I
will be using the PHPConcepts libraries to construct a class
facilitating encapsulation of files/albums into zip objects
for delivery and have already put together a pretty standard
download resume function ( I havent decided where to put
this yet ).
Modularly, this should cover all the functionality needed
outside of db hooks, though all the above classes will
reveal metrics so that you can grab whatever statistics you
want to store in MySQL for reporting/auditing/management
etcetera. However, for build testing I will simply be using
XML to auth users, set limits and report metrics.
PLEASE! PLEASE!! PLEASE!!! make suggestions now, before I
spend a bunch of time coding only to realize I have
overlooked some obvious flaw in my logic or use case that
one of you saw from the start.
THNX!
SLR-