Re: [Netjuke-devel] Inheritance
Status: Beta
Brought to you by:
blakewatters
|
From: Blake W. <sb...@ne...> - 2005-01-09 09:58:25
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree about the list. Also, I want a place on the developer site to
save logs of our design discussions and weekly meetings. Our
conversation last night (which I have logged) is a perfect starting
point. See if you can make that happen, I'm tied up with real world
work until later this evening.
Anyway, yes NetjukePlugin should be derived from NetjukeObject. If you
look at the code implemented for NetjukePlugin, you'll see that as you
slide down the hierarchy the descendents use NetjukeObject to back the
existence and state of available plugins. Only one table is used
because the data overlaps exactly -- plugins are general types of
pluggable code that can be hot loaded/unloaded. A module and a song
format are two types of pluggable code, the constructor of those
classes call $this->setType('module'), which is a setter implemented
via code generation on top of NetjukeObject. The plugin type is purely
a descendent of NetjukeObject and does indeed exploit its slickness.
Likewise all plugins can be activated/deactivated and this is another
get/set pair you get for free from NetjukeObject.
The main point here is that everything that is DB backed in pluggable
code is common and in the plugins table. Things like MIME types, file
extensions, descriptions, etc. are set in the code for convenience and
to allow the plugin system to grow indefinitely without changing the
schema.
Finally yes, realign NetjukeImage along the same lines.
NetjukeFormatImage class should be added with an image plugin type to
provide formats. I'd say that we eliminate the var/images directory and
abstract NetjukeFile into NetjukeFileImage and NetjukeFileSong, leaving
the additional possibility for NetjukeFileMovie, etc. down the road.
File should now only contain the media root, path to the file, file
size, date added, date changed, type ('Image', 'Song', and '' for files
that aren't either) and creator user ID.
NetjukeFileSong should contain file_id, bit_rate, sample_rate, and
format_name.
NetjukeFileImage should contain file_id, format_name, color depth,
dimensions, etc. -- I leave it to you to expand the set.
These two tables will need to perform a join of their table data to
their constructor during fetch and will need to perform inherited
inserts/updates so that calling $sfile->update() results in both tables
being updated together. This I believe will be very powerful as files
are now totally abstract and download/streaming can be handled via the
same code, as all file will have a MIME Type, a size, a file extension,
etc.
Next, we'll need a netjuke_downloads table which contains a user_id,
file_id, date_created.
Blake
On Jan 8, 2005, at 5:12 AM, John Wulff wrote:
> Now that development is back in full swing, we should probably start
> using this list again. So here goes:
>
> Does NetjukePlugin really need to be derived from NetjukeObject? So
> far no classes derived from NetjukePlugin have needed any of the
> NetjukeObject slickness, so I say get rid of that inheritance.
>
> Also, now that we're committed to using NetjukeFile and NetjukeFormat,
> should the NetjukeImage class/table be re thunk?
>
> --
> John Wulff
> jo...@or...
> (360) 317 - 6447
>
>
> --
> John Wulff
> jo...@or...
> (360) 317 - 6447
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Netjuke-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netjuke-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFB4QBvdpR6/1qAadwRAnlCAJ9lBwa1Fm5Pya1nX2E7qQjb0Rr5QACfcr2s
OdX/bDt1/Zq5xJYLIFfxbY4=
=7aRg
-----END PGP SIGNATURE-----
|