netjuke-devel Mailing List for Netjuke (Page 2)
Status: Beta
Brought to you by:
blakewatters
Menu
▾
▴
netjuke-devel — Used by developers to submit code-patches and explore netjuke-related concepts.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(129) |
Apr
(31) |
May
(10) |
Jun
(14) |
Jul
(9) |
Aug
(6) |
Sep
(12) |
Oct
(12) |
Nov
(2) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(25) |
Feb
(17) |
Mar
(37) |
Apr
(49) |
May
(32) |
Jun
(7) |
Jul
(7) |
Aug
(4) |
Sep
(2) |
Oct
(19) |
Nov
(3) |
Dec
(4) |
| 2004 |
Jan
|
Feb
(5) |
Mar
(4) |
Apr
(14) |
May
(1) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Blake W. <sb...@ib...> - 2004-04-16 01:58:30
|
I've been cleaning up the PHPDoc markup in the source files to keep them better organized and easy to navigate as our codebase begins to grow. In general, I've migrated to the following new layout: - All plugin modules constitute a subpackage of their own (i.e. all MPD files should be in the MPD subpackage) - All library modules live in LibraryModules subpackage - All php files in the /dev/ subdirectory live in the DeveloperToolkit subpackage - All core modules live in the CoreModules subpackage - All core netjuke code in /lib/ lives in the Backend subpackage - All blocks in the blocks/ subdirectory live in the Blocks subpackage - All web endpoints live in WebFrontend Sound reasonable? Blake |
|
From: Blake W. <sb...@ib...> - 2004-04-16 00:05:36
|
As if I didn't bullshit enough on the list this week already, I have further points for musing. As I've just implemented the library module support code and have been playing with NuSOAP, I've been thinking about Netjuke as a web services architecture. Specifically, I'm considering adding a service.php web endpoint and creating a NetjukeService.inc.php library wrapper to allow the easy development of web services. The NetjukeError display method will be wrapped such that it invokes the service to return an error (i.e. a soap envelope or an RPC failure code). I'm beginning to envision a system that transparently binds library modules and specific plugin methods as web services when you enable a service. This could be implemented as a separate module type (say, the 'service' module) or via plugin modules which extend the standard API to a given service type. I have some long term ideas that will make this architecture particularly wicked. With Netjuke serving as a presentational jukebox and management system as well as a web services platform, the possibilities extend well beyond the rather ambitious ideas we are already playing with. I'd like to see a P2P system or loose clustering module for connecting multiple Netjuke instances together, possibly with smart caching. Syndicated commerce services could also be possible. Or (to use a John Wulff example), imagine using your Netjuke to access your friend's CD-Ripping service to import a remote CD directly into your jukebox. See where we're going with this? I think the module API we currently have is becoming robust enough that we're going to see an influx of modules over the next several months. If we set the standards now, future modules can be simultaneously presentational and serviceable. Any thoughts on what makes a services API 'good' or better yet, how can we make our API excellent? Blake |
|
From: Blake W. <sb...@ib...> - 2004-04-15 03:24:15
|
Today I did some work streamlining the way eventing is handled between modules and the main Netjuke application. Increasingly, it is becoming desirable to pass around class names and portions of SQL queries to avoid some overhead and generally make the API easier to program. Some work I did in the search class passes around an array of database table references that could possibly become subject to SQL injection attacks. I'd like to go ahead and add a layer of security to the application in the next few days to put these concerns at ease. Obviously there are a couple of things to work out. We need a system for generating single use request id's, a system for cycling them out after a specified age, and an intelligent plan for when to use them so we don't sacrifice reusable URL's for things like artist page links that users would be likely to IM, email, blog, etc. Once we get the general design I think the easiest way to implement will be to provide auth_create_url or secure_create_url (with optional obfuscation of the request data), equivalent Smarty functions, and a Smarty insert function for inserting hidden auth_id inputs for forms. This should keep it very easy on the developer to avoid exposing security holes. Any thoughts? Blake |
|
From: James W. <wa...@wa...> - 2004-04-14 01:27:01
|
General comments - I agree this seems like a good idea... though, I
think the most important place for js & css to appear would be as part
of a theme / template pack, no? I've actually been thinking of doing my
own theme, just to keep familiar with the system, perhaps i'll begin
this - it will probably lead to more helpful comments from me.
-j
On 13-Apr-04, at 9:14 PM, Blake Watters wrote:
> I've been working very hard on UI related issues lately and I've come
> up with a few things up for discussion. I'm tentatively planning on
> adding custom javascript.php and css.php web endpoints to facilitate
> serving support files that might exist outside the document root or in
> module/template directories. As modules become more UI intensive and
> more likely to be living outside the document root for security
> reasons, I think this will be worth the effort. Aside from this, it
> will decrease page load times by breaking the monolithic JS/CSS model
> we've been on previously. The default.css file has already become a
> muddled mess and we have lots of UI work left.
>
> Also, processing CSS through PHP will allow for some slick themeing
> capabilities. I'm think that colors, fonts, and styles could be set
> via the database to facilitate Netjuke 1.x style themes and parsed to
> create a consistent, but themeable UI. Something like this:
>
> h1 {
> border: %border_width% px %border_style% #%border_color%;
> }
>
> With Smarty caching, this should be attainable while preserving a
> quick page load time.
>
> Thoughts?
>
> Blake
>
>
--
wa...@wa...
http://www.walkah.net/
|
|
From: Blake W. <sb...@ib...> - 2004-04-14 01:20:08
|
Alrighty then, we're in agreement. I'll implement library modules quickly and get the support into CVS. Migration of cc_license and getid3 are also included in this bundle. I'll have sourceforge strip those directories from CVS after the working implementation is committed. Dependencies are also on my radar and will be included in this also. Blake James Walker wrote: > On Tue, 2004-04-13 at 10:36, Blake Watters wrote: > >>Yes, I'm quite a fan of NuSOAP. My main point with the library module >>type is to insulate code that supports module development but is not >>required for Netjuke proper to run. The main libraries, with the >>exception of cc_license and getid3, are required for Netjuke to run at >>all and are so integrated with the system there could be no >>modularization. > > > It does make sense.. so would we move cc_license and getid3 into the new > library module system? > > >>Additionally, our modules system is database backed, so Adodb could >>never be migrated out of the core. NuSOAP and Amazon provide services >>which are strictly optional, but could be used by a number of modules >>implementing various functionality. Continuing to add libraries to our >>main codebase bloats the system, will drive page load time up, and >>introduces continuing complexity to the main system logic. With a >>module type we can implement developer friendly methods for on-demand >>loading of the support code and show a 'right' way for extending the >>system. Also, for modules which use common supporting code, we can >>keep them all on the same page with and take some of the burden off >>the module developer. Just ensure your code runs with the latest >>released library modules and you are set. > > > Ok, I'm sold, the only problem will be that we need a 'dependency' > concept within the module framework... I.E. cover_art module depends on > amazon module (which in turn depends on nusoap)... right? > > -j |
|
From: Blake W. <sb...@ib...> - 2004-04-14 01:10:02
|
I've been working very hard on UI related issues lately and I've come up
with a few things up for discussion. I'm tentatively planning on adding
custom javascript.php and css.php web endpoints to facilitate serving
support files that might exist outside the document root or in
module/template directories. As modules become more UI intensive and
more likely to be living outside the document root for security reasons,
I think this will be worth the effort. Aside from this, it will decrease
page load times by breaking the monolithic JS/CSS model we've been on
previously. The default.css file has already become a muddled mess and
we have lots of UI work left.
Also, processing CSS through PHP will allow for some slick themeing
capabilities. I'm think that colors, fonts, and styles could be set via
the database to facilitate Netjuke 1.x style themes and parsed to create
a consistent, but themeable UI. Something like this:
h1 {
border: %border_width% px %border_style% #%border_color%;
}
With Smarty caching, this should be attainable while preserving a quick
page load time.
Thoughts?
Blake
|
|
From: James W. <wa...@wa...> - 2004-04-13 14:57:21
|
On Tue, 2004-04-13 at 10:36, Blake Watters wrote: > Yes, I'm quite a fan of NuSOAP. My main point with the library module > type is to insulate code that supports module development but is not > required for Netjuke proper to run. The main libraries, with the > exception of cc_license and getid3, are required for Netjuke to run at > all and are so integrated with the system there could be no > modularization. It does make sense.. so would we move cc_license and getid3 into the new library module system? > Additionally, our modules system is database backed, so Adodb could > never be migrated out of the core. NuSOAP and Amazon provide services > which are strictly optional, but could be used by a number of modules > implementing various functionality. Continuing to add libraries to our > main codebase bloats the system, will drive page load time up, and > introduces continuing complexity to the main system logic. With a > module type we can implement developer friendly methods for on-demand > loading of the support code and show a 'right' way for extending the > system. Also, for modules which use common supporting code, we can > keep them all on the same page with and take some of the burden off > the module developer. Just ensure your code runs with the latest > released library modules and you are set. Ok, I'm sold, the only problem will be that we need a 'dependency' concept within the module framework... I.E. cover_art module depends on amazon module (which in turn depends on nusoap)... right? -j -- wa...@wa... http://www.walkah.net/ |
|
From: Blake W. <sb...@ib...> - 2004-04-13 14:43:24
|
Yes, I'm quite a fan of NuSOAP. My main point with the library module type is to insulate code that supports module development but is not required for Netjuke proper to run. The main libraries, with the exception of cc_license and getid3, are required for Netjuke to run at all and are so integrated with the system there could be no modularization. Additionally, our modules system is database backed, so Adodb could never be migrated out of the core. NuSOAP and Amazon provide services which are strictly optional, but could be used by a number of modules implementing various functionality. Continuing to add libraries to our main codebase bloats the system, will drive page load time up, and introduces continuing complexity to the main system logic. With a module type we can implement developer friendly methods for on-demand loading of the support code and show a 'right' way for extending the system. Also, for modules which use common supporting code, we can keep them all on the same page with and take some of the burden off the module developer. Just ensure your code runs with the latest released library modules and you are set. In short, I'd like to get away from adding _any_ more support libraries to the lib/ directory and move out the non-core parts as well. I just know that as we begin adding crazy new features there is going to be a growing need for external libraries and I don't want the core bloating just to support feature x, y, and z. Blake On Thu, 8 Apr 2004 10:43:36 -0400 James Walker <wa...@wa...> wrote: > On 8-Apr-04, at 7:39 AM, Blake Watters wrote: > > I'm open to debate on this, but I think the best thing to do here to > > avoid overlap in modules is going to be to make library modules out of > > the NuSOAP and Amazon components and then write an album art grabber > > that uses the Amazon module, which in turn uses the NuSOAP module, to > > perform the web services transactions. This way we can keep them up to > > date and make the functionality as reusable as possible. > > Well, that settles my first question which was: "do you have a > preferred SOAP implementation, mine's NuSOAP" :P > > However, I'm not sure why these would need to be Netjuke modules... we > already use other libraries - smarty, adodb, etc without having a > 'library module' type. Why would NuSOAP (or even an Amazon API module) > change that? > > > I guess the idea of a library module probably warrants a fourth type > > of module be added. Library modules should be always active, not > > loaded during load_modules (), and we'll provide some helper methods > > for verifying they exist, checking the version number, and loading > > them for use. > > that does make some sense, but if we're bundling them in lib/ (and > presumably distributing them in the tarball) .. is that really > necessary? Why wouldn't the cover art fetcher just include (require) > it's needed libs? > > > However implemented, album art will be a welcome, slick addition to > > the system. I'll get the album detail page template after I finish > > the search work. > > I totally agree, I've always loved album art (it's my main attraction > to vinyl). I'm a huge fan of "clutter" for OSX > (http://www.sprote.com/clutter/) which fetches album art from amazon > and displays it in a little 'now playing' box - modules like mpd could > make use of something like this. It's enormously helpful with large > collections, when you don't instantly recognize _every_ song. It is > also visually appealing, and makes for a nice interface for the album > detail page :) > > -James > -- > wa...@wa... > http://www.walkah.net/ |
|
From: John W. <jo...@or...> - 2004-04-09 03:59:52
|
> I don't think I have any super powers.. and I'm mostly interested in > the code, but I'd be happy to assist in the forums or otherwise. You are in the super group on the forums :). > On 7-Apr-04, at 9:55 PM, Blake Watters wrote: >> I've just brought on a third possible dev and graphics guy > > super! who is it? > >> -- I think we should try keeping on correspondence on netjuke-dev >> mailing list from now on. I'll be back-posting emails from the last >> week or so to the list to get it up to speed. Also the orkut community >> and the other project-centric activities need to make it onto the >> homepage as news or something. > > indeed > >> James - Do we have you flagged with any status on Netjuke.org yet? Do >> you have any interest in screwing with the forums, news, or any of >> that other crap? > > I don't think I have any super powers.. and I'm mostly interested in > the code, but I'd be happy to assist in the forums or otherwise. > > -j > > > - John Wulff ~~~~~~~~~~~~~~~~~~~~ Work: (360) 376-6095 Cell: (360) 317-6447 ~~~~~~~~~~~~~~~~~~~~ |
|
From: James W. <wa...@wa...> - 2004-04-08 14:43:45
|
On 8-Apr-04, at 7:39 AM, Blake Watters wrote: > I'm open to debate on this, but I think the best thing to do here to > avoid overlap in modules is going to be to make library modules out of > the NuSOAP and Amazon components and then write an album art grabber > that uses the Amazon module, which in turn uses the NuSOAP module, to > perform the web services transactions. This way we can keep them up to > date and make the functionality as reusable as possible. Well, that settles my first question which was: "do you have a preferred SOAP implementation, mine's NuSOAP" :P However, I'm not sure why these would need to be Netjuke modules... we already use other libraries - smarty, adodb, etc without having a 'library module' type. Why would NuSOAP (or even an Amazon API module) change that? > I guess the idea of a library module probably warrants a fourth type > of module be added. Library modules should be always active, not > loaded during load_modules (), and we'll provide some helper methods > for verifying they exist, checking the version number, and loading > them for use. that does make some sense, but if we're bundling them in lib/ (and presumably distributing them in the tarball) .. is that really necessary? Why wouldn't the cover art fetcher just include (require) it's needed libs? > However implemented, album art will be a welcome, slick addition to > the system. I'll get the album detail page template after I finish > the search work. I totally agree, I've always loved album art (it's my main attraction to vinyl). I'm a huge fan of "clutter" for OSX (http://www.sprote.com/clutter/) which fetches album art from amazon and displays it in a little 'now playing' box - modules like mpd could make use of something like this. It's enormously helpful with large collections, when you don't instantly recognize _every_ song. It is also visually appealing, and makes for a nice interface for the album detail page :) -James -- wa...@wa... http://www.walkah.net/ |
|
From: Blake W. <sb...@ib...> - 2004-04-08 11:37:42
|
I'm open to debate on this, but I think the best thing to do here to avoid overlap in modules is going to be to make library modules out of the NuSOAP and Amazon components and then write an album art grabber that uses the Amazon module, which in turn uses the NuSOAP module, to perform the web services transactions. This way we can keep them up to date and make the functionality as reusable as possible. I guess the idea of a library module probably warrants a fourth type of module be added. Library modules should be always active, not loaded during load_modules (), and we'll provide some helper methods for verifying they exist, checking the version number, and loading them for use. However implemented, album art will be a welcome, slick addition to the system. I'll get the album detail page template after I finish the search work. Thoughts? Blake James Walker wrote: > ok, having just checked out a post in the beta forum on album art... i > think that'll be my first module. -- 'cause it's one i'd really like :) > > so, unless there are any major objections, i'll get started on an amazon > module (which initially will snag album art). > > blake - get ready for questions over the next several days ;) > > On Tue, 2004-04-06 at 00:57, Blake Watters wrote: > >>James and John - >> >>Alright, I wrote this damned thing earlier today and lost it in a >>reboot. John and I have decided to publish weekly Netjuke updates to >>spur buzz about the project, keep us on task, and keep the community >>aware of what madness we are up to. >> >>This week's tasks: >>- Finish installer configurations >>- Integrate playlist functionality >>- Complete advanced search options >>- As much admin functionality as possible >>- Improve front-page interface design. Anything is better than it is now >>- Migrate nightly builds to default template set >>- Make search results sortable by genre/artist/album etc. >>- Groups editor >> >>Other stuff: >>- Investigate why phpBB and PostNuke accounts aren't synced all the >>time. It's annoying as hell >>- Ramp up recruitment effort for devs and graphics people >>- Update the site with Netjuke2 screenshots >>- Revitalize the mailing lists >>- Get some relevant documentation onto the netjuke.org site as time allows. >>- John is now maintaining the MPD PHP class >> >>Misc: >>- Do you think we should start splitting the CSS into separate files? It >>would make it easier to find things when editing on a page by page basis >>and could decrease the page load time some insignificant amount... I'm >>thinking defaults/styles/<endpoint-name>.css |
|
From: Jason S. <jas...@co...> - 2004-03-23 19:06:53
|
I tried upgrading and found that the update db scripts for postgres7 were just copied from the mysql scripts. So they didn't work at all. I rewrote them and fixed all the errors to find that the browse feature didn't work in rc2. Luckily I did a database dump before I attempted the upgrade so it was easy to revert back to rc1. I sent this list an e-mail with the upgrade scripts a few weeks ago and haven't heard from them since. While fixing the scripts I seem to remember running into a similar problem you had. It had something to do with the default user theme in the db not syncing with any themes in the db and the users theme settings also not syncing with the themes in the db. Something like that. HTH Jason Steve Lacy wrote: > I realize that the binary content and the rest of my message seems to > have been truncated, so I'll repeat my comments here again: > > - I tried going through the regular install process from the beginning, > and got the same results (just a binary-looking file instead of > inc-prefs.php). I also tried "view source" and saw the same binary > file. If you're interested, I can save and attach that file. Where did > it come from and who generated it? (and why?) > > - I have now tried to go back to my RC1 install, and now I cannot log > in. When I press the "login" button, it just returns me to login.php, > with no "access denied" dialog or anything, so I'm completely locked out > of my music collection. > > - I've tried going through the "upgrade" process on my RC1 install, and > I get the same results -- a binary file instead of inc-prefs.php. I > haven't tried doing an RC1 install from scratch, but I suspect that the > results will be the same. > > If/when I get this working, I'm going to seriously consider rewriting > your entire install process, and consider storing all the preferences in > the database instead of using this silly inc-prefs.php nonsense. Its > perilously error-prone, difficult to use, and extremely annoying. I've > been a netjuke user for 2+ years, and now I'm completely locked out of > my music collection. At least I can still get at the database and mp3 > files. > > Steve > > Steve Lacy wrote: > >> Hello, >> >> I have a successfully netjuke install of 1.0-rc1, and I'm trying to >> upgrade to rc2. >> >> When I go through the upgrade process, at the point where I should be >> asked to save inc-prefs.php, it presents me with a binary file. The >> contents look like this: >> >> ? >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Netjuke-devel mailing list >> Net...@li... >> https://lists.sourceforge.net/lists/listinfo/netjuke-devel > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Netjuke-devel mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netjuke-devel > |
|
From: Steve L. <sl...@sl...> - 2004-03-23 18:29:57
|
I realize that the binary content and the rest of my message seems to have been truncated, so I'll repeat my comments here again: - I tried going through the regular install process from the beginning, and got the same results (just a binary-looking file instead of inc-prefs.php). I also tried "view source" and saw the same binary file. If you're interested, I can save and attach that file. Where did it come from and who generated it? (and why?) - I have now tried to go back to my RC1 install, and now I cannot log in. When I press the "login" button, it just returns me to login.php, with no "access denied" dialog or anything, so I'm completely locked out of my music collection. - I've tried going through the "upgrade" process on my RC1 install, and I get the same results -- a binary file instead of inc-prefs.php. I haven't tried doing an RC1 install from scratch, but I suspect that the results will be the same. If/when I get this working, I'm going to seriously consider rewriting your entire install process, and consider storing all the preferences in the database instead of using this silly inc-prefs.php nonsense. Its perilously error-prone, difficult to use, and extremely annoying. I've been a netjuke user for 2+ years, and now I'm completely locked out of my music collection. At least I can still get at the database and mp3 files. Steve Steve Lacy wrote: > Hello, > > I have a successfully netjuke install of 1.0-rc1, and I'm trying to > upgrade to rc2. > > When I go through the upgrade process, at the point where I should be > asked to save inc-prefs.php, it presents me with a binary file. The > contents look like this: > > ? > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Netjuke-devel mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netjuke-devel |
|
From: Steve L. <sl...@sl...> - 2004-03-23 18:09:52
|
Hello, I have a successfully netjuke install of 1.0-rc1, and I'm trying to upgrade to rc2. When I go through the upgrade process, at the point where I should be asked to save inc-prefs.php, it presents me with a binary file. The contents look like this: ? |
|
From: Jason S. <jas...@co...> - 2004-03-05 16:29:28
|
I just upgraded to rc2 from b17 and I had to tweak the sql scripts for postgres7. Here are my changes. Enjoy! Jason |
|
From: Steve <sp...@pe...> - 2004-02-20 23:34:14
|
Guess I'll stick with Netjuke 1, then. Good luck. Blake Watters wrote: >Hello Netjukers! > >I have been rather quite for some time now and I thought I should reach = out to the community to alleviate any fears about this project's status, = announce some news, and generally reestablish my leadership role. First, = let me say that Netjuke is far from dead. In the last two months I have b= een working exclusively on Netjuke2 and the application is nearly complet= e, after almost 1 year in development. There are still major UI holes and= work does remain, but the backend is complete and the project is nearly = feature complete according to my original spec.=20 > >Netjuke 2's precise release date is not yet known and is subject to some= other non-technical issues that I must deal with. Netjuke2 may be releas= ed under a different license than the BSD/GPL, but I am not yet sure. I a= m currently bootstrapping a business around providing Netjuke2 as a compl= ete media management and commerce solution for record labels and distribu= tors, in addition to an insanely powerful jukebox for the rest of us. As = such, some modules (most particularly those related to business/commerce)= will NOT be available as Open Source in any form -- they will be proprie= tary code built on the Netjuke2 platform available for license from me. I= am trying very hard to make Netjuke my primary source of income so that = I may continue pushing the envelope of media management on the PHP progra= mming language. These efforts may leave the application in an unreleased = state for a time even after completion. > >Now, with that out of the way I'd like to hype up Netjuke2 a bit by enum= erating some of the many features. > >- Built using object oriented PHP 4, ready for migration to PHP 5 once i= t stabilizes >- Features a powerful module system for extensibility >- Abstracts access to the database through a consistent API >- Powerful error handling mechanism eliminates mysterious breakage >- Built on the Smarty template engine for presentation >- Entirely themeable using template sets -- hack a predefined template o= r create an entirely new look >- Database abstraction improved through use of dynamic SQL generation te= chniques >- Fully relational database design allows for an infinite number of song= , album, genre, artist, and property interrelations among media. Express = everything about your media >- Infinite number of images, clips, and files may be associated with a s= ong >- Proper handling of compilations >- Extremely scalable >- Capable of providing virtual hosted installations, run multiple sites = from same source code >- Preferred playlist and media format preferences available to users >- Powerful Access Control List (ACL) system provides fine grained contro= l of access to media and other objects within the system >- Integrated log4php logging system provides detailed logging of what is= happening inside the system >- Source code is fully documented in PHPDocumentor markup >- Full support for Windows host systems (I develop on Windows, Mac OS X,= and Linux simultaneously) >- Temporary playlists >- Dynamic preview generation >- Transcoding support >- Pluggable media format support >- Easier automation through the ScheduledTasks module >- Pluggable admin interface allows for cleaner customization >- True high performance session support >- Pluggable playlist type support (currently m3u and asx) >- Removal of requirement for media to be centralized. Media is stored on= an infinite number of media roots which do not need to exist inside the = Apache document root >- Better localization and internationalization >- Extensible user data (add AIM SN's, other contact info, sex, age, etc)= >- New browsing friendly interface greatly surpasses table based/search b= ased interface of 1.x >- Other stuff I forgot or haven't done yet :) > >Currently supported media types: >- MP3 (read, write, encode, decode) >- Ogg-Vorbis (read, write, encode, decode) >- Ogg-FLAC (read, write, encode, decode) >- Windows Media (read) >- Apple AAC (read) > >In the works: >- MPD Integration >- Album wrap support >- More media formats >- Installer > >As you can see, I have been quite busy. I've tried to address as many of= the needs/requests as possible. This application is HUGE compared to Net= juke 1.x and the overall quality & maintainability of the code has gone u= p significantly. I can say with no ego that this is a nice piece of softw= are. :) > >So, it's not quite ready yet. The project isn't dead by a long shot. So = now is the part where you guys come in. I'd like to offer between 20 and = 30 Netjukers the opportunity to test my current test site and work with m= e on improving the interface, squashing bugs, and just generally keeping = me motivated as I complete this dreaded interface stuff (I'm definitely m= ore of a backend programmer, but the skills are improving). I'm doing thi= s way down at the bottom because if you bailed on me before now, there's = no way you'd make a good tester anyhow.=20 > >Responses should be addressed to me at sb...@ib... with the subject = 'Netjuke2 Beta Test' and you should allow up to one week for a reply. If = you bother me, you'll be silently ignored. Just send me your name, electr= onic contact info (email, AIM, etc), some information about how you use N= etjuke & any requests/complaints, and a bit about your skill level with P= HP, SQL, and web applications in general. This last bit isn't because I a= m looking for techies -- I want a good cross-section of users from the mo= st naive to the most sophisticated playing with the application. I'll sen= d more information once the beta team has been assembled. > >Thanks and happy streaming! >- Blake > >-- >Blake Watters >Lead Developer, The Netjuke Project >Email: sb...@ib... >AIM: initgraf > =20 > |
|
From: Blake W. <sb...@ib...> - 2004-02-20 21:30:18
|
Hello Netjukers! I have been rather quite for some time now and I thought I should reach out to the community to alleviate any fears about this project's status, announce some news, and generally reestablish my leadership role. First, let me say that Netjuke is far from dead. In the last two months I have been working exclusively on Netjuke2 and the application is nearly complete, after almost 1 year in development. There are still major UI holes and work does remain, but the backend is complete and the project is nearly feature complete according to my original spec. Netjuke 2's precise release date is not yet known and is subject to some other non-technical issues that I must deal with. Netjuke2 may be released under a different license than the BSD/GPL, but I am not yet sure. I am currently bootstrapping a business around providing Netjuke2 as a complete media management and commerce solution for record labels and distributors, in addition to an insanely powerful jukebox for the rest of us. As such, some modules (most particularly those related to business/commerce) will NOT be available as Open Source in any form -- they will be proprietary code built on the Netjuke2 platform available for license from me. I am trying very hard to make Netjuke my primary source of income so that I may continue pushing the envelope of media management on the PHP programming language. These efforts may leave the application in an unreleased state for a time even after completion. Now, with that out of the way I'd like to hype up Netjuke2 a bit by enumerating some of the many features. - Built using object oriented PHP 4, ready for migration to PHP 5 once it stabilizes - Features a powerful module system for extensibility - Abstracts access to the database through a consistent API - Powerful error handling mechanism eliminates mysterious breakage - Built on the Smarty template engine for presentation - Entirely themeable using template sets -- hack a predefined template or create an entirely new look - Database abstraction improved through use of dynamic SQL generation techniques - Fully relational database design allows for an infinite number of song, album, genre, artist, and property interrelations among media. Express everything about your media - Infinite number of images, clips, and files may be associated with a song - Proper handling of compilations - Extremely scalable - Capable of providing virtual hosted installations, run multiple sites from same source code - Preferred playlist and media format preferences available to users - Powerful Access Control List (ACL) system provides fine grained control of access to media and other objects within the system - Integrated log4php logging system provides detailed logging of what is happening inside the system - Source code is fully documented in PHPDocumentor markup - Full support for Windows host systems (I develop on Windows, Mac OS X, and Linux simultaneously) - Temporary playlists - Dynamic preview generation - Transcoding support - Pluggable media format support - Easier automation through the ScheduledTasks module - Pluggable admin interface allows for cleaner customization - True high performance session support - Pluggable playlist type support (currently m3u and asx) - Removal of requirement for media to be centralized. Media is stored on an infinite number of media roots which do not need to exist inside the Apache document root - Better localization and internationalization - Extensible user data (add AIM SN's, other contact info, sex, age, etc) - New browsing friendly interface greatly surpasses table based/search based interface of 1.x - Other stuff I forgot or haven't done yet :) Currently supported media types: - MP3 (read, write, encode, decode) - Ogg-Vorbis (read, write, encode, decode) - Ogg-FLAC (read, write, encode, decode) - Windows Media (read) - Apple AAC (read) In the works: - MPD Integration - Album wrap support - More media formats - Installer As you can see, I have been quite busy. I've tried to address as many of the needs/requests as possible. This application is HUGE compared to Netjuke 1.x and the overall quality & maintainability of the code has gone up significantly. I can say with no ego that this is a nice piece of software. :) So, it's not quite ready yet. The project isn't dead by a long shot. So now is the part where you guys come in. I'd like to offer between 20 and 30 Netjukers the opportunity to test my current test site and work with me on improving the interface, squashing bugs, and just generally keeping me motivated as I complete this dreaded interface stuff (I'm definitely more of a backend programmer, but the skills are improving). I'm doing this way down at the bottom because if you bailed on me before now, there's no way you'd make a good tester anyhow. Responses should be addressed to me at sb...@ib... with the subject 'Netjuke2 Beta Test' and you should allow up to one week for a reply. If you bother me, you'll be silently ignored. Just send me your name, electronic contact info (email, AIM, etc), some information about how you use Netjuke & any requests/complaints, and a bit about your skill level with PHP, SQL, and web applications in general. This last bit isn't because I am looking for techies -- I want a good cross-section of users from the most naive to the most sophisticated playing with the application. I'll send more information once the beta team has been assembled. Thanks and happy streaming! - Blake -- Blake Watters Lead Developer, The Netjuke Project Email: sb...@ib... AIM: initgraf |
|
From: Blake W. <sb...@ib...> - 2004-02-18 20:39:10
|
Hi all - I've already addressed this issue in Netjuke2. All songs now have meta tables (netjuke_song_artists, netjuke_song_albums, etc) which allow an infinite number of 1 to many relationships for a given meta field to a song. This allows you to handle both songs on albums by different artists and express things such as songs with artists featuring other artists, etc. Basically the operating theory is that each metadata node (song, album, artist, genre) has relations to other fields. This escapes the 'flat' metaphor of Netjuke 1 and should allow for a more richer management and usage experience. Blake On Wed, 18 Feb 2004 10:43:46 -0500 "Daniel Blake" <dan...@tc...> wrote: > I think I have noticed a problem with the suggested change to the database. > There are many cd's that are compilations where each track is by a different > artist. > > What would be the result of the suggested change to the database in this > instance? > > Daniel Blake > > > >>I have a suggested change to the DB for the new version. > >> > >>From my DB experience, I believe the tracks table should only include > the albumsID and the albums table should include the artistsID. You > shouldn't have to specify the artists ID for each track. You already > specify the album ID for each track which would already give us the > artists info from the album (if album contained the ar_id). > > Thanks for the time! This program does ROCK! > > -Rob > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Netjuke-devel mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netjuke-devel |
|
From: stark <st...@je...> - 2004-02-18 16:55:48
|
DEFINITELY! I really rely on being able to have a CD with a different artist for each track! It helps with making virtual discs as well : I can group my "best 50 of all time" into an album (yeah, I could make it a shared playlist, but this works too :) and each song has a different artist associated with it. Dana Lacoste San Diego On Wed, 2004-02-18 at 07:43, Daniel Blake wrote: > I think I have noticed a problem with the suggested change to the database. > There are many cd's that are compilations where each track is by a different > artist. > > What would be the result of the suggested change to the database in this > instance? > > Daniel Blake > > > >>I have a suggested change to the DB for the new version. > >> > >>From my DB experience, I believe the tracks table should only include > the albumsID and the albums table should include the artistsID. You > shouldn't have to specify the artists ID for each track. You already > specify the album ID for each track which would already give us the > artists info from the album (if album contained the ar_id). > > Thanks for the time! This program does ROCK! > > -Rob > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Netjuke-devel mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netjuke-devel |
|
From: Daniel B. <dan...@tc...> - 2004-02-18 15:48:51
|
I think I have noticed a problem with the suggested change to the database. There are many cd's that are compilations where each track is by a different artist. What would be the result of the suggested change to the database in this instance? Daniel Blake >>I have a suggested change to the DB for the new version. >> >>From my DB experience, I believe the tracks table should only include the albumsID and the albums table should include the artistsID. You shouldn't have to specify the artists ID for each track. You already specify the album ID for each track which would already give us the artists info from the album (if album contained the ar_id). Thanks for the time! This program does ROCK! -Rob |
|
From: Xavier B. <xb...@in...> - 2003-12-22 21:37:02
|
Hi, [I had no luck with the forum, so maybe the mailing-list will be more responsive ?] I'd like to code in the cvs version so I wanted to install it. I tried to follow the README.txt in /dev but have encountered various errors. The SQL has problems. I fixed it like this : $ cvs diff cvs server: Diffing . Index: install_netjuke_groups.sql =================================================================== RCS file: /cvsroot/netjuke/netjuke2/dev/sql/install_netjuke_groups.sql,v retrieving revision 1.4 diff -r1.4 install_netjuke_groups.sql 14,16c14,16 < INSERT INTO `netjuke_groups` VALUES (1, 'Administrators', 'Administrators have full access to all features of the Netjuke media platform and can change the system\'s configuration.'); < INSERT INTO `netjuke_groups` VALUES (2, 'Editors', 'Editors have full control over all media in the Netjuke archive. This includes full read and write permissions to the database and the metadata tags of managed media content.'); < INSERT INTO `netjuke_groups` VALUES (3, 'Users', 'Users are the most basic group in the media system. They have read-only access to managed media content.'); \ No newline at end of file --- > INSERT INTO `netjuke_groups` (`id`, `name`, `description`) VALUES (1, 'Administrators', 'Administrators have full access to all features of the Netjuke media platform and can change the system\'s configuration.'); > INSERT INTO `netjuke_groups` (`id`, `name`, `description`) VALUES (2, 'Editors', 'Editors have full control over all media in the Netjuke archive. This includes full read and write permissions to the database and the metadata tags of managed media content.'); > INSERT INTO `netjuke_groups` (`id`, `name`, `description`) VALUES (3, 'Users', 'Users are the most basic group in the media system. They have read-only access to managed media content.'); \ No newline at end of file Index: install_netjuke_pages.sql =================================================================== RCS file: /cvsroot/netjuke/netjuke2/dev/sql/install_netjuke_pages.sql,v retrieving revision 1.1 diff -r1.1 install_netjuke_pages.sql 6c6 < `date_added` datetime NOT NULL default now(), --- > `date_added` datetime NOT NULL, Now i have that : Fatal error: Call to a member function on a non-object in /hdc9/brol/netjuke2/modules/core/plugin.recursive_import.php on line 104 What should I do ? Thank you, Xavier |
|
From: Rob R. <ros...@al...> - 2003-12-19 22:13:08
|
> -----Original Message----- > From: net...@li... [mailto:netjuke-devel- > ad...@li...] On Behalf Of Rob > Sent: Friday, December 19, 2003 2:41 PM > Subject: [Netjuke-devel] Database Change (artists/albums/tracks tables) > > I have a suggested change to the DB for the new version. > > Actual Change to DB: > - Move ar_id from tracks table to albums table. > > >From my DB experience, I believe the tracks table should only include > the albumsID and the albums table should include the artistsID. You > shouldn't have to specify the artists ID for each track. You already > specify the album ID for each track which would already give us the > artists info from the album (if album contained the ar_id). What about tracks from compilation/various artists albums? |
|
From: Rob <ne...@cu...> - 2003-12-19 19:41:43
|
I have a suggested change to the DB for the new version. Why I found the suggested change: - I wanted to see the artists in the HTML "title" (mouse over) on the main page of netjuke where it shows latest albums. Took a look database, and I found I could not just grab the Artists ID from the Album table. Current way of including the Artist from Album table: - inner join netjuke_tracks on netjuke_albums.id = netjuke_tracks.al_id - inner join netjuke_artists on netjuke_tracks.ar_id = netjuke_artists.id Actual Change to DB: - Move ar_id from tracks table to albums table. >From my DB experience, I believe the tracks table should only include the albumsID and the albums table should include the artistsID. You shouldn't have to specify the artists ID for each track. You already specify the album ID for each track which would already give us the artists info from the album (if album contained the ar_id). Thanks for the time! This program does ROCK! -Rob |
|
From: Brandon K. <kni...@bl...> - 2003-12-09 00:16:25
|
I didn't like the fact that my MP3 collection had to be live on the internet,
albeit with no directory listing. Even the obfiscated stuff is no help as it
would simply mask the url, and it was easy to get the 302 and then send it to
all my friends. YUCK!
I made this simple little patch to make this all better! :) Am I missing
something here which precludes this from working for everyone?
== diff ==
*** /home/knitterb/src/netjuke/netjuke/play.php Mon Jul 14 16:07:44 2003
--- ./play.php Mon Dec 8 16:05:18 2003
***************
*** 98,105 ****
# experimental on the fly reencoding, remove comment to use it!
# reencodeOnTheFly(MUSIC_DIR."/".rawurldecode($location),
$dbrs->fields[1], $dbrs->fields[2], $dbrs->fields[3]);
# send the track to the user's player
! header ( "Location: ".expandLocation($location) );
}
}
--- 98,113 ----
# experimental on the fly reencoding, remove comment to use it!
# reencodeOnTheFly(MUSIC_DIR."/".rawurldecode($location),
$dbrs->fields[1], $dbrs->fields[2], $dbrs->fields[3]);
+ # send this without a stupid redir
+ $fileloc=MUSIC_DIR."/".rawurldecode($location);
+ header("Content-type: audio/mp3");
+ header("Content-Length: ".filesize($fileloc));
+ $fp=fopen($fileloc, "r");
+ fpassthru($fp);
+ fclose($fp);
+
# send the track to the user's player
! # header ( "Location: ".expandLocation($location) );
}
}
== END diff ==
Basically I just made the PHP script do a passthru of the file. This makes it
so that with the obsficated urls, you now have to have the session. I would add
a timestamp to the url as well, and make that only work for "x" hours also.
That should really help lock things down. Oh yeah, lock it down to an ip as
well in the database with the timestamp. That'll come next.
Please let me know if I'm missing the boat on something here.
Thanks,
--
-bk
|
|
From: Brett E. <br...@sp...> - 2003-11-16 19:02:30
|
Greetings! While I've been poking through the NetJuke source for a couple = of days, this is my first post to the developers list. I've also been a de= veloper on RIMPS (another networked media management system) for some time.= I'd like to get more involved with NetJuke... In fact, I've already found= something I'd like to do. However, before I get started, I wanted to run = it by the development community to make sure it doesn't fly in the face of = established conventions that I haven't been able to ascertain from the docu= mentation or source.=0A=0AProposal: NetJuke-mediated Streaming=0A=0AAbstra= ct: Integration of an option that would allow NetJuke to be =0A called w= ith a specially constructed URL that would then cause =0A NetJuke to act= ively stream back the file over the connection. =0A=0AAdvantages:=0A * = Media files are not required to be in the web server document root=0A * = Easier library management-- You no longer need to be concerned =0A a= bout how clients will access titles. Once NetJuke has located =0A a= file it knows how to serve it up automatically.=0A * NetJuke is aware o= f the files that are playing. This would allow:=0A + A screen that = displays to a user what is currently playing. =0A This could se= t to automatically refresh and "monitor" what =0A you are playin= g.=0A + Administrators could see everything that is playing and by= =0A whom=0A + Modification of playlists based on what is = playing... Add a =0A current track to a "favorites" playlist, or= remove the current=0A track from the playlist so you won't hear= it next time you =0A access the same list.=0A * Enforcement = of access rights. (This is already there to some degree=0A in the "p= rotect media" option. But since it just uses a redirect=0A it is re= latively simple for me to figure out the actual location and=0A by p= ass the "protection" in the future.)=0A * Platform for re-encoding on th= e fly (we are already streaming the =0A file, it would be relatively= simple to pipe it through LAME or =0A other media encoder along the= way). Could potentially even do=0A transcoding from one format to = another.=0A * Dynamic, server-controlled playlists-- By setting the medi= a player=0A to loop on a playlist with a single track, NetJuke could= serve up=0A a different track with each loop over the playlist. Ne= tJuke could=0A even terminate a track early and start up the next on= e. The=0A server could determine the actual track to play at reques= t time.=0A * Better play stats possible... You could not track that the = title had =0A been listened to unless it was at least half done, or = listened to=0A for more than x seconds. Or you could just track how= long it was=0A played.=0A * Control... Seems like lots of other= cool things might be possible=0A in the future with the increased c= ontrol NetJuke would have over=0A the media files.=0A=0ADisadvantage= s:=0A * Increased resource usage on the hosting server (but should be = =0A fairly minimal unless re-encoding on the fly).=0A * Limited s= eeking support? Some clients may not know how to=0A use the range h= eader to seek in the stream (WinAmp works=0A great). In theory, see= king could be done by the server... you =0A tell it you want to jump= ahead, and it seeks forward in the stream=0A it is currently servin= g=0A * others?=0A=0AMethodology Overview:=0A * Create new preference = "Mediated Streaming" on/off=0A * Create new file "stream.php"=0A * Mo= ve dispatch functions from play.php to stream.php=0A * Modify track loca= tions in play.php to reference stream.php if =0A mediated streaming = is turned on. Build URL like:=0A http://server.com/stream.php/encod= ed/data/here/artist-track.mp3=0A * Based on the "encoded data" passed in= , look up the track in the db=0A * Stream the track over the open connec= tion=0A=0A=0AOverall, I think this would make a great addition to NetJuke, = and unless I completely misunderstand how the majority of folks are using N= etJuke (usually serving files over HTTP), and assuming that this idea actua= lly pans out, I think this would quick become the default and recommended w= ay of serving up files. =0A=0AThanks in advance for your consideration,=0A= =0ABrett=0A=0A |
1 message has been excluded from this view by a project administrator.