You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(1) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(4) |
Feb
(4) |
Mar
(83) |
Apr
(45) |
May
(56) |
Jun
(51) |
Jul
(52) |
Aug
(10) |
Sep
(43) |
Oct
(7) |
Nov
|
Dec
(14) |
2006 |
Jan
(22) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(6) |
2007 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(1) |
May
(4) |
Jun
(11) |
Jul
(21) |
Aug
(19) |
Sep
(11) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
2008 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(2) |
Sep
(10) |
Oct
(8) |
Nov
(27) |
Dec
(31) |
2009 |
Jan
(11) |
Feb
(10) |
Mar
(17) |
Apr
(48) |
May
(122) |
Jun
(92) |
Jul
(68) |
Aug
(32) |
Sep
(27) |
Oct
(34) |
Nov
(7) |
Dec
(20) |
2010 |
Jan
(13) |
Feb
(10) |
Mar
(65) |
Apr
(64) |
May
(54) |
Jun
(62) |
Jul
(46) |
Aug
(42) |
Sep
(19) |
Oct
(3) |
Nov
(1) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: <web...@kr...> - 2005-03-16 22:54:42
|
Okay, so(I think) the code is up in the CVS repository. Hack around and have fun, I know it took another day, but I promise I wrote some funny documentation and a guide that is simple and very explanitory in the doc directory, the code is laid out quite bueatifually. Also, I would tend to aggree with Tim's idea, we could run the program once for each feed and have another tool to parse a config file and run the program once for each file. The base program is pretty good, expcept for one thing, I left the error system open for more hacking. We can also use a config file, I'm really open to anything right now, its turning out to be a great program, thanks guys. May we grow to be the best! :) |
From: Tim C. <aap...@gm...> - 2005-03-16 07:09:39
|
Do we really need to be able to handle multiple feeds? I propose we just accept one -f/-t/-o option pair. Users can just run it once for every feed they need. Am I missing something? It's nice to see some activity in the mailing list. :) On Tue, 15 Mar 2005 14:16:46 -0800, wren argetlahm <wr...@fr...> wrote: > web...@kr... wrote: > > Yeah, I read all that earlier in the week and wrote a base program(only > > like 500 lines, is that a problem?) > > No problem with that :) I was just mentioning (in a bit more detail) > what I was thinking. As I've said, if we keep the basic program as > simple as possible that makes it easier to make add-on programs (like a > daemon etc) without introducing goofy interdependencies in the code > which will lead to maintenance issues down the line. > > > well anyway, it has very simmilar > > command line options, but I havnt put in the ability to parse a config > > file yet(just get one feed and put the parsed contents to stdout or a file > > of your choice). So like I said, I'll put it up on cvs by the end of the > > day, but right now I'm trying to figure out autoconf so our makefile can > > auto-detect the cflags and library flags required to compile the program. > > Thanks, I hope you like the base program. > > I'll need to install libcurl (I think), but I'll check it out. I'm > thinking that, with a beta prototype in hand, we should look at the > config file issues. One of the things I'd definitely like to see is a > powerful ability to deal with combinations of multiple feeds and > templates. The config DTD I threw out there looks like it might be a > really good start for that sort of thing. After we get the code in a > place to deal with a config like that, I think we should revisit how the > commandline args should work. My initial -f/-t/-o suggestion may be a > bit shortsighted for multi-rss/xsl. > > (( Thinking aloud again here, maybe we could do something like have a > "--" delimited list of those args. Something like: > > ./paperboy -f.. -t.. -o.. -- -f.. -f.. -f.. -t.. -o.. -- ... > > (Which might get goofy with long flag names.) So the second block of > arguments joins all those feeds into one for the template. Of course, > with this sort of arrangement, if you want multiple individual feeds to > be sent through a template you'd need to type out the path to that > template repeatedly. > > Of course, that's also true with the way I had the config file set up. > To get around that in the config file we could have separate top level > elements for templates and feeds and then associate them though some > sort of unique id. Which quickly dives into the realm of needing a > frontend to maintain (see iTunes w/r/t songs and playlists, frex). > Another idea would be to keep the arrangement I had with feeds being > elements of templates, then have an option where instead of specifying a > path to a template you can declare this "template" to be an alias of > another one. That would be a lot prettier and easier. > > Well, that's just me thinking. I have some free time coming up, I'll > download the source once it's up and see if I can make any of these > ideas work. )) > > Is there a standard library for dealing with posix-style commandline > flags? Or should we have our own code for short/long flags? (do we even > want long flags?) <more rambling thoughts> > > Live well, > ~wren > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Paperboy-development mailing list > Pap...@li... > https://lists.sourceforge.net/lists/listinfo/paperboy-development > |
From: wren a. <wr...@fr...> - 2005-03-15 22:16:56
|
web...@kr... wrote: > Yeah, I read all that earlier in the week and wrote a base program(only > like 500 lines, is that a problem?) No problem with that :) I was just mentioning (in a bit more detail) what I was thinking. As I've said, if we keep the basic program as simple as possible that makes it easier to make add-on programs (like a daemon etc) without introducing goofy interdependencies in the code which will lead to maintenance issues down the line. > well anyway, it has very simmilar > command line options, but I havnt put in the ability to parse a config > file yet(just get one feed and put the parsed contents to stdout or a file > of your choice). So like I said, I'll put it up on cvs by the end of the > day, but right now I'm trying to figure out autoconf so our makefile can > auto-detect the cflags and library flags required to compile the program. > Thanks, I hope you like the base program. I'll need to install libcurl (I think), but I'll check it out. I'm thinking that, with a beta prototype in hand, we should look at the config file issues. One of the things I'd definitely like to see is a powerful ability to deal with combinations of multiple feeds and templates. The config DTD I threw out there looks like it might be a really good start for that sort of thing. After we get the code in a place to deal with a config like that, I think we should revisit how the commandline args should work. My initial -f/-t/-o suggestion may be a bit shortsighted for multi-rss/xsl. (( Thinking aloud again here, maybe we could do something like have a "--" delimited list of those args. Something like: ./paperboy -f.. -t.. -o.. -- -f.. -f.. -f.. -t.. -o.. -- ... (Which might get goofy with long flag names.) So the second block of arguments joins all those feeds into one for the template. Of course, with this sort of arrangement, if you want multiple individual feeds to be sent through a template you'd need to type out the path to that template repeatedly. Of course, that's also true with the way I had the config file set up. To get around that in the config file we could have separate top level elements for templates and feeds and then associate them though some sort of unique id. Which quickly dives into the realm of needing a frontend to maintain (see iTunes w/r/t songs and playlists, frex). Another idea would be to keep the arrangement I had with feeds being elements of templates, then have an option where instead of specifying a path to a template you can declare this "template" to be an alias of another one. That would be a lot prettier and easier. Well, that's just me thinking. I have some free time coming up, I'll download the source once it's up and see if I can make any of these ideas work. )) Is there a standard library for dealing with posix-style commandline flags? Or should we have our own code for short/long flags? (do we even want long flags?) <more rambling thoughts> Live well, ~wren |
From: <web...@kr...> - 2005-03-15 19:10:21
|
Yeah, I read all that earlier in the week and wrote a base program(only like 500 lines, is that a problem?) well anyway, it has very simmilar command line options, but I havnt put in the ability to parse a config file yet(just get one feed and put the parsed contents to stdout or a file of your choice). So like I said, I'll put it up on cvs by the end of the day, but right now I'm trying to figure out autoconf so our makefile can auto-detect the cflags and library flags required to compile the program. Thanks, I hope you like the base program. |
From: wren a. <wr...@fr...> - 2005-03-15 06:44:37
|
web...@kr... wrote: > Okay, thats awsome! So we are in aggreement that paperboy should be a > basic program that parses the feeds and spits them out, would we want some > kind of daemon that would run in the background to update feeds? Also, I > dont know much about XSLT, guess I'll have to start reading up. So we > would just want the base program to parse feeds and spit them out and then > have other tools scripts etc.. combine them? If so then when we were done > we could write a frontend in Python or Tcl to combine all the scripts and > stuff over a gui. Lets get a framework document together so we can start > coding. Sound all right? Also, we will be dumping most of our alpha code, > scince it leaked and seg faulted. XSLT is pretty simple. If you want a quick tutorial you can check out <http://www.w3schools.com/xsl/>. Of course, the idea behind using xslt--or at least my idea behind suggesting it--is that the code for paperboy doesn't need to know anything about it whatsoever. Just parse the template with libxml2, hand that object to libxslt to be re-blessed, then give the libxslt object and a libxml2 object for the feed to libxslt and it'll do all the dirty work for you. You only need to know xslt if you want to make the templates, but again, it's pretty simple if you already know xml. I don't think a daemon is necessary, at least not for the basic v1.0 code. It would be pretty simple to write such a daemon, but I think it'd be best to keep that separate from the generic exec. Of course, for that matter the "daemon" could be a cron job; I don't think most people would need more than hourly updates (though I could be wrong, in which case a real daemon might be desired). What I'm thinking for the simple utility version of paperboy is something like the pseudo-code below: main(argc, argv) { if (argc > 1) { foreach (argv) { parse_commandline(argv); } } else { parse_default_config(); } if (!arg[dont_download]) { foreach (arg[feed]) { libcurl::get(arg[feed], path_to_save); } } if (!arg[download_only]) { xslt = libxml2::parse(arg[path_to_xslt]); foreach (arg[path_to_save]) { xml = libxml2::parse(arg[path_to_save]); out = libxslt::transform(xml, xslt); path_to_file = arg[path_to_file] || stdout; fprintf(path_to_file, "%s", out); } } } Of course the real thing'll be more complicated (and I significantly doubt that we want to use fprintf() ), but that's the basic idea I was thinking of. Commandline arguments would be things like: -f --file http://url.of.feed (or path/to/local/rss) -s --save_to path/to/save/rss/feed (default to a mangled name somewhere in /tmp) -t --template path/to/xslt/file -o --output_to path/to/output/file (default to stdout) -d --download no (just parse the copies you already have) -d --download only (just download, don't parse) I think the output should default to stdout because that lets you pipe it to some other program. For example, a cgi for displaying the latest version could just parse the url args, print http headers, and then call paperboy. If it didn't default to stdout you'd have to (a) save the output, then open it to the other program, a time consuming and annoying task; or (b) have some filename reserved to symbolize stdout (or an extra flag that says "print to stdout rather than a file"). You seem reluctant about the idea, is there a different default value you were thinking would be better? There are some snags to those ideas for command flags, namely how to deal with multiple feeds. Since each -f is associated with an -s we can't simply allow multiple -f flags; we'd need to find some way to associate them (maybe a FIFO mapping?). We could have -s specify a directory to save to instead, but we'd need to come up with a url mangling pattern to name the files with (of course we'd need this for the default /tmp files too, though there the filename doesn't need to be human readable). Also, if the template is one for conjoining multiple feeds into one page, how do we differentiate that from a template that only looks at one feed? These are things that would be easier to deal with in a config file than as commandline arguments; maybe we could just say that if you want to play with multiple feeds you need to use the config file rather than the commandline. That goes against the philosophy that the config file should just be a shorthand for the commandline args, however. The two approaches to a config file I can think of are (a) store it as xml, then parse with libxml2 and interpret it, or (b) store it as a list of commandline arguments, then just use then in the parse_commandline() function. We could come up with some other way of doing the config file, too. If we use xml for the config file we could have a layout something like this: <?xml?> <!DOCTYPE> <paperboy-config> <global-prefs> <!-- what would go here? --> ... </global-prefs> <template> <path>path to template</path> <output>path to output file</output> <feed> <path>url or path to feed</path> <save>path to save to. optional</save> </feed> <feed> ... </feed> ... </template> <template> ... </template> ... </paperboy-config> Which fairly elegantly deals with issues of multiple feeds, multiple templates, and all the info associated with them. Live well, ~wren |
From: <web...@kr...> - 2005-03-15 04:25:14
|
So, I finished the basic program, it takes some command line options and does "stuff" with it. In a nutshell(well, the program is only like 550 lines so theres not much nutshelling) it A)Parses input options B)Downloads the feed and stores it in a file you specify(only if you choose to do this) C)Applies the stylesheet to that raw XML and D)outputs the feed(to stdout if you dont specify a file). Anyway, I will have the code in CVS on our site by tommorow(the "on the site" may just be wishful thinking). I am trying to figure out autoconf so I can write a config file(our program uses libxml2, libxslt, and libcurl so we have to write a config script that makes the makefile point to the right stuff) thats about all, we use libcurl to be portable BTW. |
From: <web...@kr...> - 2005-03-03 23:30:49
|
Okay, I have the coding standards here, tell me if they need any change: http://www.kryptech.net/download/paperboycodingstandards.pdf And should we write an introduction and agree on what kind of thing we want to write. Should we really default the output to stdout. And will we just use printf("%d", datastuff); or Unix IO to print to standard streams? |
From: <web...@kr...> - 2005-03-03 17:31:41
|
Okay, thats awsome! So we are in aggreement that paperboy should be a basic program that parses the feeds and spits them out, would we want some kind of daemon that would run in the background to update feeds? Also, I dont know much about XSLT, guess I'll have to start reading up. So we would just want the base program to parse feeds and spit them out and then have other tools scripts etc.. combine them? If so then when we were done we could write a frontend in Python or Tcl to combine all the scripts and stuff over a gui. Lets get a framework document together so we can start coding. Sound all right? Also, we will be dumping most of our alpha code, scince it leaked and seg faulted. |
From: wren a. <wr...@fr...> - 2005-03-03 09:44:08
|
Tim Cooijmans wrote: > I agree with wren. Wasn't it called the UNIX philosophy to chain basic > tools together? We shouldn't implement all those network services, > because they are prone to bugs and vulnerabilities. That would be the UNIX philosophy :) > For HTTP, we could just write an example bash script to grab > paperboy's output and convert them to HTML files, which are then > dumped into a specified directory, probably the user's webroot. If we use user-defined XSLT sheets to format the RSS, no conversion to HTML is needed (the XSLT can turn the RSS into HTML, or literally anything else). We just need some config preference or commandline argument to specify which XSL template to use (so the user can have one for HTML, one for YAML, one for raw RSS...). The shell script could be as simple as a series of: paperboy -f http://site.com/feed.rss -t ~/.paperboy/xslt/html.xsl -o ~/public_html/feed.html ...commands with some sort of loop around it to iterate over your list of feeds (where -f are feeds, -t templates, -o where to output if other than stdout). > We can probably use the mail command (again in a bash script or > something) to send the feeds over e-mail. Definitely. Same goes for the irc bot. If paperboy only grabs files, manipulates them into some meaningful format, and spits it out,, that can just be shell scripted or piped into other utilities. It may not sound like a lofty goal, but if it can be reached I see the program being very useful-- certainly more free form (and hence more powerful) than the majority of other rss tools out there. The hard part is how the program should arrange multiple feeds if they all get put on one page. The first thing that pops to mind is some arrangement like: <?xml?> <paperboy> <feed path="http://foo.com/feed.rss"> <!-- the actual feed imported here --> </feed> <feed path="http://blog.com/my_blog.rss"> <!-- the actual feed imported here --> </feed> ... </paperboy> Seems the most straightforward approach. The other hard part would be not the program itself (a pretty straightforward use of libxml2 and libxslt) but creating the suite of useful scripts, templates, etc to give users an idea of how to play with it. Live well, ~wren |
From: wren a. <wr...@fr...> - 2005-03-03 09:44:05
|
Tim Cooijmans wrote: > I agree with wren. Wasn't it called the UNIX philosophy to chain basic > tools together? We shouldn't implement all those network services, > because they are prone to bugs and vulnerabilities. That would be the UNIX philosophy :) > For HTTP, we could just write an example bash script to grab > paperboy's output and convert them to HTML files, which are then > dumped into a specified directory, probably the user's webroot. If we use user-defined XSLT sheets to format the RSS, no conversion to HTML is needed (the XSLT can turn the RSS into HTML, or literally anything else). We just need some config preference or commandline argument to specify which XSL template to use (so the user can have one for HTML, one for YAML, one for raw RSS...). The shell script could be as simple as a series of: paperboy -f http://site.com/feed.rss -t ~/.paperboy/xslt/html.xsl -o ~/public_html/feed.html ...commands with some sort of loop around it to iterate over your list of feeds (where -f are feeds, -t templates, -o where to output if other than stdout). > We can probably use the mail command (again in a bash script or > something) to send the feeds over e-mail. Definitely. Same goes for the irc bot. If paperboy only grabs files, manipulates them into some meaningful format, and spits it out,, that can just be shell scripted or piped into other utilities. It may not sound like a lofty goal, but if it can be reached I see the program being very useful-- certainly more free form (and hence more powerful) than the majority of other rss tools out there. The hard part is how the program should arrange multiple feeds if they all get put on one page. The first thing that pops to mind is some arrangement like: <?xml?> <paperboy> <feed path="http://foo.com/feed.rss"> <!-- the actual feed imported here --> </feed> <feed path="http://blog.com/my_blog.rss"> <!-- the actual feed imported here --> </feed> ... </paperboy> Seems the most straightforward approach. The other hard part would be not the program itself (a pretty straightforward use of libxml2 and libxslt) but creating the suite of useful scripts, templates, etc to give users an idea of how to play with it. Live well, ~wren |
From: Tim C. <aap...@gm...> - 2005-03-03 08:26:13
|
I agree with wren. Wasn't it called the UNIX philosophy to chain basic tools together? We shouldn't implement all those network services, because they are prone to bugs and vulnerabilities. For HTTP, we could just write an example bash script to grab paperboy's output and convert them to HTML files, which are then dumped into a specified directory, probably the user's webroot. We can probably use the mail command (again in a bash script or something) to send the feeds over e-mail. I don't see much use in the IRC bot thing, but it's probably highly possible to make the bot run paperboy and give some formatted output. For configuration, I guess the best way is to write a webmin module. It makes for a more standardized way of configuring UNIX services ;) I too don't know how much time I can spend on the project. I'm back at school now, and a lot has changed, the result being that I have very little spare time left. We'll see where things are headed, I'll check whenever I can find the time. Tim On Wed, 02 Mar 2005 22:19:15 -0800, wren argetlahm <wr...@fr...> wrote: > I'm still unsure about how much time I can devote to the project, and I > didn't follow the alpha code as well as I ought to've, so feel free to > take my opinions with a huge grain of salt, but... > > I think the program (as something written in C) should: > a) grab feeds from online if the local copies are too old > b) parse those files through a (set of) XSLT template(s) > c) return that output to stdout (possibly with a flag to let you output > to a file) > > This way it's the most basic, most generic program. From there a > separate daemon could be written that calls upon it to serve a webpage > or email changes or whatever. A separate cgi script as an example[1] of > how to pipe it to your website. Another script could dump output to irc, > vi, etc. If the basic program just parses RSS, shoves it through XSLT, > and returns that output, subsequent programs and scripts can take that > output and do what they will with it. We could coalesce all those > functions, but that would make it more difficult to maintain, lead to > more bloat (if the user doesn't want a particular function), etc and I > don't know that it would gain anything. I'd be cool with the paperboy > project being a suite of things based on the simple grab-parse-output > utility. > > I'm of the philosophy that all configuration should be stored in a > plaintext config file somewhere except when overridden on the > commandline. If we developed a GUI frontend for configuring it, I'd say > just have that frontend affect the config file, and have the user do a > `sudo paperboyctl graceful` or the like. Seems the simplest approach. > > Live well, > ~wren > > [1] I call this an example script, because chances are anyone using > paperboy this way will want to write their own script to integrate the > feeds with other page content. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Paperboy-development mailing list > Pap...@li... > https://lists.sourceforge.net/lists/listinfo/paperboy-development > |
From: wren a. <wr...@fr...> - 2005-03-03 06:19:21
|
I'm still unsure about how much time I can devote to the project, and I didn't follow the alpha code as well as I ought to've, so feel free to take my opinions with a huge grain of salt, but... I think the program (as something written in C) should: a) grab feeds from online if the local copies are too old b) parse those files through a (set of) XSLT template(s) c) return that output to stdout (possibly with a flag to let you output to a file) This way it's the most basic, most generic program. From there a separate daemon could be written that calls upon it to serve a webpage or email changes or whatever. A separate cgi script as an example[1] of how to pipe it to your website. Another script could dump output to irc, vi, etc. If the basic program just parses RSS, shoves it through XSLT, and returns that output, subsequent programs and scripts can take that output and do what they will with it. We could coalesce all those functions, but that would make it more difficult to maintain, lead to more bloat (if the user doesn't want a particular function), etc and I don't know that it would gain anything. I'd be cool with the paperboy project being a suite of things based on the simple grab-parse-output utility. I'm of the philosophy that all configuration should be stored in a plaintext config file somewhere except when overridden on the commandline. If we developed a GUI frontend for configuring it, I'd say just have that frontend affect the config file, and have the user do a `sudo paperboyctl graceful` or the like. Seems the simplest approach. Live well, ~wren [1] I call this an example script, because chances are anyone using paperboy this way will want to write their own script to integrate the feeds with other page content. |
From: <web...@kr...> - 2005-03-02 22:26:15
|
Okay, so I really want to get started on coding the new version soon. We first need to make some descions on how we want the program to execute. Our new descisions would concern weather or not to use a GUI and stuff like that. In the past we had not used a GUI just because all of our interface stuff was handled by a server that we would plan to use so that you could configure the program by a server if you fired up a browser. Well, I think that we should disable the server as default option for the next version. Sure, if you want to use a server to display your news when you go on vacation or something like that then you could enable it in the config file or via a command line option or something like that. Thing is that if you enabled the server as default, then we would be responsible for errors and bugs the server produced. Our goal is not to start an Apache project or anything like that. I think that if we developed a server we minght have reports of people breaking into someones fiels and publishing their personal info all over the net like our friend Paris Hilton... So what do we want our program to do. I think that our program should be a general use RSS parser so that you can use it for everything. So the goals of the project should be somehting like this 1)generating parsed feeds and placing them in your web page. 2)producing parsed versions of HTML templates and placing them in your personal directory so you can view them from your browser 3)Sending our parsed text feeds over email. 4)Acting as ain IRC bot for you favorite IRC network and then type a command like "dump news bbc" and it would print out news over an IRC channel or a private message 5)I also think that we should write a GUI frontend using python that will interact with the main program, perhaps this program could communicate to paperboy by using a fifo or a server. I have no problem writing a simple server that will accept commands that will update news on a certain computer, but how would we know if that person had any authority over that machine. In other words, I dont want to give any access to anyone who didnt have it. I just need you guys opinion for what we want this thing to do. So, bring on the ideas. Also I will put our the 5 page coding standards document tonight via .pdf. |
From: <web...@kr...> - 2005-02-14 22:51:10
|
Okay, if you have all checked the coding style then coding should begin shortly. First I think that we should decide on what IDE we want to use. My computer works with the latest build of Debian Linux, and I will be upgrading to the newest version of the 2.6 kernel tonight(Hopefully it will work). I think we should try to use the Anjuta Integrated Development Environment(Also developed on sf.net). I hope I can get that working and if I cant then we minght switch to something else. |
From: <web...@kr...> - 2005-02-09 23:03:00
|
Okay, I have the document we want to use as our coding standard, its here: http://developer.gnome.org/doc/guides/programming-guidelines/book1.html Read that. If anyone is working on the code here are some suggestions: 1)Write code that will be enjoyable to update and understandable by others: Write code in a way such that it has a clean interface. Using black box abstratcions is a good idea(writing functions that one can use without understanding if they work). 2)Write code that makes use of portable libraries: With the new version of paperboy feed parser we will NOT be using our own network functions in the new version of the program. We also want our code to be as portable as possible, that way we can port it to windows. So use ANSI C. For our network download funcitons we will be using libcURL(which the curl program is based off of) and still using libxml2 . 3)Dont submit anything that does not work to CVS: With the new version we will be creating a new directory in our repository. Dont commit any code that does not work, if you have code that is seg faulting and want to get it in before you goto sleep so you can have a backup DONT! Submitting non functional code is worse than not submitting code at all. Also, when I say code that does not work I also mean code that has memory leaks or limitaitons. 4)No buffer limits: we need to allocate and free memory in our program, not have buffers and cut off the rest of the feed if there is not enough room in the buffer for several reasons: 1)This promotes buffer overflow 2)Its annoying to a user when they cant read their feed because it was more than 10000 characters long with HTML included. Okay, now we need to decide on the structure of our program. Anyone got any proposals? |
From: Tim C. <aap...@gm...> - 2005-02-04 14:03:11
|
Wow, that has to suck. As for me, I have just spent my first week at school again after half a year of internship. There's a huge reorganization going on over here, about time I'd say, but since my school hasn't changed a lot (it's still an unoganized incompetent bunch of clueless teachers, see http://rubbish.aapopfiets.nl/?v=interaa), I've had a busy week. I think I've never worked this hard for school before. At the moment, I'm not at all interested in programming. I've not felt like programming for the last three weeks, but the lust for creating will come back soon enough ;) I think we need to reorganize a bit; we can't just start writing code and see where we'll end up. We should write dynamic stuff, you know: have several formatting engines (types of RSS feeds and whatnot), which use a standardized way of registering with the core (which is just the job that schedules the fetching, I guess), and the same for output engines, so we can output HTML, XML, whatever you want, and the core nor the formatting engine needs to know about what format we're using: abstraction. Maybe we should switch to an object-oriented language like C++ or we could look how glibc's OO-like code works. I also think we still need a good coding standard. Seeing as such a standard needs to be detailed, we might as well rip one from another project; I like Gaim's (I think Gnome as a whole uses the same standard). Greets, Tim On Wed, 2 Feb 2005 08:53:08 -0500 (EST), web...@kr... <web...@kr...> wrote: > This is sick, so I'm sorry... > I had been working on the new version of the program, had written lots of > lines of code, it looked really good but kept seg faulting, on top of that > I lost it all the other day, I came home, and my hard drive crashed, I > also lost my code repository(3GB!!! Well, with compiled code). Then when I > tried to install a new version of linux my cat hit the table, and it came > crashing down on the hard drive, knocking the spindle off its axis and > effectivly killing it, so I also have to download the new version of > debian(anyone know when sarge will be coming out). But I think its time we > start working on the new version, and use very little if any code that we > have from the prototype. Can we do that? or is someone horribly opposed to > it. > (I'm on a windows box right now in case you thought I was emailing from a > dead machine :) > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Paperboy-development mailing list > Pap...@li... > https://lists.sourceforge.net/lists/listinfo/paperboy-development > |
From: <web...@kr...> - 2005-02-02 13:53:12
|
This is sick, so I'm sorry... I had been working on the new version of the program, had written lots of lines of code, it looked really good but kept seg faulting, on top of that I lost it all the other day, I came home, and my hard drive crashed, I also lost my code repository(3GB!!! Well, with compiled code). Then when I tried to install a new version of linux my cat hit the table, and it came crashing down on the hard drive, knocking the spindle off its axis and effectivly killing it, so I also have to download the new version of debian(anyone know when sarge will be coming out). But I think its time we start working on the new version, and use very little if any code that we have from the prototype. Can we do that? or is someone horribly opposed to it. (I'm on a windows box right now in case you thought I was emailing from a dead machine :) |
From: <web...@kr...> - 2005-01-25 13:53:00
|
Yeah, I'm thinking that we should get another python person to help me code it. hmm, mabye we should just code it in C, the only thing is that it wouldnt be portable, its not like this is a tool that you "had" to use. You would still have the option to just download the binary and use it, we would just be making a tool that helped people who didnt know as much use our program better, e.g. letting you download new skins for the thing. So this program will be completly seperate from the main program, its just an optional download. By the way, Dont work on the code yet, I havnt put my new version on CVS yet, theres this one stupid function that I've been debugging all week! The problem is that our old code that I was cleaning up did not free() any memory, so we have tons of memory leaks! But when this new version is done we will be able to easily intergrate code for parsing other types of feeds like RDF and still have to use the same functions for exporting them to HTML as we would with RSS. I've also been looking at libraries to export to PDF. To compete with todays top parsers we will have to get our server to be a key part of the project, which means making it a lot more secure(along with our network handling code). And we will also have to export to a lot of other things, if you have any ideas of what other formats than HTML we should export to other than HTML please respond. The ideas I have for them right now are: HTML PDF Plain text(For printing them every morning or something like that) SMTP(Sending the news out on a mailing list) IRC(Make an integrated IRC bot to serve the news on certain channels) Thats all thanks, Kryptech |
From: Tim C. <aap...@gm...> - 2005-01-24 22:54:00
|
Nice to hear from you. I really only have one comment, because the rest looks fine to me. If we decide to go for Python to code the GUI in, I think you're the one who's going to have to program and maintain that part. ;) I'm unfamiliar with Python, I don't know about the others... I'll look into the code some time this week. I finally outlived my internship, so time will probably be on my side. I still have a lot of other projects to work on, though. Cheers, Tim On Mon, 24 Jan 2005 14:39:07 -0500 (EST), web...@kr... <web...@kr...> wrote: > Okay, so our program is looking really good. I still havnt worked out a > problem that has been bugging me for the last week. But I think that I > will solve that problem tonight. We now implement a new RSS parser. It > should also be easy to implement new parsers for ATOM and RDF, mabye we > could also find some other wierd feed types on the net as well, the > network wappers still look junky, but I hope we will also fix that. My > though is that after we finish the program it will be able to do a great > many things. I think that to make people who dont know so much about > programming happy, we should have the program run as a daemon in the > background that silenly updates the pages and handles the server. Then, we > should have a GUI program that communicates with the main program mabye > through a FIFO or something like that. I think that we should program the > GUI app in a easy language like Python for a number of reasons: > 1) It would be accessible to everyone: > You can easily get TKinter for python and then run it on any system, > programming it in C for GTK+ because only systems that run on things > like GONME. > 2) It would be easy to program: > It would be shorter than programming it in C. This way it would be > easy to maintain. > > The interface would have features like a wizzard for making the config > file, tools to monitor the server stats, tools that would help you > distribute the news(for example a mailing list or an IRC bot). > Does this sound cool, or should we program it in C? > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Paperboy-development mailing list > Pap...@li... > https://lists.sourceforge.net/lists/listinfo/paperboy-development > |
From: <web...@kr...> - 2005-01-24 19:39:13
|
Okay, so our program is looking really good. I still havnt worked out a problem that has been bugging me for the last week. But I think that I will solve that problem tonight. We now implement a new RSS parser. It should also be easy to implement new parsers for ATOM and RDF, mabye we could also find some other wierd feed types on the net as well, the network wappers still look junky, but I hope we will also fix that. My though is that after we finish the program it will be able to do a great many things. I think that to make people who dont know so much about programming happy, we should have the program run as a daemon in the background that silenly updates the pages and handles the server. Then, we should have a GUI program that communicates with the main program mabye through a FIFO or something like that. I think that we should program the GUI app in a easy language like Python for a number of reasons: 1) It would be accessible to everyone: You can easily get TKinter for python and then run it on any system, programming it in C for GTK+ because only systems that run on things like GONME. 2) It would be easy to program: It would be shorter than programming it in C. This way it would be easy to maintain. The interface would have features like a wizzard for making the config file, tools to monitor the server stats, tools that would help you distribute the news(for example a mailing list or an IRC bot). Does this sound cool, or should we program it in C? |
From: <web...@kr...> - 2005-01-11 13:56:11
|
Hi guys, I'm sorry if I havnt emailed in a while. Lets just say our(no, my) code looks like crap. This is mainly due to the excessive use of header files in everything that we write. So over the weekend I have revised the code. I am still working to make the code cleaner, but right now it looks a whole lot better! I have implemented a nice file tree to organize everything as well as following some of the standards that Tim has submitted(thanks Tim). Thanks guys, I will import my new, nice version of paperboy that will be moving toward an initial release mabye by may. |
From: Tim C. <aap...@gm...> - 2004-12-26 10:38:41
|
Hey all, I just checked out the source, but it doesn't compile. I dove into the source to find out why, and I noticed the code was really ugly (I mean the formatting). It's really time to decide on a coding standard ;-) My proposal: * tabs for indentation (4 space tabs) * curly braces: if (true) { // blah } * and lots of more stuff I can't think of now, actually We should also make the pb_* files .c files, and don't include them, but compile them separately (with the -c switch), and link them afterwards. Well, I'm kind of in a hurry... And I haven't had much time to work on paperboy, maybe in February I'll have time again, I'm really busy right now. And happy holidays :) Tim |
From: <web...@kr...> - 2004-12-16 22:20:09
|
Okay, Tim, I think this is a great solution to our problem, I will get implememting it right away, I just have a few questions. Our program puts out an index page and multiple feed pages, how should we implement this? I'm thinking that we should have an index page template file, and then we should have an individual page page template file so like we would have a tag <indextemplate>indextem.txt</indextemplate> <individualtemplate>indivtem.txt</individualtemplate> then indextem.txt would contain the following: <html><head><title>Index page</title></head> <body> %start feed% <h1>%title feed%</h1> %end feed% </body> </html> then indivtem.txt would be a little of the same thing... Also, I'm thinking of implementing a search function, I think we should just use the individual page template for that, I think I will implement this idea tonight, I minght not be able to develop over the christmas holidays because I'm traveling all over the US. I'm gonna try to burn a copy of knoppix and get a little flashram stick to dev on but it probably wont work. Does this idea sound okay? |
From: Tim C. <aap...@gm...> - 2004-12-16 20:46:18
|
I'm sorry, I forgot to explain how I was planning to implement the template concept. I'd say we use a regular HTML file, and interpret character sequences in it as variables: %feed_title% %feed_description% Something like that (I don't like the '%' on either side of the variable names, but who cares, it's an example :P). There's only one problem: there's possibly more than one feed/item. I have two suggestions for solutions: 1) We implement an 'include'-like function, to do something along the lines of: %feed_template "feed.template"% So you can include other files as templates for feeds or items. Example: <html> <body> <h1>Welcome to my page full of feeds!</h1> <hr> %feed_template "feed.template"% <hr> Some footer stuff </body> </html> File feed.template: <h2>%feed_title%</h2> <h3>%feed_description%</h3> <hr> %item_template "item.template"% <hr> File item.template: <h3>%item_title%</h3> <h4>%item_description%</h3> <p>%item_content%</p> You get the idea. There's a disadvantage to it: even more files :P 2) We use %feed_start% and %feed_stop% (same for item) to indicate the beginning and end of sections. <html> <body> <h1>Welcome to my page full of feeds!</h1> <hr> %feed_start% <h2>%feed_title%</h2> <h3>%feed_description%</h3> <hr> %item_start% <h3>%item_title%</h3> <h4>%item_description%</h3> <p>%item_content%</p> %item_stop% <hr> %feed_stop% <hr> Some footer stuff </body> </html> If anyone else has any suggestions, I'd like to hear them ;) Keep in mind, these are still only examples and there's probably a lot of finetuning to do. Oh, and Kryptech, I suggest you do the CGI stuff, because I have no experience with that stuff at all ;) I should play around with it some time though. Glad to hear I've been a help ;) Tim On Mon, 13 Dec 2004 23:47:29 -0500 (EST), web...@kr... <web...@kr...> wrote: > Okay, I made some more updates to the server and also added a function to > update the pages, first the server. > I made our server able to(kind-of) support cgi scripts. What I did was add > a scriptdir varible to the global > scope of our program it then is parsed in the config parser function, now > if the server gets a request to > access a file from the script directory(I made it so our program will > think that SCRIPT_DIR_ALIAS is the > path to the script directory) it will execute the file and set the > enviroment varible SCRIPTARGS to the > script's arguments. > So lets say the server gets this request: > > localhost:8651/scripts/file.py?argument1=argvalue&argument2=arg2val > > the server would open the directory defined by "scriptdir" in the config > file and execute the file "file.py" > and would set the enviroment varible SCRIPTARGS to: > argument1=argvalue&argument2=arg2val > another note when the arguments are passed they are not parsed in other > words it a user enters " Hi" in > the field "username" of a form > the SCRIPTARGS enviroment varible would be set as > username=+++Hi > > Thanks a lot for all your help and good advice Tim. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Paperboy-development mailing list > Pap...@li... > https://lists.sourceforge.net/lists/listinfo/paperboy-development > |
From: <web...@kr...> - 2004-12-14 04:47:31
|
Okay, I made some more updates to the server and also added a function to update the pages, first the server. I made our server able to(kind-of) support cgi scripts. What I did was add a scriptdir varible to the global scope of our program it then is parsed in the config parser function, now if the server gets a request to access a file from the script directory(I made it so our program will think that SCRIPT_DIR_ALIAS is the path to the script directory) it will execute the file and set the enviroment varible SCRIPTARGS to the script's arguments. So lets say the server gets this request: localhost:8651/scripts/file.py?argument1=argvalue&argument2=arg2val the server would open the directory defined by "scriptdir" in the config file and execute the file "file.py" and would set the enviroment varible SCRIPTARGS to: argument1=argvalue&argument2=arg2val another note when the arguments are passed they are not parsed in other words it a user enters " Hi" in the field "username" of a form the SCRIPTARGS enviroment varible would be set as username=+++Hi Thanks a lot for all your help and good advice Tim. |