You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(29) |
Dec
(101) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(90) |
Feb
(101) |
Mar
(173) |
Apr
(141) |
May
(38) |
Jun
(28) |
Jul
(14) |
Aug
(7) |
Sep
(3) |
Oct
(7) |
Nov
(15) |
Dec
(9) |
2002 |
Jan
(2) |
Feb
(5) |
Mar
(11) |
Apr
|
May
(4) |
Jun
(6) |
Jul
(7) |
Aug
(12) |
Sep
(8) |
Oct
(1) |
Nov
(4) |
Dec
(7) |
2003 |
Jan
(7) |
Feb
(1) |
Mar
(9) |
Apr
(2) |
May
(3) |
Jun
(4) |
Jul
(19) |
Aug
(4) |
Sep
(8) |
Oct
(30) |
Nov
(25) |
Dec
(22) |
2004 |
Jan
(6) |
Feb
(12) |
Mar
|
Apr
(2) |
May
|
Jun
(10) |
Jul
(18) |
Aug
(2) |
Sep
(4) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
2005 |
Jan
(8) |
Feb
(4) |
Mar
(6) |
Apr
(5) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
|
2006 |
Jan
(9) |
Feb
(6) |
Mar
(11) |
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alexandre L. <ale...@ec...> - 2009-01-27 18:44:09
|
Hi list, Can anyone provide a short update status on the possibility or not of accessing the AJAX Slashcode code that Slashdot is using? I'd really like to migrate Slashgeo.org (about only 5000 unique IP addresses reached daily) to the AJAX code if it's not days and days of work. There was no answer to last June's request about the code by another fellow (http://sourceforge.net/mailarchive/message.php?msg_name=67AB45CA-169E-44D7-997B-F20DB2D31743%40lottadot.com - that was actually the only email on the list last year!). Thanks for any reply! :-) Alex -- Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre météorologique canadien / Canadian Meteorological Centre Section de la réponse aux urgences environnementales / Environmental Emergency Response Section ale...@ec... |
From: Shane Z. <sh...@lo...> - 2008-06-27 08:17:41
|
CVS Head doesn't seem to have updated from the new OSTG Git Repo since T_2_5_0_202. I can see the commits from the Git side, but nothing's been included in the CVS side for quite some time now (ie 2008-04-16) Any chance this this will be fixed soon? Thanks! Shane |
From: <fgi...@st...> - 2007-05-22 09:46:12
|
Hi, It turned out to be easier than I though to do what I wanted (with =20 CVS head as of a couple of weeks ago (start of May 2007)). I edited =20 the start of the handler in Slash::Apache::User (S::A::U) and added =20 this code: snip--- sub handler { =09my($r) =3D @_; =09return DECLINED unless $r->is_main; =09my $uri =3D $r->uri; # --new-- =09my $uid ; =09{ =09 my $user =3D $r->user; =09 my $slashdb =3D getCurrentDB(); =09 #print STDERR "User: ",$user,"\n"; =09 #print STDERR "UID: ",$slashdb->getUserUID($user),"\n"; =09 $uid =3D $slashdb->getUserUID($user); =09 if(!$uid){ =09=09# create user; =09=09my $matchname =3D nick2matchname($user); =09=09#print STDERR "Matchname: $matchname\n"; =09=09$uid=3D$slashdb->createUser( =09=09=09$matchname, $user."\@xxx.xx.ac.uk",$user); =09=09$slashdb->sqlUpdate('users', {newpasswd =3D> "foobar"}, 'uid=3D'.$uid)= ; =09 } my $newpass; =09 ($uid,$newpass)=3DuserLogin($slashdb->getUserUID($user),"foobar"); =09 #print STDERR "UID: $uid\n"; =09 #print STDERR "NEWPASS: $newpass\n"; =09 $r->subprocess_env(SLASH_USER =3D> $uid); =09} # --end of new-- snip--- About line 167 there's a "my $uid" which I've commented out. Then I removed the login form from index.shtml and edited the =20 default:misc:mainmenu template to remove the change password link. Then I edited apache's config to redirect any link for "login.pl" back =20 to the main page. Works like a treat. It still needs some optimization and I'll want to =20 abstract it bit, but basically it works. The one snag is that it doesn't log you in on the very first page, a =20 user needs to click on any link to get logged in. I need to find a way =20 to fake the cookie to fix this so I don't mess with the structure of =20 S::A::U too much. Yours Faye Quoting Clifton Wood <cli...@gm...>: > On 5/16/07, Faye Gibbins <fgi...@st...> wrote: >> >> Hi Cliff, >> >> Yep this helps. I did some more testing with a stripped down set of >> scripts and this is what I've found out: >> >> * User opens up a brand new Firefox session with no cookies or history >> of any sort. >> >> * Request comes in to apache and the first relavent thing apache does is >> PerlAccessHandler. $r->user is undefined. >> >> * Then apache (which is setup to do Cosign (i.e. kerberos with cookies) >> calls its Authentication routines but does not call PerlAuthenHandler, >> ever (or at least I can't get it to) > > Right. PerlAuthenHandler depends on there being an "AuthName", > "AuthType" and "require" directive in that configuration context. If > there isn't, then the handler isn't run. > >> >> * At this point the users is taken to another URL, asked to enter their >> password etc. Then they are returned to the original URL /with/ a brand >> new encrypted authentication (Cosgin) cookie. >> >> * So Apache starts up again and the call reaches PerlAccessHandler which >> now has a defined $r->user. > > Which is promising, because then stacked PerlAccessHandlers should work. > >> * Again Apache doesn't call PerlAuthenHandler. But does its cosign stuff >> again but as we have a valid cookie it passes through OK and doesn't >> redirect. >> >> * Then we get to PerlAuthzHandler, which does get called and has a >> defined $r->user. > > Ah! I thought PerlAuthzHandler was attached to PerlAuthenHandler. If > this isn't the case, then I was wrong in my previous email. > >> I.e, in order >> >> PerlAccessHandler >> Apache Auth >> PerlAccessHandler >> PerlAuthzHandler > > Well, yes -- however, according to an earlier paragraph, it's more like: > > PerlAccessHandler > (Slash may think we're anonymous but it doesn't matter > since we...) > Redirect > Apache Auth > PerlAccessHandler > PerlAuthzHandler > >> So the upshot of this is that I need to rely upon $r->user (and >> therefore REMOTE_USER). And it seems to me (but I'm prepared to stand >> corrected) that the first time Slash::Apache::User gets called it looks >> to slash like we're anonymous. >> >> What I've not investigated yet is weather slash gives me a cookie at >> that point which says "I'm anonymous". > > I'm not sure either, but if it does that cookie would be replaced by > the "I'm logged in cookie", otherwise there would be problems with > Slash. Moot point, I think. ^_^ > >> Which is why from MPOV it'd be better to either: >> >> 1) Move the whole shebang to PerlAuthzHandler, or >> 2) Leave the IP blocking stuff of Slash::Apache::User on the >> PerlAccessHandler and move every thing else to PerlAuthzHandler >> >> Either way instead of hacking my fix directly into Slash::Apache::User I >> might just put a hook into it and make things a bit more generic. > > Well, you could do that. I'd prefer a stacked PerlAccessHandler > because it seems to be more straight forward and would involve less > work on your end. However if you'd feel better doing things this way, > you'd probably be better off *subclassing* Slash::Apache::User in a > PLUGIN (which is basically a Perl module) and changing things there > [you can then "use base qw(Slash::Apache::User)" and when you need to > use the old behavior just make a call to SUPER:: > > Or you could just rewrite the class entirely to your liking, and use > that class for your handlers instead of Slash::Apache::User and do > things as you like it. The options are numerous. > >> If I get to to work I'll submit a patch. >> > > It's better that you do this in your own module first before worrying > about patching main Slash. Make sure you have something that works, > first. > > Good luck, Faye! > > - Cliff |
From: Clifton W. <cli...@gm...> - 2007-05-16 20:24:48
|
On 5/16/07, Faye Gibbins <fgi...@st...> wrote: > > Hi Cliff, > > Yep this helps. I did some more testing with a stripped down set of > scripts and this is what I've found out: > > * User opens up a brand new Firefox session with no cookies or history > of any sort. > > * Request comes in to apache and the first relavent thing apache does is > PerlAccessHandler. $r->user is undefined. > > * Then apache (which is setup to do Cosign (i.e. kerberos with cookies) > calls its Authentication routines but does not call PerlAuthenHandler, > ever (or at least I can't get it to) Right. PerlAuthenHandler depends on there being an "AuthName", "AuthType" and "require" directive in that configuration context. If there isn't, then the handler isn't run. > > * At this point the users is taken to another URL, asked to enter their > password etc. Then they are returned to the original URL /with/ a brand > new encrypted authentication (Cosgin) cookie. > > * So Apache starts up again and the call reaches PerlAccessHandler which > now has a defined $r->user. Which is promising, because then stacked PerlAccessHandlers should work. > * Again Apache doesn't call PerlAuthenHandler. But does its cosign stuff > again but as we have a valid cookie it passes through OK and doesn't > redirect. > > * Then we get to PerlAuthzHandler, which does get called and has a > defined $r->user. Ah! I thought PerlAuthzHandler was attached to PerlAuthenHandler. If this isn't the case, then I was wrong in my previous email. > I.e, in order > > PerlAccessHandler > Apache Auth > PerlAccessHandler > PerlAuthzHandler Well, yes -- however, according to an earlier paragraph, it's more like: PerlAccessHandler (Slash may think we're anonymous but it doesn't matter since we...) Redirect Apache Auth PerlAccessHandler PerlAuthzHandler > So the upshot of this is that I need to rely upon $r->user (and > therefore REMOTE_USER). And it seems to me (but I'm prepared to stand > corrected) that the first time Slash::Apache::User gets called it looks > to slash like we're anonymous. > > What I've not investigated yet is weather slash gives me a cookie at > that point which says "I'm anonymous". I'm not sure either, but if it does that cookie would be replaced by the "I'm logged in cookie", otherwise there would be problems with Slash. Moot point, I think. ^_^ > Which is why from MPOV it'd be better to either: > > 1) Move the whole shebang to PerlAuthzHandler, or > 2) Leave the IP blocking stuff of Slash::Apache::User on the > PerlAccessHandler and move every thing else to PerlAuthzHandler > > Either way instead of hacking my fix directly into Slash::Apache::User I > might just put a hook into it and make things a bit more generic. Well, you could do that. I'd prefer a stacked PerlAccessHandler because it seems to be more straight forward and would involve less work on your end. However if you'd feel better doing things this way, you'd probably be better off *subclassing* Slash::Apache::User in a PLUGIN (which is basically a Perl module) and changing things there [you can then "use base qw(Slash::Apache::User)" and when you need to use the old behavior just make a call to SUPER:: Or you could just rewrite the class entirely to your liking, and use that class for your handlers instead of Slash::Apache::User and do things as you like it. The options are numerous. > If I get to to work I'll submit a patch. > It's better that you do this in your own module first before worrying about patching main Slash. Make sure you have something that works, first. Good luck, Faye! - Cliff |
From: Faye G. <fgi...@st...> - 2007-05-16 08:31:54
|
Hi Cliff, Yep this helps. I did some more testing with a stripped down set of scripts and this is what I've found out: * User opens up a brand new Firefox session with no cookies or history of any sort. * Request comes in to apache and the first relavent thing apache does is PerlAccessHandler. $r->user is undefined. * Then apache (which is setup to do Cosign (i.e. kerberos with cookies) calls its Authentication routines but does not call PerlAuthenHandler, ever (or at least I can't get it to) * At this point the users is taken to another URL, asked to enter their password etc. Then they are returned to the original URL /with/ a brand new encrypted authentication (Cosgin) cookie. * So Apache starts up again and the call reaches PerlAccessHandler which now has a defined $r->user. * Again Apache doesn't call PerlAuthenHandler. But does its cosign stuff again but as we have a valid cookie it passes through OK and doesn't redirect. * Then we get to PerlAuthzHandler, which does get called and has a defined $r->user. I.e, in order PerlAccessHandler Apache Auth PerlAccessHandler PerlAuthzHandler --- So the upshot of this is that I need to rely upon $r->user (and therefore REMOTE_USER). And it seems to me (but I'm prepared to stand corrected) that the first time Slash::Apache::User gets called it looks to slash like we're anonymous. What I've not investigated yet is weather slash gives me a cookie at that point which says "I'm anonymous". --- Which is why from MPOV it'd be better to either: 1) Move the whole shebang to PerlAuthzHandler, or 2) Leave the IP blocking stuff of Slash::Apache::User on the PerlAccessHandler and move every thing else to PerlAuthzHandler Either way instead of hacking my fix directly into Slash::Apache::User I might just put a hook into it and make things a bit more generic. If I get to to work I'll submit a patch. Yours Faye Clifton Wood wrote: > Ah, you make a good point, here. It's probably easier to think about > things in this manner, and it's been a while since I've done mod_perl > 1 so I think I might have missed critical differences in each of the > necessary handlers -- there are *3*, not 2. Presented in the order > they execute (I hope I have this right): > > PerlAccessHandler - Determine if the client is to have access to a > specific resource, this is generally used to deal with IP banning as > such and doesn't require the need for specific credentials (usually > indicated by directives like "AuthType", "AuthName", and "require"). > THIS is why Slash uses this handler. Really, Slash::Apache::User is > probably doing too much, but since there is an IP ban list in Slash, > it was probably just easier to handle everything in one piece of > monolithic code. If other Slash sites needed the extra security, they > could handle those pieces on their own. As it is, the only > "authentication" necessary is handled by Slash's perl scripts and need > *not* be handled by specific client/server interaction. (as is the > case with PerlAuthenHandler and PerlAuthzHandler). The only > distinction that Slash cares about at this point is "logged in" and > "not logged in", and this is handled by the presence of a specific > cookie. All other security measures are handled by the script code, > not by specific server code. > > PerlAuthenHandler - Handles authorization, ala verifying user > credentials and the like. You would think that this would be the > natural place for your code, but it isn't, as it would require an > "AuthType", "AuthName" and "require" directive, which Slash doesn't > use. Since Slash has already done it's magic in PerlAccessHandler, > this also makes this handler redundant. > > PerlAuthzHandler - Determins if an *authenticated user* is to have > access to specific site resources. This assumes that a client *has > already authenticated* based on the results of PerlAuthenHandler and > is intrinsically linked to that particular phase. Since > PerlAuthenHandler isn't used for Slash, neither is PerlAuthzHandler. > > Slash doesn't need $REMOTE_USER to do it's magic, you do. What you > might want to try is to use stacked PerlAccessHandlers to check > $REMOTE_USER. You would perform this check and automatically generate > a properly formatted Slash cookie for that user, then let Slash's > existing code run afterwards to do that voodoo that it do. > > For your purposes, your code would need to run first, and then the > existing Slash handler would run last. > > PerlAccessHandler Slash::Apache::User::RemoteUserCheck Slash::Apache::User > > Here's an outline on how I think your PerlAccessHandler should work: > - Check $REMOTE_USER. Robust code says you should do this. Do not expect it > to exist. If it doesn't, fail out ("return > Apache::Constants::FORBIDDEN" -- > Apache::Constants::AUTH_REQUIRED might work here, too.). > - [optional] If it exists, perform a check to see if the Kerberos > credentials are valid. > - Do a query on the $REMOTE_USER user in the database, if she does not exist, > create an account with your default password. > - If any errors, return "Apache::Constants::SERVER_ERROR". > - If you get to this point with no problems, bake a properly formed > Slash cookie, > and send it to the client. > - Done. "return Apache::Constants::OK" > > I *think* this is how it should work. I had to go back to the mod_perl > 1.0 docs and check my assumptions and this is maybe the 3rd or 4th > version of this email since I got several things wrong! ;-) -- I'm > sure that probably doesn't instill great confidence in what I've > written above, but it's the best I've got to offer at this time. If > anyone else can correct any errors or misconceptions in the above, > please do. I know I ain't perfect and am not arrogant enough to push > forward that assertion. ^_^ > > Hope this helps! > > - Cliff > >> On 5/14/07, Faye Gibbins <fgi...@st...> wrote: >> Hi, >> >> Disclaimer: >> Please forgive a slashcode novice if this discussion covers >> well trod land. >> >> The default install of slashcode attaches Slash::Apache::User to >> PerlAccessHandler. >> >> PerlAccessHandler is run before PerlAuthenHandler which is in turn >> runs before PerlAuthzHandler. >> >> So if using Apache external authentication the REMOTE_USER env var is >> not available at the "PerlAccessHandler" but _is_ available at the >> "PerlAuthzHandler" phase. This makes it difficult to setup accounts >> based upon the Authentication phase. >> >> So to gain finer control over user access would it not make sense to >> move Slash::Apache::User to the PerlAuthzHandler phase? >> >> Yours >> Faye >> >> -- >> --------------------------------------------------------- >> Faye Gibbins, Computing Officer (Infrastructure Services) >> GeoS KB; Linux, Unix, Security and Networks; 0131 6506426 >> --------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > https://lists.sourceforge.net/lists/listinfo/slashcode-development > -- --------------------------------------------------------- Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks; 0131 6506426 --------------------------------------------------------- |
From: Clifton W. <cli...@gm...> - 2007-05-15 22:49:01
|
Ah, you make a good point, here. It's probably easier to think about things in this manner, and it's been a while since I've done mod_perl 1 so I think I might have missed critical differences in each of the necessary handlers -- there are *3*, not 2. Presented in the order they execute (I hope I have this right): PerlAccessHandler - Determine if the client is to have access to a specific resource, this is generally used to deal with IP banning as such and doesn't require the need for specific credentials (usually indicated by directives like "AuthType", "AuthName", and "require"). THIS is why Slash uses this handler. Really, Slash::Apache::User is probably doing too much, but since there is an IP ban list in Slash, it was probably just easier to handle everything in one piece of monolithic code. If other Slash sites needed the extra security, they could handle those pieces on their own. As it is, the only "authentication" necessary is handled by Slash's perl scripts and need *not* be handled by specific client/server interaction. (as is the case with PerlAuthenHandler and PerlAuthzHandler). The only distinction that Slash cares about at this point is "logged in" and "not logged in", and this is handled by the presence of a specific cookie. All other security measures are handled by the script code, not by specific server code. PerlAuthenHandler - Handles authorization, ala verifying user credentials and the like. You would think that this would be the natural place for your code, but it isn't, as it would require an "AuthType", "AuthName" and "require" directive, which Slash doesn't use. Since Slash has already done it's magic in PerlAccessHandler, this also makes this handler redundant. PerlAuthzHandler - Determins if an *authenticated user* is to have access to specific site resources. This assumes that a client *has already authenticated* based on the results of PerlAuthenHandler and is intrinsically linked to that particular phase. Since PerlAuthenHandler isn't used for Slash, neither is PerlAuthzHandler. Slash doesn't need $REMOTE_USER to do it's magic, you do. What you might want to try is to use stacked PerlAccessHandlers to check $REMOTE_USER. You would perform this check and automatically generate a properly formatted Slash cookie for that user, then let Slash's existing code run afterwards to do that voodoo that it do. For your purposes, your code would need to run first, and then the existing Slash handler would run last. PerlAccessHandler Slash::Apache::User::RemoteUserCheck Slash::Apache::User Here's an outline on how I think your PerlAccessHandler should work: - Check $REMOTE_USER. Robust code says you should do this. Do not expect it to exist. If it doesn't, fail out ("return Apache::Constants::FORBIDDEN" -- Apache::Constants::AUTH_REQUIRED might work here, too.). - [optional] If it exists, perform a check to see if the Kerberos credentials are valid. - Do a query on the $REMOTE_USER user in the database, if she does not exist, create an account with your default password. - If any errors, return "Apache::Constants::SERVER_ERROR". - If you get to this point with no problems, bake a properly formed Slash cookie, and send it to the client. - Done. "return Apache::Constants::OK" I *think* this is how it should work. I had to go back to the mod_perl 1.0 docs and check my assumptions and this is maybe the 3rd or 4th version of this email since I got several things wrong! ;-) -- I'm sure that probably doesn't instill great confidence in what I've written above, but it's the best I've got to offer at this time. If anyone else can correct any errors or misconceptions in the above, please do. I know I ain't perfect and am not arrogant enough to push forward that assertion. ^_^ Hope this helps! - Cliff >On 5/14/07, Faye Gibbins <fgi...@st...> wrote: > Hi, > > Disclaimer: > Please forgive a slashcode novice if this discussion covers > well trod land. > > The default install of slashcode attaches Slash::Apache::User to > PerlAccessHandler. > > PerlAccessHandler is run before PerlAuthenHandler which is in turn > runs before PerlAuthzHandler. > > So if using Apache external authentication the REMOTE_USER env var is > not available at the "PerlAccessHandler" but _is_ available at the > "PerlAuthzHandler" phase. This makes it difficult to setup accounts > based upon the Authentication phase. > > So to gain finer control over user access would it not make sense to > move Slash::Apache::User to the PerlAuthzHandler phase? > > Yours > Faye > > -- > --------------------------------------------------------- > Faye Gibbins, Computing Officer (Infrastructure Services) > GeoS KB; Linux, Unix, Security and Networks; 0131 6506426 > --------------------------------------------------------- |
From: Faye G. <fgi...@st...> - 2007-05-14 11:00:08
|
Hi, Disclaimer: Please forgive a slashcode novice if this discussion covers well trod land. The default install of slashcode attaches Slash::Apache::User to PerlAccessHandler. PerlAccessHandler is run before PerlAuthenHandler which is in turn runs before PerlAuthzHandler. So if using Apache external authentication the REMOTE_USER env var is not available at the "PerlAccessHandler" but _is_ available at the "PerlAuthzHandler" phase. This makes it difficult to setup accounts based upon the Authentication phase. So to gain finer control over user access would it not make sense to move Slash::Apache::User to the PerlAuthzHandler phase? Yours Faye -- --------------------------------------------------------- Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks; 0131 6506426 --------------------------------------------------------- |
From: shane <sh...@lo...> - 2007-05-03 15:37:08
|
On May 3, 2007, at 3:51 AM, Faye Gibbins wrote: > > Hi, > > I'm a Sys Admin at Edinburgh Uni, Scotland. I'm doing work on > installing slash as a non root user in SSL enabled apache servers > which > use external authentication (I'm also a PostgreSQL DBA, so I might > touch > on that as well). My primary platforms are SL4, RHEL4 and FC6. > > I'm fluent in Perl/SQL and would like to contribute patches to the > slash code as and when I find bugs and possible enhancements. > > Please let me know the etiquette/methodology for doing so. > > Yours > Faye Gibbins Welcome aboard :) Here's my understanding of how OSTG wants things: When you diff: diff -N -U3 -xCVS -r from the root of your CVS checkout. When you find what you think is a bug, goto Slashcode's SF homepage and browse the bug list: http://sourceforge.net/tracker/?group_id=4421&atid=104421 If you don't find anything relevant, then create a new bug report. Keep in mind the version of Slashcode you are using, however. Because if you are using an older T_ or R_ tag, what you are reporting on may have already been fixed by someone, but there's no mention of it in Slash's SF. That's about it. I try to, if I think I've found a bug, submit a diff with it to patch if I can. Same with feature requests. Like many opensource projects, the easier you can make it for those w/ commit access to make the change, the higher the odds are that what you want done will be included :) You should hop on the IRC channel if you can, too. Shane -- My slashcode stuff: http://slash.lottadot.com/ Slashcode faq: http://slash.lottadot.com/slash-faq How to ask a question: http://www.catb.org/~esr/faqs/smart- questions.html#before |
From: Faye G. <fgi...@st...> - 2007-05-03 07:51:47
|
Hi, I'm a Sys Admin at Edinburgh Uni, Scotland. I'm doing work on installing slash as a non root user in SSL enabled apache servers which use external authentication (I'm also a PostgreSQL DBA, so I might touch on that as well). My primary platforms are SL4, RHEL4 and FC6. I'm fluent in Perl/SQL and would like to contribute patches to the slash code as and when I find bugs and possible enhancements. Please let me know the etiquette/methodology for doing so. Yours Faye Gibbins Sys. Admin., Edinburgh University Secretary of the Edinburgh Linux Users Group (EdLUG). -- --------------------------------------------------------- Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks; 0131 6506426 --------------------------------------------------------- |
From: shane <sh...@lo...> - 2007-04-18 23:13:36
|
FYI, If you've ever written a plugin that uses Slash::Messages, as of T_2_5_0_143 the schema's changed. It now uses a message_deliverymodes. If you update your install to that tag or later w/o modifying your code, well, bad things may happen ;) Shane |
From: Chris N. <pu...@po...> - 2006-12-02 00:29:30
|
Because of a change in U.S. law in 2005 (and in Canada, where most provinces have followed suit), DST is now a few weeks longer. Which means Slash needs a small update. Here's the SQL line to run (and it will be added to the sql/upgrades file next week). REPLACE INTO dst (region, selectable, start_hour, start_wnum, start_wday, start_month, end_hour, end_wnum, end_wday, end_month) VALUES ('America', 1, 2, 2, 0, 2, 2, 1, 0, 10); Don't forget to run it before DST starts again, at 2 a.m. on the second Sunday in March (March 11 this coming year). -- Chris Nandor pu...@po... http://pudge.net/ Open Source Technology Group pu...@os... http://ostg.com/ |
From: Jayaprakash S - T. Chennai. <jpr...@hc...> - 2006-11-13 09:51:20
|
Hello All, I am using digi me with uCLinux. I am trying to loopback the serial = port through a small program. I am able to send the characters without any problem, but the receive fails. It either returns 'a' or 'EAGAIN' (I am using non-blocking serial port). I am not clear on how many ports the = digi can control at a time. I am using both the ports. One for console and = the other for my loopback test (The tx and rx are connected via a mating connector). Any pointers for me would be of great help. Here is my serial port setup: // Get the current options for the port... tcgetattr(fd, &options); // Set the baud rates to 19200... cfsetispeed(&options, B19200); cfsetospeed(&options, B19200); // Enable the receiver and set local mode... options.c_cflag |=3D (CLOCAL | CREAD); options.c_cflag &=3D ~PARENB; options.c_cflag &=3D ~CSTOPB; options.c_cflag &=3D ~CSIZE; options.c_cflag |=3D CS8; // Set the new options for the port... tcsetattr(fd, TCSANOW, &options); Thanks in Advance, JP. DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. |
From: shane <sh...@lo...> - 2006-09-14 13:32:25
|
On Sep 13, 2006, at 11:48 PM, Imtiaz A khan wrote: > > Hi Shane, > Here's what I did : > checked out the latest R tag from the CVS tree > cvs -d:pserver:ano...@sl...:/cvsroot/ > slashcode login > cvs -d:pserver:ano...@sl...:/cvsroot/ > slashcode co -P -r R_2_5_0_94 slash > removed older instances of the install by dropping the slashdb > database and the /usr/local/slash directory as well as removing the > Include statements from Apache. > did a make followed by make install > did a install-slashsite -u virtuser > added Include to Apache and restarted Apache > started slash > > Now the problem I am facing are: > I dont have a sections table in slashdb > I dont have a sections.pl > subsequently if I go to edit a section I get the 404 "The requested > URL (sections.pl?op=list) was not found." Sections.pl, as well as any section* is depricated in that version of Slash. You want to setup you *skins* and Topic Nexus's. > I am assuming that I should be selecting the sections plugin in the > list of plugins when prompted to do so, but you were categorical > about not doing so. Please advise if I should answer 'a' when asked > the question "Hit 'a' to select all, otherwise select comma > separated numbers or 'q' to quit" or 'q' during install-slashsite You want to install only the default list of plugins. Do not add any. I think you'd just 'press q'. > > Thanks a lot for your help I'm sure it's just a little more effort > and I'll be able to make subdomains and get to using slashcode to > run my websites. Because the section stuff is depricated, that's why I was suggesting you grab the skins editor. I wrote it for inclusion into the standard code. It's been submitted to the OSTG crew, I'm sure when they have time to look at it it'll get included in the standard distribution of code. Until then, that's why I mentioned you can go grab it. It's a GUI to let you setup your skins. Otherwise, you'll have to do similar to this: INSERT INTO skins (skid, nexus, name, title, issue, url, hostname, cookiedomain, last_rewrite) VALUES (29,13,'convention','Convention','yes','','','',20040110235000); where an topic already exists at the skins.tid that you are specifying that points to a tid in table topic_nexus. The topic stuff you can setup w/ the httpd slash-admin gui. But the skins, unless you grab that plugin, you'll have to create using SQL. Don't forget to setup the CSS for each too. INSERT INTO css (rel, type, media, file, title, skin, page, admin, theme, ctid, ordernum, ie_cond) VALUES ('stylesheet','text/ css','screen, projection','foobar.css','','foorbar','','no','',2,0,''); etc. If you haven't looked at how to create a theme for your site, you may want to look at it. Over time, having a seperate theme for your site, rather then it using the slashcode theme, can be very time saving if you plan to make cosmetic changes to your site. If you don't plan on lots of cosmetic changes, nor template changes, then I don't know that I'd bother with a theme. theme-howto: http://slash.lottadot.com/ article.pl?sid=03/06/17/224243 Shane -- My slashcode stuff: http://slash.lottadot.com/ Slashcode faq: http://slash.lottadot.com/slash-faq How to ask a question: http://www.catb.org/~esr/faqs/smart- questions.html#before |
From: Imtiaz A k. <kha...@gm...> - 2006-09-14 03:48:42
|
Hi Shane, Here's what I did : 1. checked out the latest R tag from the CVS tree * cvs -d:pserver:ano...@sl...:/cvsroot/slashcode login * cvs -d:pserver:ano...@sl...:/cvsroot/slashcode co -P -r *R_2_5_0_94* slash 2. removed older instances of the install by dropping the slashdb database and the /usr/local/slash directory as well as removing the Include statements from Apache. 3. did a make followed by make install 4. did a install-slashsite -u virtuser 5. added Include to Apache and restarted Apache 6. started slash Now the problem I am facing are: * I dont have a sections table in slashdb * I dont have a sections.pl * subsequently if I go to edit a section I get the 404 "/The requested URL (sections.pl?op=list) was not found."/ I am assuming that I should be selecting the sections plugin in the list of plugins when prompted to do so, but you were categorical about not doing so. Please advise if I should answer 'a' when asked the question /"Hit 'a' to select all, otherwise select comma separated numbers or 'q' to quit" /or 'q' during install-slashsite Thanks a lot for your help I'm sure it's just a little more effort and I'll be able to make subdomains and get to using slashcode to run my websites. Warm Regards Imtiaz 919821540543 shane wrote: > > On Sep 13, 2006, at 4:08 AM, Imtiaz Khan wrote: > >> must be the CVS checkout as when using slashcode-2.2.6 I was able to >> install without any errors and now sections, topics, blocks etc all >> show up fine. >> >> For the packaging department :) probably need the CVS tree fixed >> >> -Imtiaz >> >> On 9/13/06, *Imtiaz Khan* <kha...@gm... >> <mailto:kha...@gm...>> wrote: >> >> OK I tried to install slashcode with all modules selected (this >> is at the install-slashsite stage) and got an error: >> >> Error:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:368:virtuser='virtslash' >> -- hostinfo='Localhost via UNIX socket' -- Table >> 'slashdb.sections' doesn't exist -- INSERT into sections >> (section, artcount, title) VALUES ('newsvac', 0, 'NewsVac Links') >> Which was called >> by:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:167 >> >> === (NewsVac) Failed on :INSERT into sections (section, artcount, >> title) VALUES ('newsvac', 0, 'NewsVac Links'): >> >> >> >> The site is working but maybe sections isn't. >> >> I checked /usr/local/slash/sql/mysql/schema.sql and there's no >> table named sections being created there. This is the CVS >> checkout from about four days back. Could this be a broken source >> problem? >> >> -Imtiaz >> >> >> > > You want to use the last T-tag from CVS. Get a checkout of slash-HEAD. > Then read the INSTALL. Make sure you understand what it says about how > slash does versions and re-visioning. Don't use 2.2.6 version of > Slash. (See list-serve archives for prior in-depth discussion on why > that's a bad thing to start off at, at this day and age.) > > Then, decide whether you want to run the latest T-tag, R-tag or HEAD. > Grab whichever you've chosen from CVS. > > Wipe your current install - rm -fR /usr/local/slash > make install the src. > drop and create the mysql database that your virtual user is to use. > run install-slashsite. > > install *ONLY* the default plugins. > > The install will work, and the site will function, and it will have > the "latest CSS" that you mentioned in another post. > > Now, go read the Nexus/topic information articles on > Lottadot. http://slash.lottadot.com/ > > You'll want create topic nexus's, for each skin (aka section). Think > of it as 'section == 'a skinned nexus'. > > You can either create the skins by hand (by SQL inserts) or you can > grab the Skin's editor from http://cvs.lottadot.com/ (follow the > instructions to install it). That'll give you a GUI interface to > manage your skins. > > That's it. > > Once you are at the point where the site's setup, the subdomains are > setup, the Nexus and skins are setup for the subdomains *then* you can > go and try experimenting with extra plugins. But even then, I'd > recommend you do that on a development system, especially if the > plugin is not included w/ the standard distro. And if you find you > like the plugin, then install it using the install-plugin tool (after > you've backed up) on your production webserver. > > Shane > > > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >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?cmd=lnk&kid=120709&bid=263057&dat=121642 > >------------------------------------------------------------------------ > >_______________________________________________ >Slashcode-development mailing list >Sla...@li... >https://lists.sourceforge.net/lists/listinfo/slashcode-development > > |
From: shane <sh...@lo...> - 2006-09-13 17:47:21
|
On Sep 13, 2006, at 4:08 AM, Imtiaz Khan wrote: > must be the CVS checkout as when using slashcode-2.2.6 I was able > to install without any errors and now sections, topics, blocks etc > all show up fine. > > For the packaging department :) probably need the CVS tree fixed > > -Imtiaz > > On 9/13/06, Imtiaz Khan <kha...@gm...> wrote: > OK I tried to install slashcode with all modules selected (this is > at the install-slashsite stage) and got an error: > > Error:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686- > linux/Slash/Install.pm:368:virtuser='virtslash' -- > hostinfo='Localhost via UNIX socket' -- Table 'slashdb.sections' > doesn't exist -- INSERT into sections (section, artcount, title) > VALUES ('newsvac', 0, 'NewsVac Links') > Which was called by:Slash::Install:/usr/local/lib/perl5/site_perl/ > 5.8.8/i686-linux/Slash/Install.pm:167 > === (NewsVac) Failed on :INSERT into sections (section, artcount, > title) VALUES ('newsvac', 0, 'NewsVac Links'): > > > > The site is working but maybe sections isn't. > > I checked /usr/local/slash/sql/mysql/schema.sql and there's no > table named sections being created there. This is the CVS checkout > from about four days back. Could this be a broken source problem? > > -Imtiaz > > You want to use the last T-tag from CVS. Get a checkout of slash- HEAD. Then read the INSTALL. Make sure you understand what it says about how slash does versions and re-visioning. Don't use 2.2.6 version of Slash. (See list-serve archives for prior in-depth discussion on why that's a bad thing to start off at, at this day and age.) Then, decide whether you want to run the latest T-tag, R-tag or HEAD. Grab whichever you've chosen from CVS. Wipe your current install - rm -fR /usr/local/slash make install the src. drop and create the mysql database that your virtual user is to use. run install-slashsite. install *ONLY* the default plugins. The install will work, and the site will function, and it will have the "latest CSS" that you mentioned in another post. Now, go read the Nexus/topic information articles on Lottadot. http:// slash.lottadot.com/ You'll want create topic nexus's, for each skin (aka section). Think of it as 'section == 'a skinned nexus'. You can either create the skins by hand (by SQL inserts) or you can grab the Skin's editor from http://cvs.lottadot.com/ (follow the instructions to install it). That'll give you a GUI interface to manage your skins. That's it. Once you are at the point where the site's setup, the subdomains are setup, the Nexus and skins are setup for the subdomains *then* you can go and try experimenting with extra plugins. But even then, I'd recommend you do that on a development system, especially if the plugin is not included w/ the standard distro. And if you find you like the plugin, then install it using the install-plugin tool (after you've backed up) on your production webserver. Shane |
From: Imtiaz K. <kha...@gm...> - 2006-09-13 08:08:37
|
must be the CVS checkout as when using slashcode-2.2.6 I was able to install without any errors and now sections, topics, blocks etc all show up fine. For the packaging department :) probably need the CVS tree fixed -Imtiaz On 9/13/06, Imtiaz Khan <kha...@gm...> wrote: > > OK I tried to install slashcode with all modules selected (this is at the > install-slashsite stage) and got an error: > > Error:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:368:virtuser='virtslash' > -- hostinfo='Localhost via UNIX socket' -- Table 'slashdb.sections' > doesn't exist -- INSERT into sections (section, artcount, title) VALUES > ('newsvac', 0, 'NewsVac Links') > Which was called > by:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:167 > > === (NewsVac) Failed on :INSERT into sections (section, artcount, title) > VALUES ('newsvac', 0, 'NewsVac Links'): > > > > The site is working but maybe sections isn't. > > I checked /usr/local/slash/sql/mysql/schema.sql and there's no table named > sections being created there. This is the CVS checkout from about four days > back. Could this be a broken source problem? > > -Imtiaz > -- Bye for now Imtiaz A. Khan ============= I just need enough to tide me over until I need more. -- Bill Hoest Lack of money is the root of all evil. -- George Bernard Shaw So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand All I want is a little more than I'll ever get. |
From: Imtiaz K. <kha...@gm...> - 2006-09-13 07:57:44
|
OK I tried to install slashcode with all modules selected (this is at the install-slashsite stage) and got an error: Error:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:368:virtuser='virtslash' -- hostinfo='Localhost via UNIX socket' -- Table 'slashdb.sections' doesn't exist -- INSERT into sections (section, artcount, title) VALUES ('newsvac', 0, 'NewsVac Links') Which was called by:Slash::Install:/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Slash/Install.pm:167 === (NewsVac) Failed on :INSERT into sections (section, artcount, title) VALUES ('newsvac', 0, 'NewsVac Links'): The site is working but maybe sections isn't. I checked /usr/local/slash/sql/mysql/schema.sql and there's no table named sections being created there. This is the CVS checkout from about four days back. Could this be a broken source problem? -Imtiaz |
From: Imtiaz K. <kha...@gm...> - 2006-09-13 07:42:39
|
Hi Shane, As I said earlier, I'm pretty new to slashcode (about a week now though), and am not very sure how to go about the virtual hosting for subdomains. Hacking around I was able to figure out that if I had multiple virtual users I could add more slashsites to the same host and run them all at the same time. So here's what I did: 1. prepared the server for slash by removing all preinstalled stuff that would've conflicted (Perl, Apache, MySQL) 2. Reinstalled from source using documentation at slashcode.org 3. downloaded the latest css enabled slash from CVS (version 2.2.6 I believe but I could be wrong as I got it from CVS and it doesn't really say which version it i even in the CHANGES file) 4. setup a virtual user lets call it virtslash 5. did a install-slashsite for my primary site using one virtual user 6. got the site up and running 7. next I added a new virtual user to DBIx::Password and created a MySQL database for this user 8. setup the second subdomain using the virtual user added in step 6 by running a install-slashsite and providing new user when asked for it 9. did the include jazz and tested both sites as running indepedently Now my requirement is that these should be able to share data. But it seems, and actually rightfully so, that that is not possible or at the very least not adviseable. I tried getting the lottadot plugin but seems the cvs server is not working. Will try again or maybe install the slashcode once again with all modules selected, I think lottadot was an option there. Could you, or anyone else on the list, kindly detail the steps involved in setting up sections and then using them for the subdomains. So for example if I setup a section named rock (we're doing a music site) and I want to make that section the doc root for say rock.domain.com then how should I actually go about it. Even if it's a readme which I have not been able to find the help would be greatly appreciated. Thanks in Advance Warm Regards Imtiaz On 9/12/06, Imtiaz A khan <kha...@gm...> wrote: > > > > Hi, > I was finally able to setup slashcode and get it working as well as get > subdomains going. I used multiple virtual users and multiple databases for > the subdomains. Now my question is : > > > Is it possible to have one central database for all of the subdomains? This > way, when a user logs into the homepage or any of the subdomains, he will be > logged into the entire site (this is what we want). It also may be easier > to set up the subdomains to pull from this central database according to > different parameters (for example: only display rock stories). > I see on slashdot.org that they have multiple stories listed on the front > page and these come from different subdomains. Is that a plugin at work and > if yes what should I be looking at? > I would very much like to have a single sign-on for all subdomains and > content sharing between all, however if that is not something slashcode > provides as a functionality is it atleast possible to get content from > subdomains listed on the main page as is done on slashdot.org. > > Thanks in advance for your help > > Warm Regards > Imtiaz > kha...@gm... > > > > > -- Bye for now Imtiaz A. Khan ============= I just need enough to tide me over until I need more. -- Bill Hoest Lack of money is the root of all evil. -- George Bernard Shaw So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand All I want is a little more than I'll ever get. |
From: shane <sh...@lo...> - 2006-09-12 20:42:05
|
What version of slash are you using? After you installed the source- and you installed your slash site, what'd you do exactly? For your subdomains, did you install a new slashsite, or did you create a new section (or skin, depending on the version of slash you are using)? Typically, one installs the src code (make install), then runs install-slashsite to create a website that's slashcode-based. Then, when the site grows, they create a skin (or section if you're using an older version of slash), define a url (ie http:// {subdomain}.mytld.org } for that skin, add the URL to their httpd config and restart httpd. What is abnormal about what you are saying is that you're talking about having multiple virtual users and db's. If you ran install-slashsite for your main TLD, and then ran install- slashsite for each subdomain, then what you did was created unique websites (and a unique slashcode website) for each URL. And if that is indeed what you did, there is no published automated way to combine these, atleast that I'm aware of. I've never heard of anyone doing it this way before. If this is what you did, I would delete the website instances for the subdomains, add the subdomains to the base- website's skins, The way that slashdot associates one story with multiple skins on their website is stock code. See http://slash.lottadot.com/article.pl?sid=04/06/18/001233 http://slash.lottadot.com/article.pl?sid=05/01/03/1250230 for more of an explanation. Shane On Sep 12, 2006, at 1:56 PM, Imtiaz A khan wrote: > Hi, > I was finally able to setup slashcode and get it working as well as > get subdomains going. I used multiple virtual users and multiple > databases for the subdomains. Now my question is : > > Is it possible to have one central database for all of the > subdomains? This way, when a user logs into the homepage or any of > the subdomains, he will be logged into the entire site (this is > what we want). It also may be easier to set up the subdomains to > pull from this central database according to different parameters > (for example: only display rock stories). > I see on slashdot.org that they have multiple stories listed on the > front page and these come from different subdomains. Is that a > plugin at work and if yes what should I be looking at? > I would very much like to have a single sign-on for all subdomains > and content sharing between all, however if that is not something > slashcode provides as a functionality is it atleast possible to get > content from subdomains listed on the main page as is done on > slashdot.org. > > Thanks in advance for your help > > Warm Regards > Imtiaz > kha...@gm... > > > > > ---------------------------------------------------------------------- > --- > 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? > cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ > _________________ > Slashcode-development mailing list > Sla...@li... > https://lists.sourceforge.net/lists/listinfo/slashcode-development |
From: Imtiaz A k. <kha...@gm...> - 2006-09-12 17:56:34
|
Hi, I was finally able to setup slashcode and get it working as well as get subdomains going. I used multiple virtual users and multiple databases for the subdomains. Now my question is : 1. *Is it possible to have one central database for all of the subdomains?* This way, when a user logs into the homepage or any of the subdomains, he will be logged into the entire site (this is what we want). It also may be easier to set up the subdomains to pull from this central database according to different parameters (for example: only display rock stories). 2. I see on slashdot.org that they have multiple stories listed on the front page and these come from different subdomains. Is that a plugin at work and if yes what should I be looking at? I would very much like to have a single sign-on for all subdomains and content sharing between all, however if that is not something slashcode provides as a functionality is it atleast possible to get content from subdomains listed on the main page as is done on slashdot.org. Thanks in advance for your help Warm Regards Imtiaz kha...@gm... |
From: Eric D. <eri...@ja...> - 2006-08-29 18:31:53
|
I was thinking more like users with an elevated access level (like approved users) would be able to participate in stories that we could attach PDFs or JPGs to. I was thinking more along the lines of using BLOBs.......... shane wrote: > On Aug 25, 2006, at 5:03 PM, Eric Dannewitz wrote: > > >> I still think a great plugin/feature would be to allow approved >> users to >> be able to submit files/pictures in replies to articles. >> > > Would what they submitted be attached to the story, or their comment? > > It would be trivial to show an image (that the user picked) with each > user's comment. Just add an entry for them in the editUser template > (a text input) and then alter the displayComment templates to include > that user.myimagelink in the html. > > Is this safe and adviseable? Lots of sites do this (ie UBB, etc) I > wouldn't on any sites I run. But that's just me. I think it depends > on the website, personally. > > Shane > |
From: Alexandre L. <ale...@ec...> - 2006-08-29 15:37:17
|
Hi, Larson, Timothy E. wrote: > It would have to be defined somewhere on the site, but that would be > done by the admins during setup, and only once. If this GeoRSS thing i= s > that big already, I imagine someone somewhere has already done some of > the work: defining the boundaries of countries, states, cities, > landmasses, etc. You'd just have to pick the ones that work for you, > and fill in the gaps. It's getting complex here since there are numerous possibilities. This=20 could be done directly using "RSS to GeoRSS Converter" from Geonames.org: http://www.geonames.org/rss-to-georss-converter.html However, I still feel a custom-made list of locations that can be=20 ordered as wished would still be more useful/convenient. As for zip code geocoding, I don't know much myself about this, but I=20 know it's pretty easy. See http://technology.slashgeo.org/article.pl?sid=3D06/01/21/054201 and http://technology.slashgeo.org/article.pl?sid=3D06/06/15/1312224 >> In what way? To search the stories? To filter them on an index view >> (as you could filter by author, or by topic?)=20 >=20 > Precisely! That was my original vision for how it would work in that > low-pri request. It would be a fourth piece of data along with topic, > section, and author. One would be able to filter the homepage on > location just as with those three. =20 Humm.. this raises an important issue. Do you want slash to manage the=20 'spatial queries' or let the user's GeoRSS reader do the job? I tend to=20 opt for the GeoRSS reader, since those will evolve/improve way faster=20 than slash does. The Slash engine could allow basic searches on archives=20 using a bounding box. Logically, a GeoRSS feed shows only geolocated stories. Slashdot has=20 only 10 RSS items in its list, this means the slashdot map of georss=20 stories will be most of the time empty. This is bad. However, I guess=20 it's possible to map on the slashsite more than only the published RSS=20 items (see Shane's work-in-progress http://slashgeo.org/maps.pl ).=20 Probably showing the last 25 geolocated stories would make sense. The=20 exact number could be a var. Alex --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: Alexandre L. <ale...@ec...> - 2006-08-29 15:09:02
|
shane wrote: > Well, the container to hold that data w/ the story (or submission) is =20 > there. The code to render that polygon/lines within the google map =20 > isn't there. It'll come with finding freetime :) Don't look too hard for freetime for this ;-) Most GeoRSS readers=20 (web-based or not) only read/allow point coordinates so far. Until=20 GeoRSS is widely used and lines/polygons are supported on both sides=20 (thus including the reader), focusing on points is the logical thing to=20 do. This is true for the GeoRSS part of the plugin. For the Mashup part of the plugin, publishing lines and polygons would=20 be nice, but if you ask me, this isn't a priority!! I don't think we=20 want a full-fledge map server, this is slash, a weblog system!=20 Lines/Polygons/Box could be disabled to keep only points and this would=20 still be great :-) Alex :-) --=20 Alexandre Leroux, M.Sc., Ing. Environnement Canada / Environment Canada Centre m=E9t=E9orologique canadien / Canadian Meteorological Centre Division de la r=E9ponse aux urgences environnementales / Environmental Emergency Response Division ale...@ec... |
From: shane <sh...@lo...> - 2006-08-29 15:06:40
|
On Aug 29, 2006, at 10:16 AM, Larson, Timothy E. wrote: > shane wrote: >> On Aug 25, 2006, at 4:59 PM, Larson, Timothy E. wrote: >>> I'd've been happy with a even a list of regions/countries to choose >>> from when submitting stories. How hard is it to reliably map any >>> given coordinate pair to a city/country/state/area? I can certainly >>> see the utility in finding local postings (i.e. "within 200 km of >>> <coord>") but more likely (for my needs) I'd want to focus on >>> "Canada" or "Manhattan" or "Middle East". It certainly would be >>> easier (for non-geography buffs) to submit something like this (i.e. >>> picking from a list, clicking a map region) with stories rather than >>> coordinate pairs. >> >> Where would one obtain such data? > > It would have to be defined somewhere on the site, but that would be > done by the admins during setup, and only once. If this GeoRSS > thing is > that big already, I imagine someone somewhere has already done some of > the work: defining the boundaries of countries, states, cities, > landmasses, etc. You'd just have to pick the ones that work for you, > and fill in the gaps. We may have a stop gap here - http://www.lottadot.com/projman.pl?op=view&id=15 I had started that zipcode plugin, well, a very long time ago. As far as I recall, it was functional last time I messed with it. If you can, take a look at it, specifically the schema and the data it contains. From a quick glance, it looks like it has lat/long information by zip/city/state. However, defining boundaries w/ landmasses et all, er yuk. > >>> So this only applies to RSS, and you won't notice anything when >>> visiting the site otherwise? >> >> No. If a story has geo-data associated with it, it'll show a map. >> Example: >> >> http://industry.slashgeo.org/article.pl?sid=06/07/27/1337233 >> >> It will also add tags into the html such as >> >> <meta name="geo.position" content="51.5;-0.1"> >> >> For more info on the tags: http://www.lottadot.com/projman.pl? >> op=viewissue&id=5 > > Very very very cool. Especially if the map view is customizable. The maps are drawn via a template. The template expects certain things passed to it (map api key, lat, long, points) But other then that, it will be very, very highly mod'able. > >>> If the story has location info, I'd want to see it in the story >>> somewhere. >> >> Where? And what? That's been the big question. > > That depends on the nature of the site. A "hard news" site would > prefix > "Dateline: New York" to the story submission, perhaps. > >>> I think it would be a huge value-add, and very useful, especially > were >>> it given the ability to use "general" location as well as "specific" >>> location. >> >> In what way? To search the stories? To filter them on an index view >> (as you could filter by author, or by topic?) > > Precisely! That was my original vision for how it would work in that > low-pri request. It would be a fourth piece of data along with topic, > section, and author. One would be able to filter the homepage on > location just as with those three. > > In fact, 699047 describes an enhancement to home page customization > that > would make use of this field. Since that request, a different > enhancement has been done, but the idea of using locale is still cool. > On slashdot, for example, sure it's interesting that some big business > 10 timezones away is switching operations to Linux, but I'm also > interested in the much less earthshaking news of an Open Software > Festival sponsored by a high school club in the next county. By > adding > support for location, big sites can still cover local news without > "spamming" the non-locals. How would this be any different from having a topic-nexus defined that would hold all stories associated with a certain area? Then all a user has to do is hit the URL for skin to obtain that content. I bring that solution up, because that doesn't entail modifying any source code, nor schema. So far, to get the functionality that's mentioned on the project homepage ( http://lottadot.com/projects/ slashmaps ) I've not had to modify all that much source code to get these things to work. Mostly we're using topic_nexus_extras to store the information, and modified templates to show it. (I did have to complete the skins editor, and the skins_params, but that's another topic). Inorder for one to be able to essentially search by story.location (let's assume that's what it's called) efficiently, at first thought I would think we'd have to modify the stories table schema, add that column, and then modify all the story code (getStoriesEssentials,etc) in Slash.pm as well as retool a bit of Slash::Search. Then add a bit to the edituser page that would let them set the 'region/place' limiting options (just like they can exclude authors, topics). At first glance, that seems like quite a bit of work. Maybe there'd be a better way to do it. Any thoughts? I'm all ears. Another question I would have, is if you're wanting to associate a story with a location, how do you let a user exclude? by proximity to that location? how do you define proximity? lat/long? within XX miles? but that's US, so you'd want to investigate using an alternative metric. Shane -- My slashcode stuff: http://slash.lottadot.com/ Slashcode faq: http://slash.lottadot.com/slash-faq How to ask a question: http://www.catb.org/~esr/faqs/smart- questions.html#before |
From: shane <sh...@lo...> - 2006-08-29 13:37:34
|
On Aug 25, 2006, at 5:24 PM, Alexandre Leroux wrote: > > Hi, > >> more likely (for my needs) I'd want to focus on "Canada" or >> "Manhattan" >> or "Middle East". It certainly would be easier (for non-geography >> buffs) to submit something like this (i.e. picking from a list, >> clicking >> a map region) with stories rather than coordinate pairs. > > You'll be happy Tim, the GeoRSS standard (it's a Open Geospatial > Consortium standard, see http://www.opengeospatial.org/) allows not > only > points, but lines and polygons. So this means, to take your > example, you > can specify Canada or Middle-East with a polygon. This is -already- in > the plugin :-) Well, the container to hold that data w/ the story (or submission) is there. The code to render that polygon/lines within the google map isn't there. It'll come with finding freetime :) > One of the improvements will be to allow adding and > selecting regularly used 'locations' from a list, instead of having to > type the whole coordinates in the story edition page. This droplist > could be provided to users submitting stories. I'd been thinking on this one quite a bit. I envisioned a drop down that onchange would fill in the geopoints data from whatever was selected on the dropdown. > > I wasn't aware there was previous feature request of story > 'regionalization'. Me neither. Shane |