Menu
▾
▴
fofredux-devel — Developers discussion, bug fixing, and coding of fofredux
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(92) |
Dec
(142) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(65) |
Mar
(76) |
Apr
(172) |
May
(124) |
Jun
(45) |
Jul
(76) |
Aug
(78) |
Sep
(1) |
Oct
(20) |
Nov
(6) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(7) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Evan R. <eva...@gm...> - 2006-04-22 10:42:10
|
do we have a CSS expert amongst us? that you khaled? as i'm working on incorporating the user stuff into the install script, i'm using a tableless form, most of which i've adapted from http://jeffhowden.com/code/css/forms/, but as we don't want to steal his intellectual property, we should redo the css and so on. anyone want to volunteer? (i tend to get suicidal when i have to think about css... =3D) /evan |
|
From: Broken K. <kha...@gm...> - 2006-04-22 10:32:01
|
Part of the reason why WordPress is as popular as it is due to the ease of installation. I'm not saying that FOFR isn't easy to install but anything that makes it clear cut to the user how to work things through is a very good thing. In my eyes as the least code minded person around here I do think that having someone create a database, upload the files and that's all the editing they've got to do is a great boost in the usability of the software as it eliminates fears for first time users etc. Keeping things simple should be on the top of our agenda. Evan Roth wrote: > Hey guys, > > another open question... > > As I'm forced to redo the install script quite a bit to allow for user > input (first user info...) and then a submit to start the > install/update process, do we want to migrate the main config stuff to > the install script as well. That would mean that the user would not > have to edit config.php, but rather we generate it for him when he > enters his DB connection info in the install script. If needed, he > can go tweak the config file for the other parameters. > > Although, i want to avoid opening a can of worms...if there already is > a config.php, then we need to do an update, which could be a bit messy. > > Or do we forget it for now, and just go for the user info? > > /evan |
|
From: Evan R. <eva...@gm...> - 2006-04-22 08:58:09
|
Hey guys, another open question... As I'm forced to redo the install script quite a bit to allow for user inpu= t (first user info...) and then a submit to start the install/update process, do we want to migrate the main config stuff to the install script as well. That would mean that the user would not have to edit config.php, but rather we generate it for him when he enters his DB connection info in the install script. If needed, he can go tweak the config file for the other parameters. Although, i want to avoid opening a can of worms...if there already is a config.php, then we need to do an update, which could be a bit messy. Or do we forget it for now, and just go for the user info? /evan |
|
From: Broken K. <kha...@gm...> - 2006-04-21 23:36:38
|
I couldn't agree with you more Evan; I used to be EXACTLY like that, but that should come as no surprise, as I'm a designer and by nature like to make sure things look the part. I think the UI and setting up the support structure around the application will get more people involved. So from my POV as long as we keep things simple, make sure they work properly and have a wiki set up we should be much better prepared. Just wanted to say that I really think everyone is doing an amazing job and that I really believe FOFR will EXPLODE in the coming months over the next few releases, the UI interface, the plugin architecture and all the super special enhancements will get things rolling. Once we've got the next release done, I'll be sure to get the promotion machine working and get loads of the 9rulers using it and giving their views on their sites and whatnot. In case it didn't come across clearly I'm very proud and happy to be part of this team as I really believe in open source projects and this one is a clear and great example of what can be made of the model as a whole. Evan Roth wrote: > it's just like any project...in my day job i'm one of a few guys > leading a team of 10 ppl, and we are supporting various departments > using the same apps...a few 100 users. > the problem is, ppl with free software tend to bitch, but they also > usually realize that everyone is doing the best they can (normally in > their free time). problem is that when your dealing with the > corporate world, everyone thinks that their little requirement is more > important than the next, they can't work without it, and it has to be > done tomorrow. > > the best way to combat this that we've found (and it's nothing new) is > to have a clear roadmap, which is communicated to everyone so that > it's clear to all what to expect. > > it's something that might make sense to think about as we approach the > next few releases. > > but i still think the most important thing is simply get more ppl to > be downloading and using the software. and the new UI is probably one > of the most important aspects there. most ppl are superficial when > they look at software...if it doesn't look good, it's tossed. > > On 4/21/06, *Andrew Turner* <ajt...@hi... > <mailto:ajt...@hi...>> wrote: > > http://reblog.org/#download > > The GPL is also weird in how it applies to things. it's not always > clear to me. > > Anyways, there it is. i haven't had time to look through it or what > they're doing. But at this point, I would be kind of suprised if the > FoFRedux & reBlog looked much alike anymore. > > The other question is, looking at their boards, would we *want* that > many users? I mean, we're all volunteers. and it's cool to have a lot > of people excited about what you do. But I can't imagine how much the > devs are pulled in diff't directions. > > Now if FoFRedux just was sustaining as a job... :) > Andrew > > On 4/21/06, Evan Roth < eva...@gm... > <mailto:eva...@gm...>> wrote: > > side note on reblog: > > can you grab their source or are they just hosting? i skimmed > the site, but > > didnt find it in my first fly-by. i mean, in order to be in > compliance of > > the gpl, they should have to offer the code, correct? > > > > > > On 4/21/06, Andrew Turner <ajt...@hi... > <mailto:ajt...@hi...>> wrote: > > > > > On 4/21/06, Kevin <ke...@dr... <mailto:ke...@dr...>> wrote: > > > > > > Kevin doth declared: > > > When the plugin loads it would register itself and give some > indication of > > > what events it is interested in and what features it provides. > > > > > > > Right - so FoFRedux would walk the plugins/ directory and call > of each > > plugin's "register()" function, which would then call the > appropriate > > register_feed_creation(me) > > > > > > > At least one of the interfaces would be just for receiving > events. Some > > > useful hook points I can think of are: > > > > > > - before/after user authenticates > > > - before/after feed is added to the db > > > - before/after item is added to the db > > > - after feed is updated > > > - before feed is removed from the db > > > - before item is removed from the db > > > > > > If the plugin will be adding UI functionality, then these > would be useful > > > hook points: > > > > > > - before html output starts > > > - before html body is started > > > - before item is rendered on the page > > > - before feed is rendered on the page > > > > - after html body > > - by feed, do you mean "feed line"? > > > > > I think the "before" event listeners will work more like > intercepting > > > filters. Meaning: they are triggered before the operation > happens, so > > > they have the ability to alter and/or override the behavior of the > > > operation. (example: a third-party auth plugin would use a > 'before > > > authentication event' to do it's own authentication and > override the > > > default/built-in authentication method) > > > > so they block (or call?) the original behavior, but each plugin > decides? > > > > > > So, a couple of things we may like to do as plugins - to think about > > when implementing the plugin arch and new code moving about: > > > > 1) LDAP/other authentication scheme (captcha, sing a song) > > 2) Geo (after feed is added, parsing feeds on update, displaying > > feeds, displaying items, additional UI pages, additional rss) > > 3) Media - being able to load & play MP3's/video directly in the > HTML page > > 4) User views - the ability for any user to have their own > view.php ( > > I think this is what reBlog does?) > > > > Andrew > > > > > > > > > > -- > > Andrew Turner > > ajt...@hi... > <mailto:ajt...@hi...> 42.4266N x 83.4931W > > http://highearthorbit.com Northville, Michigan, USA > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, > security? > > Get stuff done quickly with pre-integrated technology to make > your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642 > <http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&dat%121642> > > _______________________________________________ > > Fofredux-devel mailing list > > Fof...@li... > <mailto:Fof...@li...> > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > > > > > > -- > Andrew Turner > ajt...@hi... > <mailto:ajt...@hi...> 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > > |
|
From: Evan R. <eva...@gm...> - 2006-04-21 19:52:34
|
it's just like any project...in my day job i'm one of a few guys leading a team of 10 ppl, and we are supporting various departments using the same apps...a few 100 users. the problem is, ppl with free software tend to bitch, but they also usually realize that everyone is doing the best they can (normally in their free time). problem is that when your dealing with the corporate world, everyon= e thinks that their little requirement is more important than the next, they can't work without it, and it has to be done tomorrow. the best way to combat this that we've found (and it's nothing new) is to have a clear roadmap, which is communicated to everyone so that it's clear to all what to expect. it's something that might make sense to think about as we approach the next few releases. but i still think the most important thing is simply get more ppl to be downloading and using the software. and the new UI is probably one of the most important aspects there. most ppl are superficial when they look at software...if it doesn't look good, it's tossed. On 4/21/06, Andrew Turner <ajt...@hi...> wrote: > > http://reblog.org/#download > > The GPL is also weird in how it applies to things. it's not always clear > to me. > > Anyways, there it is. i haven't had time to look through it or what > they're doing. But at this point, I would be kind of suprised if the > FoFRedux & reBlog looked much alike anymore. > > The other question is, looking at their boards, would we *want* that > many users? I mean, we're all volunteers. and it's cool to have a lot > of people excited about what you do. But I can't imagine how much the > devs are pulled in diff't directions. > > Now if FoFRedux just was sustaining as a job... :) > Andrew > > On 4/21/06, Evan Roth <eva...@gm...> wrote: > > side note on reblog: > > can you grab their source or are they just hosting? i skimmed the site= , > but > > didnt find it in my first fly-by. i mean, in order to be in compliance > of > > the gpl, they should have to offer the code, correct? > > > > > > On 4/21/06, Andrew Turner <ajt...@hi...> wrote: > > > > > On 4/21/06, Kevin <ke...@dr...> wrote: > > > > > > Kevin doth declared: > > > When the plugin loads it would register itself and give some > indication of > > > what events it is interested in and what features it provides. > > > > > > > Right - so FoFRedux would walk the plugins/ directory and call of each > > plugin's "register()" function, which would then call the appropriate > > register_feed_creation(me) > > > > > > > At least one of the interfaces would be just for receiving > events. Some > > > useful hook points I can think of are: > > > > > > - before/after user authenticates > > > - before/after feed is added to the db > > > - before/after item is added to the db > > > - after feed is updated > > > - before feed is removed from the db > > > - before item is removed from the db > > > > > > If the plugin will be adding UI functionality, then these would be > useful > > > hook points: > > > > > > - before html output starts > > > - before html body is started > > > - before item is rendered on the page > > > - before feed is rendered on the page > > > > - after html body > > - by feed, do you mean "feed line"? > > > > > I think the "before" event listeners will work more like intercepting > > > filters. Meaning: they are triggered before the operation happens, s= o > > > they have the ability to alter and/or override the behavior of the > > > operation. (example: a third-party auth plugin would use a 'before > > > authentication event' to do it's own authentication and override the > > > default/built-in authentication method) > > > > so they block (or call?) the original behavior, but each plugin decides= ? > > > > > > So, a couple of things we may like to do as plugins - to think about > > when implementing the plugin arch and new code moving about: > > > > 1) LDAP/other authentication scheme (captcha, sing a song) > > 2) Geo (after feed is added, parsing feeds on update, displaying > > feeds, displaying items, additional UI pages, additional rss) > > 3) Media - being able to load & play MP3's/video directly in the HTML > page > > 4) User views - the ability for any user to have their own view.php ( > > I think this is what reBlog does?) > > > > Andrew > > > > > > > > > > -- > > Andrew Turner > > ajt...@hi... 42.4266N x 83.4931W > > http://highearthorbit.com Northville, Michigan, USA > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, > security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > > _______________________________________________ > > Fofredux-devel mailing list > > Fof...@li... > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > > > > > > -- > Andrew Turner > ajt...@hi... 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > |
|
From: Andrew T. <ajt...@hi...> - 2006-04-21 19:36:53
|
On 4/21/06, Kevin <ke...@dr...> wrote: > > Kevin doth declared: > When the plugin loads it would register itself and give some indication o= f > what events it is interested in and what features it provides. > Right - so FoFRedux would walk the plugins/ directory and call of each plugin's "register()" function, which would then call the appropriate register_feed_creation(me) > At least one of the interfaces would be just for receiving events. Some > useful hook points I can think of are: > > - before/after user authenticates > - before/after feed is added to the db > - before/after item is added to the db > - after feed is updated > - before feed is removed from the db > - before item is removed from the db > > If the plugin will be adding UI functionality, then these would be useful > hook points: > > - before html output starts > - before html body is started > - before item is rendered on the page > - before feed is rendered on the page - after html body - by feed, do you mean "feed line"? > I think the "before" event listeners will work more like intercepting > filters. Meaning: they are triggered before the operation happens, so > they have the ability to alter and/or override the behavior of the > operation. (example: a third-party auth plugin would use a 'before > authentication event' to do it's own authentication and override the > default/built-in authentication method) so they block (or call?) the original behavior, but each plugin decides? So, a couple of things we may like to do as plugins - to think about when implementing the plugin arch and new code moving about: 1) LDAP/other authentication scheme (captcha, sing a song) 2) Geo (after feed is added, parsing feeds on update, displaying feeds, displaying items, additional UI pages, additional rss) 3) Media - being able to load & play MP3's/video directly in the HTML page 4) User views - the ability for any user to have their own view.php ( I think this is what reBlog does?) Andrew -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-21 19:05:12
|
Andrew sayeth: > So, how would the plugin arch look? Just provide an API?, something > like Wordpress (insinuate intself into various hook-locations), etc. When the plugin loads it would register itself and give some indication o= f what events it is interested in and what features it provides. At least one of the interfaces would be just for receiving events. Some useful hook points I can think of are: - before/after user authenticates - before/after feed is added to the db - before/after item is added to the db - after feed is updated - before feed is removed from the db - before item is removed from the db If the plugin will be adding UI functionality, then these would be useful hook points: - before html output starts - before html body is started - before item is rendered on the page - before feed is rendered on the page I think the "before" event listeners will work more like intercepting filters. Meaning: they are triggered before the operation happens, so they have the ability to alter and/or override the behavior of the operation. (example: a third-party auth plugin would use a 'before authentication event' to do it's own authentication and override the default/built-in authentication method) > But I agree, Plugins are great way to expand a system without having > to maintain it by the core dev. It gets users involved and dedicated > to a system, and they come up with some COOL things. Yup. Providing a plugin/extension interface is a very open, community minded thing to do. All good software does it to some extent. Where would we be without apache modules, or OS device drivers for that matter? --=20 Kevin |
|
From: Andrew T. <ajt...@hi...> - 2006-04-21 18:04:21
|
On 4/21/06, Kevin <ke...@dr...> wrote: > > > i don't see any reason to exclude ldap, i'm just not sure it's somethin= g > > that would be used too often. > > i'm just guessing, but i would imagine most fofr installs are for one > > user. > > in the first round, enabling a login adds a bit of security without > > requiring the user to put directory security on the site, which is > > probably > > a bit difficult for a novice user. > > > > ldap is more of an idustrial solution which you won't find on your norm= al > > user's box. hell, we have it at work, but we don't even bother connect= ing > > to it for our team's webapps. > > > > any way for us to figure out how many ppl would actually ldap? > > do any other major oss php projects use it? phpmyadmin doesn't, afaik. > > The demand for LDAP in this type of app is probably quite small. I think > this is another excellent candidate for a plugin. Agreed - I think the problem with LDAP is it would be a lot of work to add, maintain, support, with little user interest at this point. but as kevin points out... plugin. > ON PLUGINS: > If done right, plugins just might be the killer feature of fofredux. I > can think of many examples where plugins can offer more and better > features then we could ever fit into the core of the app without making i= t > big and very slow. It's already been requested: "I don't want the tag an= d > category features, how do I disable them?". Well, because they are core > features of the app, it is literally impossible to disable them without > completely gutting the app. If they were plugins, albeit builtin plugins= , > disabling them would be as easy a unchecking a box on a form. So, how would the plugin arch look? Just provide an API?, something like Wordpress (insinuate intself into various hook-locations), etc. But I agree, Plugins are great way to expand a system without having to maintain it by the core dev. It gets users involved and dedicated to a system, and they come up with some COOL things. > > -- > Kevin > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-21 17:46:18
|
> i don't see any reason to exclude ldap, i'm just not sure it's somethin= g > that would be used too often. > i'm just guessing, but i would imagine most fofr installs are for one > user. > in the first round, enabling a login adds a bit of security without > requiring the user to put directory security on the site, which is > probably > a bit difficult for a novice user. > > ldap is more of an idustrial solution which you won't find on your norm= al > user's box. hell, we have it at work, but we don't even bother connect= ing > to it for our team's webapps. > > any way for us to figure out how many ppl would actually ldap? > do any other major oss php projects use it? phpmyadmin doesn't, afaik. The demand for LDAP in this type of app is probably quite small. I think this is another excellent candidate for a plugin. ON PLUGINS: If done right, plugins just might be the killer feature of fofredux. I can think of many examples where plugins can offer more and better features then we could ever fit into the core of the app without making i= t big and very slow. It's already been requested: "I don't want the tag an= d category features, how do I disable them?". Well, because they are core features of the app, it is literally impossible to disable them without completely gutting the app. If they were plugins, albeit builtin plugins= , disabling them would be as easy a unchecking a box on a form. --=20 Kevin |
|
From: Evan R. <eva...@gm...> - 2006-04-21 16:35:09
|
i don't see any reason to exclude ldap, i'm just not sure it's something that would be used too often. i'm just guessing, but i would imagine most fofr installs are for one user. in the first round, enabling a login adds a bit of security without requiring the user to put directory security on the site, which is probably a bit difficult for a novice user. ldap is more of an idustrial solution which you won't find on your normal user's box. hell, we have it at work, but we don't even bother connecting to it for our team's webapps. any way for us to figure out how many ppl would actually ldap? do any other major oss php projects use it? phpmyadmin doesn't, afaik. /evan On 4/21/06, Jason Airlie <ja...@ja...> wrote: > > I know it's early yet, but will authentication via ldap be an option? > I'd love to offer fofredux to my users but I would need ldap support so > they could use the already existing Novell eDirectory accounts. > > P.S > I love fofredux, it's a great piece of software. The only way I could > keep up with the 120 feeds I subscribe to. If you aren't already aware > of it you might check out Reblog (http://www.reblog.org/), which is also > based on fof, for code you can steal. It has some nice features, but I > prefer fofredux. > > Andrew Turner wrote: > > On 4/20/06, Evan Roth <eva...@gm...> wrote: > >> i've begun to work on setting up the login...at least arranging my > thoughts. > >> > >> but some questions pop into mind: > >> 1. cookie vs. session: more feedback is still worthwhile here. hell= , > we > >> could do both, and allow the user to choose via preferences...but i'm > not a > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Andrew T. <ajt...@hi...> - 2006-04-21 15:58:43
|
On 4/21/06, Kevin <ke...@dr...> wrote: > Evan Roth wrote: > > i'd prefer to be able to sort my items by cache_time, rather than > > publish_time, to see the new items (to me!) always at the top. > > > Allowing the sort column to be configurable is on the feature list, I thi= nk. > > -Kevin Yes, sort-by will be selectable, as well as column order, and showing/hiding columns Andrew -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-21 14:23:38
|
Evan Roth wrote: > The cache_time has an attribute of 'ON UPDATE CURRENT_TIMESTAMP'. > This is obviously new in redux, since the original FoF did not use > cache_time. i was doing some tests last night, and it seems that the > first TIMESTAMP field in a table gets this attribute automagically > from ADODB (which was also not included in FoF, iirc). This is mysql doing it, not ADODB_Lite. If you enable FOF_DB_DEBUG, you can see all the SQL sent to the database. I can reproduce this with Mysql 4.1.11. The first timestamp column added to a table gets this attribute set.(ON UPDATE CURRENT_TIMESTAMP) If I reverse publish_time and cache_time in the table create statement, then publish_time get's this *feature*, instead of cache_time. Have you created a bug for this yet? I'll add it if I have time today.** <...> > one could argue that the cache_time is not important, since we have > publish time...but often they are largely different for me: > 1. being in germany, and reading mostly stuff from the homeland...i > am dealing with 6-9 hrs difference, which could not come through. > ie. published at 12:00 local time EST, but cached at 18:00 local time > CET. We convert all timestamps to GMT internally. (well, unix epoch seconds) which should eliminate timezone problems, at least in the DB. You can configure what your local time offset is on the options page. This is used when timestamps are displayed on the view page. We should probably make this smarter by allowing a timezone string to be entered instead of an hour offset value. > 2. and the most important point for me...often times there is a delay > from when content is published to when it shows up in an rss feed. > hence, we get a new item 2 hrs after it was really published, and > therefore, it won't show on the top of the list. > > i'd prefer to be able to sort my items by cache_time, rather than > publish_time, to see the new items (to me!) always at the top. > Allowing the sort column to be configurable is on the feature list, I think. -Kevin |
|
From: Jason A. <ja...@ja...> - 2006-04-21 13:29:14
|
I know it's early yet, but will authentication via ldap be an option? I'd love to offer fofredux to my users but I would need ldap support so they could use the already existing Novell eDirectory accounts. P.S I love fofredux, it's a great piece of software. The only way I could keep up with the 120 feeds I subscribe to. If you aren't already aware of it you might check out Reblog (http://www.reblog.org/), which is also based on fof, for code you can steal. It has some nice features, but I prefer fofredux. Andrew Turner wrote: > On 4/20/06, Evan Roth <eva...@gm...> wrote: >> i've begun to work on setting up the login...at least arranging my thoughts. >> >> but some questions pop into mind: >> 1. cookie vs. session: more feedback is still worthwhile here. hell, we >> could do both, and allow the user to choose via preferences...but i'm not a |
|
From: Evan R. <eva...@gm...> - 2006-04-21 08:34:41
|
The cache_time has an attribute of 'ON UPDATE CURRENT_TIMESTAMP'. This is obviously new in redux, since the original FoF did not use cache_time. i was doing some tests last night, and it seems that the first TIMESTAMP fiel= d in a table gets this attribute automagically from ADODB (which was also not included in FoF, iirc). when you are reading an item, it is ok, since the field value is correct. when you mark it read or save or do anything else to the record, this attribute triggers, and cache_time is rewritten to the time of the update. Thus, we lose the information when we stored this bit of data. If you ask me, i'd be of the opinion that we need 3 dates: when was it published -> taken from RSS when was it cached -> on insert when was it changed -> on update (ie. read, unread, saved, etc...) one could argue that the cache_time is not important, since we have publish time...but often they are largely different for me: 1. being in germany, and reading mostly stuff from the homeland...i am dealing with 6-9 hrs difference, which could not come through. ie. published at 12:00 local time EST, but cached at 18:00 local time CET. 2. and the most important point for me...often times there is a delay from when content is published to when it shows up in an rss feed. hence, we ge= t a new item 2 hrs after it was really published, and therefore, it won't sho= w on the top of the list. i'd prefer to be able to sort my items by cache_time, rather than publish_time, to see the new items (to me!) always at the top. On 4/21/06, Kevin <ke...@dr...> wrote: > > Evan Roth wrote: > ... > > in the end it's not absolutely necessary, but the auto-timestamping on > > cache_time needs to go. i suspect that the adodb stuff adds it, when > > we add the field, as it's the first timestamp in the table. > I still don't understand. What about the handling of the cache_time > field is wrong? Could you provide a test case so I can reproduce it? > > -Kevin > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Kevin <ke...@dr...> - 2006-04-21 06:17:04
|
Devs, A few things to note about the CVS -> SVN migration planned for Saturday sometime. *I will disable commits on the CVS repository as a first step. *once CVS is locked, it will remain in a read-only state from now on. *any changes not commited to CVS before the migration starts will need to be manually moved to an SVN working directory. *any commits made to SVN before the migration starts will be lost. I will request a fresh migrate from CVS after it is locked. -Kevin Kevin wrote: > I'd like to switch code repositories from CVS to Subversion this weekend. > > Here is my plan of how the SVN repository will be structured. We > currently don't have the website under source control. I thought it would > be good to add it. > > Comments are welcome on the schedule or repository structure. > > > /fofredux > /tags > /branches > /trunk > > /vendor > /ADODB_Lite > /magpierss > /<...> > > /website > /tags > /branches > /trunk > > > |
|
From: Kevin <ke...@dr...> - 2006-04-21 06:00:19
|
Evan Roth wrote: ... > in the end it's not absolutely necessary, but the auto-timestamping on > cache_time needs to go. i suspect that the adodb stuff adds it, when > we add the field, as it's the first timestamp in the table. I still don't understand. What about the handling of the cache_time field is wrong? Could you provide a test case so I can reproduce it? -Kevin |
|
From: Evan R. <eva...@gm...> - 2006-04-21 05:16:59
|
well, i never delete anything. so for me it's useful to have an idea when = i actually read something. and when it was cached is seperate data that shouldn't be tampered with. it's your basic principle of having an insert and update timestamp on the record. in the end it's not absolutely necessary, but the auto-timestamping on cache_time needs to go. i suspect that the adodb stuff adds it, when we ad= d the field, as it's the first timestamp in the table. i don't want the cache_time to be changed when i mark something read. (if we don't know whe= n it was marked read, then it's not a big problem right now) On 4/21/06, Kevin <ke...@dr...> wrote: > > > > hey guys, > > > > a side note i just remembered. > > > > in the feed items table, on my install, i've stripped out the > > auto-timestamping on the cache_time field...since this is actually > > changing > > valid data from the rss feed. in order to do it correctly, i'd add > > another > > field for date_changed or something, which is then updated when the use= r > > marks the item read (or whatever other action). > > > > any objections to me correcting that, or shall i just add it as a > > bug/feature request for the time-being? (if sourceforge wants to > work...i > > am getting only 500 errors tonight.) > > publish_time uses the timestamp from the rss feed. > cache_time is when it is inserted into the database. It is primarily use= d > for items deletes. We also display it in the view. > > Do we care when a user marks an item read? How is that useful? > > -- > Kevin > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Broken K. <kha...@gm...> - 2006-04-21 05:01:19
|
I've not done any coding whatsoever, as I'm thinking of staying clear of that, EXCEPT once you guys have put in the infrastructure in place. Once that's done then I'll start poking my ugly nose into the code and begin moving things/aligning and changing the colours etc (unless of course you guys are happy for me to splice the mockups and give the colour codes etc). I'm going to admit that I'm pretty sure you guys know how to structure things in a much more professional manner than I would. Just to confirm, this is the one I think we should be going for as it ties the best with the rest of the administration pages and the whole design in general. With respect to the sessions versus cookies, I was thinking about the whole login in from terminals etc and I can see that being a problem if said terminal doesn't have ff for example which deletes your session if you want it to... so go for the session I guess and we'll make a nice little area for that option of how long in the admin section. Evan Roth wrote: > i've begun to work on setting up the login...at least arranging my > thoughts. > > but some questions pop into mind: > 1. cookie vs. session: more feedback is still worthwhile here. > hell, we could do both, and allow the user to choose via > preferences...but i'm not a fan of doing work twice. but after giving > it more thought today, i'm leaning towards sessions. > 2. first user... i see 2 choices here as well, but there could be > more good ideas: > a. we modify the install.php to allow the user to define the first > user when he installs/updates the various tables. > b. no data is added to the table during install, but then the first > user to attempt to login is asked to confirm his pass, and he is > stored as an admin. > c. ??? anyone with other ideas? > > > andrew, i still need to be added to the project, so i can commit back > to svn. > > khaled, do you have the html for any of the login stuff yet? <div > class=""> etc... if so, ship it on over, and i'll use it, rather > than making you change whatever i throw in there for now.. > > ok, let me hear any other thoughts, i'm flexible to do whatever the > majority likes. > > /evan > |
|
From: Kevin <ke...@dr...> - 2006-04-20 22:06:15
|
> hey guys, > > a side note i just remembered. > > in the feed items table, on my install, i've stripped out the > auto-timestamping on the cache_time field...since this is actually > changing > valid data from the rss feed. in order to do it correctly, i'd add > another > field for date_changed or something, which is then updated when the use= r > marks the item read (or whatever other action). > > any objections to me correcting that, or shall i just add it as a > bug/feature request for the time-being? (if sourceforge wants to work.= ..i > am getting only 500 errors tonight.) publish_time uses the timestamp from the rss feed. cache_time is when it is inserted into the database. It is primarily use= d for items deletes. We also display it in the view. Do we care when a user marks an item read? How is that useful? --=20 Kevin |
|
From: Evan R. <eva...@gm...> - 2006-04-20 19:30:46
|
hey guys, a side note i just remembered. in the feed items table, on my install, i've stripped out the auto-timestamping on the cache_time field...since this is actually changing valid data from the rss feed. in order to do it correctly, i'd add another field for date_changed or something, which is then updated when the user marks the item read (or whatever other action). any objections to me correcting that, or shall i just add it as a bug/feature request for the time-being? (if sourceforge wants to work...i am getting only 500 errors tonight.) /evan |
|
From: Evan R. <eva...@gm...> - 2006-04-20 19:03:28
|
don't think it matters. i'd simply keep this in the trunk, and any bug fixes can be merged in then seperately. but in the end, it doesn't really matter. are you sure that i'm correctly added to the project? i'm trying to commit back the config.php.sample...and i am getting 403 Permission errors. (before i had gotten access denied) On 4/20/06, Andrew Turner <ajt...@hi...> wrote: > > On 4/20/06, Evan Roth <eva...@gm...> wrote: > > i've begun to work on setting up the login...at least arranging my > thoughts. > > > > but some questions pop into mind: > > 1. cookie vs. session: more feedback is still worthwhile here. hell, > we > > could do both, and allow the user to choose via preferences...but i'm > not a > > fan of doing work twice. but after giving it more thought today, i'm > > leaning towards sessions. > > I like sessions - as the nice thing of a web-based reader is being > able to read it from anywhere. This obviously implies public > terminals. Cookies are nice for someone usually logging in from a > desktop or same system. I would think wrapping this up into a > validate_user() function, put in sessions now, and we can add cookies > without changing anything else later. Then we can check session first, > then cookies (if the user clicked "remember me" when they logged in). > > > > 2. first user... i see 2 choices here as well, but there could be more > good > > ideas: > > a. we modify the install.php to allow the user to define the first use= r > > when he installs/updates the various tables. > > b. no data is added to the table during install, but then the first > user to > > attempt to login is asked to confirm his pass, and he is stored as an > admin. > > c. ??? anyone with other ideas? > > On the install page the user is asked for an initial > username/password/email address. This user is automatically an admin. > > > > > andrew, i still need to be added to the project, so i can commit back t= o > > svn. > Added, sf gave me more errors, but I bashed it into submission. > > > Question: do we want to keep all of this work on trunk and branch > RC-0_3_1 (b/c I'm sure there will be bug-fixes) or do we want to > branch this rework? > > > > > khaled, do you have the html for any of the login stuff yet? <div > class=3D""> > > etc... if so, ship it on over, and i'll use it, rather than making yo= u > > change whatever i throw in there for now.. > > > > ok, let me hear any other thoughts, i'm flexible to do whatever the > > majority likes. > > > > /evan > > > > > > > -- > Andrew Turner > ajt...@hi... 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Kevin <ke...@dr...> - 2006-04-20 18:59:45
|
> On 4/20/06, Evan Roth <eva...@gm...> wrote: >> i've begun to work on setting up the login...at least arranging my >> thoughts. >> >> but some questions pop into mind: >> 1. cookie vs. session: more feedback is still worthwhile here. hell= , >> we >> could do both, and allow the user to choose via preferences...but i'm >> not a >> fan of doing work twice. but after giving it more thought today, i'm >> leaning towards sessions. > > I like sessions - as the nice thing of a web-based reader is being > able to read it from anywhere. This obviously implies public > terminals. Cookies are nice for someone usually logging in from a > desktop or same system. I would think wrapping this up into a > validate_user() function, put in sessions now, and we can add cookies > without changing anything else later. Then we can check session first, > then cookies (if the user clicked "remember me" when they logged in). Cookies are simpler, but less flexible if you wanted to store additional info while the user is logged in. (caching things like config properties, etc) All that shouldn't go out to the client. > >> 2. first user... i see 2 choices here as well, but there could be mor= e >> good >> ideas: >> a. we modify the install.php to allow the user to define the first us= er >> when he installs/updates the various tables. >> b. no data is added to the table during install, but then the first >> user to >> attempt to login is asked to confirm his pass, and he is stored as an >> admin. >> c. ??? anyone with other ideas? > > On the install page the user is asked for an initial > username/password/email address. This user is automatically an admin. +1 for option a. Add the admin user via the install page. > > Question: do we want to keep all of this work on trunk and branch > RC-0_3_1 (b/c I'm sure there will be bug-fixes) or do we want to > branch this rework? If it's not going to cause too much chaos, let's keep it on trunk. Then put 0.3 in a release branch. Merging branches is a PITA. It took me hours to do the merge for tags. That was CVS, Subversion might be better= . --=20 Kevin |
|
From: Andrew T. <ajt...@hi...> - 2006-04-20 17:43:28
|
On 4/20/06, Evan Roth <eva...@gm...> wrote: > i've begun to work on setting up the login...at least arranging my though= ts. > > but some questions pop into mind: > 1. cookie vs. session: more feedback is still worthwhile here. hell, w= e > could do both, and allow the user to choose via preferences...but i'm not= a > fan of doing work twice. but after giving it more thought today, i'm > leaning towards sessions. I like sessions - as the nice thing of a web-based reader is being able to read it from anywhere. This obviously implies public terminals. Cookies are nice for someone usually logging in from a desktop or same system. I would think wrapping this up into a validate_user() function, put in sessions now, and we can add cookies without changing anything else later. Then we can check session first, then cookies (if the user clicked "remember me" when they logged in). > 2. first user... i see 2 choices here as well, but there could be more g= ood > ideas: > a. we modify the install.php to allow the user to define the first user > when he installs/updates the various tables. > b. no data is added to the table during install, but then the first user= to > attempt to login is asked to confirm his pass, and he is stored as an adm= in. > c. ??? anyone with other ideas? On the install page the user is asked for an initial username/password/email address. This user is automatically an admin. > > andrew, i still need to be added to the project, so i can commit back to > svn. Added, sf gave me more errors, but I bashed it into submission. Question: do we want to keep all of this work on trunk and branch RC-0_3_1 (b/c I'm sure there will be bug-fixes) or do we want to branch this rework? > > khaled, do you have the html for any of the login stuff yet? <div class= =3D""> > etc... if so, ship it on over, and i'll use it, rather than making you > change whatever i throw in there for now.. > > ok, let me hear any other thoughts, i'm flexible to do whatever the > majority likes. > > /evan > > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Evan R. <eva...@gm...> - 2006-04-20 17:22:48
|
i've begun to work on setting up the login...at least arranging my thoughts= . but some questions pop into mind: 1. cookie vs. session: more feedback is still worthwhile here. hell, we could do both, and allow the user to choose via preferences...but i'm not a fan of doing work twice. but after giving it more thought today, i'm leaning towards sessions. 2. first user... i see 2 choices here as well, but there could be more goo= d ideas: a. we modify the install.php to allow the user to define the first user when he installs/updates the various tables. b. no data is added to the table during install, but then the first user t= o attempt to login is asked to confirm his pass, and he is stored as an admin= . c. ??? anyone with other ideas? andrew, i still need to be added to the project, so i can commit back to svn. khaled, do you have the html for any of the login stuff yet? <div class=3D= ""> etc... if so, ship it on over, and i'll use it, rather than making you change whatever i throw in there for now.. ok, let me hear any other thoughts, i'm flexible to do whatever the majorit= y likes. /evan |
|
From: Evan R. <eva...@gm...> - 2006-04-20 05:18:56
|
yeah, for some reason i simply couldn't connect. i pumped up the subclipse version to 1.0.1 (was on 0.9.x) and it was able to work perfectly fine. although, it was very slow to do anything...but that could be related to other sf problems that andrew mentioned. so that's 1 vote cookies and 1 vote sessions.i really don't think cookies become a security issue for us, since you dont need to write much in there...login name and timestamp. if that's a security issue, then we are pretty strict. but either way is fine...i don't care. we can easily allow the session timeout to be defined in our options...so the user can easily change it himself. /evan On 4/20/06, Kevin <ke...@dr...> wrote: > > Evan Roth wrote: > > Hey, > > > > i'm trying to configure eclipse to connect to svn and at least get set > > up to start working on some of this stuff. i figure the first thing > > i'll tackle, unless someone has better idea or objections, would be > > the login functionality. it's something that can be squeezed into any > > release, since it's easier for the user than an htpasswd based variant. > > > What trouble are you having with eclipse+subversion? I just added the > repository and did a checkout. > The repository URL is: https://svn.sourceforge.net/svnroot/fofredux/ > > Currently, the path to checkout is */trunk/fofredux*. Once I do the > conversion this weekend it will be moved to */fofredux/trunk*. > > > what's your guys opinion on cookie vs session logins? i'd personally > > go for cookie, since a session could be problematic if someone reads > > his feeds longer than X minutes of the session timeout, then clicks > > mark as read. (ok, we could set session at like 2 hrs and avoid > > that...) but i'll go whatever direction the majority likes... > > > I prefer sessions. If timing out becomes an issue, we can use some > really large default like 1 day. When the browser closes, the session > cookie should expire. I think that's how it works. I hear they are > more secure, also, because all data stays server side, just the > session-id is sent to the client. > > -Kevin > |
5 messages has been excluded from this view by a project administrator.
