Re: [Netjuke-devel] Inheritance

[John W. <joh...@gm...>]

I added a forum (
http://www.netjuke.org/index.php?name=PNphpBB2&file=viewforum&f=14 )
on boards where we can post logs of our IRC and IM development
discussions.  Only 'The Netjuke Team' group has permission to post new
topics, but everyone can reply.


Ok so we can all be on the same page, here is the inheritance tree
currently in SVN.

# NetjukeFormat
    * NetjukeFormatImage
          o NetjukeFormatImageJPEG
    * NetjukeFormatPlaylist
          o NetjukeFormatPlaylistM3U
    * NetjukeFormatSong
          o NetjukeFormatSongAAC
          o NetjukeFormatSongFLAC
          o NetjukeFormatSongMP3
          o NetjukeFormatSongWMA

Right now we're naming the format files 'plugins/MP3/MP3.song.php'. 
Should we consider naming them something like 'MP3.format.song.php' or
'MP3.song.format.php' (I vote for the latter).  This change would be
more consistent with 'plugins/Installer/Installer.module.php'.


On Sun, 9 Jan 2005 04:59:11 -0500, Blake Watters <sb...@ne...> wrote:
> -----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-----
> 
> 


-- 
John Wulff
jo...@or...
(360) 317 - 6447