Re: [Netjuke-devel] Inheritance

[Blake W. <sb...@ne...>]

-----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-----