During the past few months creating SceneDDL, it became increasingly annoying making changes to the code. The code is currently based on an experiment I was doing while bored to see if I could make a Rapidshare uploader that automated everything from RARing to posting the links. Naturally, being the genius that I am (not a gay fish), I was successful, and in typical Me fashion, I expanded upon messy code.
The code was originally only meant for the Rapidshare Remote Upload thingy (which sucks), used Torrentflux (which is the biggest lump of shit ever) as a means of downloading and interracted very poorly with Wordpress, however the code in use now is built upon that same suckfest foundation and really should never have been allowed to get as far as it is now, which is why I started planning Edrad.
Edrad is, for all intents and purposes, SceneDDL V2, although the end-user will not see what goes on behind the scenes. The main goal is to create an easily extendable application for the purposes of automating everything from downloading to posting, which is why Edrad uses a plugin model over the current "everything in one big function" model.
The Edrad system is designed to offer the maximum possible customization for the least amount of effort. Below is a rough overview of the components involved.
Core
The core handles all of the external plugin systems, and several built in core core systems. It also handles the definitions of release sections and each section's specific rules.
Packer Plugin
The packer plugin is built in to the core. It handles the RARing of each release once the files are complete on the local hard disk, based on each section's rules and each upload plugin's maximum file size specifications.
Download Plugin
The download plugin manager handles all plugins related to getting releases on to the local hard disk. By default it will come with support for FTP, Usenet and Bittorrent.
Upload Plugin
The upload plugin manager handles all plugins related to uploading files provided by the packer plugin to the remote file host providers. Planned default plugins are Rapidshare, Netload and UploadJockey.
Publisher Plugin
The publisher plugin manager handles all plugins related to publishing the links provided by the upload plugins to the interwebs. The only default plugin will be WordPress.
Content Plugin
The content plugin manager handles the bbcode-based modification of post templates provided by the publisher plugins in order to add additional dynamic content, such as TVRage links. The only default plugin will IMDB.
All external plugins are compiled using a C++ API provided with the Edrad SDK. There may be a scripting language (such as TCL) added at some point in the future.
Developers may submit their plugin to the official Edrad plugin database in order to recieve an authorization code to be passed from their plugin to Edrad. Developers of authorized Edrad plugins will have the benefit of being eligible for a share of the license fee from each user that uses their plugin. The planned formula is as follows
Revenue = LicenseCost(20%) / TotalLoadedPlugins
The plan for license costs is for it to be reasonably priced depending on the intended use, which means each license will be limited to a maximum number of plugins. Charging people for IMDB links would be a tad lame I realise, which is why some plugin types will not count as a whole plugin, and some will not count as a plugin at all.
I hope this has been informative. It certainly gave me a chance to clear my head.
22 comments:
Thanks Jay , I will be waiting for the official release.
Wow! I thought it was all done using canned packages written by elves. Thanks for all the hard work.
WOW! It seems well organized and modular . waiting for the release
are u release to public?
Sounds great :D
Can't wait till it gets finally released.
@Jay: How many upload/download servers can Edrad handle?
What is Edrad coded in?
Server clustering is on the todo list and is planned to be used for disseminating files for user uploaded content. Edrad is coded in C++.
@Jay: WTF? C++ on debian? How does it works? Debian can't run C++ (.exe) files without an emulator like wine.
i love the above retard on the assumptions of binary files. infact i wonder how he even knows what debian even is
I'm lost for words. Please get off the internet.
I don't get this whole Edrad thing, this is too much for my little brain. But nevertheless, why did you remove the little upload queue box from the main site? It was always nice to see what will be uploaded next without needing to click on a different page.
Why C++? If you are looking for optimization, C++ is not a good choice. If you are looking for extensibility, again, C++ is not a good choice. C++ does strike a balance between the two, but not a very good one.
C is much better suited for writing good, efficient, and optimized code. It can handle "plugins" too. You can even use glib to help implement an object oriented design, but I personally dislike it.
Python is much better suited for writing extensible code. You take a performance hit, but few things can compete with its flexibility and ability to load runtime code.
Without getting into a language war, observe that few developers use C++ for web based applications. Most prefer some scripting language that takes care of memory management and garbage collection so that they can focus on the application rather than on book keeping.
Edrad is not a web application.
Python is a clunky pile of shit that can NOT cope with high speed i/o operations.
That is sad to hear. It seems Python is sufficiently fast for Google to use. But I suppose your project has greater demands.
Perhaps you should look over [1]. Specifically, [2] and [3].
[1] http://www.catb.org/~esr/writings/taoup/html/
[2] http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878666
[3] http://www.catb.org/~esr/writings/taoup/html/ch14s04.html
Allow me to make something clear: I am not a posturing unix faggot. I despise posturing unix faggots.
Edrad is a Windows application first, Unix second. The ONLY reason it will be cross-platform with Debian is because at least 2/3 of people use Debian for such things.
C has long since been depricated. Top-down execution is flat out archaic. The only people who prefer C are the aforementioned posturing unix faggots.
This has nothing to do with UNIX. While the book may have "UNIX" in its title, it offers valuable advice regarding programming in general. ESR is a well respected member of the open source community. In fact, he is probably the most recognized proponent of open source. It is sad that you would dismiss his work so lightly.
One key flaw with open source is that any douche can contribute, which is why none of my projects are or ever will be open source.
Believe it or not this is not something I have accidentally stumbled onto by chance. I have been programming for a very long time, so you'll forgive me if I don't listen to someone trying to tell me what's what in a comment box.
My apologize. I never intended to tell you what to do. And I certainly do not wish to preach.
I have been programming for a long time as well, around 15 years. Yet, I defer to the experience of those who have been coding for longer, for example, ESR.
Open source does not have to mean anyone can contribute whatever they want to your project. Your project is still your project. If you want to accept a patch, say from someone with more experience, then you can. As far as I can tell, you are not out to make a profit, so there is no danger in someone creating and running another version of your code. Anyway, as I said, I do not mean to preach, but your argument does not make much sense.
I appreciate your perspective on the matter. It's probably entirely personal preference, and I must prefer object orientated programming.
I much prefer to have a collection of classes that will persist versus archaic top down execution modules that I have to call repeatedly.
I very much have my own style and ideas of doing things, and I find other people trying to contribute just gets in my way to some degree. It's nothing personal.
Well, I could help you with developing if you coded in C#, but never mind.
Can we expect this project to be open source? I'll love to see whats inside Edrad and browse the code to lean from your skills.
Anyway, I respect closed source too.
Thanks for your work.
So let me get this right, you want to charge people a license fee so they can create mirrors to copyrighted works automatically? Because lets face it, that's what SceneDDL and all those other sites do.
While I have my own eyepatch, skull and crossbones flag and peg leg I just still see this (albeit loosely) as profiting from piracy or the scene.
Post a Comment