On Fri, 7 May 2010 23:58:20 +0800 Michael Alger <ds...@mm.quex.org> wrote:
> On Fri, May 07, 2010 at 05:14:07PM +0200, Stevan Bajić wrote: > > > > Look. I am not the one against everything in a db. For me DB is > > fine. The only thing that is bothering me is that so far no one > > has done serious work on DSPAM in the last months beside me. Every > > one keeps talking, talking, promissing, talking and at the end > > everything is hitting me. > > I think it should perhaps be the other way - everything the webUI > does ought to be abstracted out through dspam_admin and similar > utilities. > Yes. Or even better would be to have a server protocol that the WebUI could use and the DSPAM server does all the magic. Something ultra simple to code and with a bunch of commands. Nothing special. Would however rule out all the users that use right now just DSPAM but not the daemon. > The current UI is a bit of a haphazard mix of > dspam_admin calls and direct access to the filesystem. > Yep. > > Remember the PHP WebUI talk? Doing a WebUI should be a no issue > > but even that small development is never happening. At the end > > every one is waiting for the other to do something. > > I think that's exactly right. I wouldn't mind spending some time on > the UI (I've already hacked mine a fair bit) but I did see this > rumour of a PHP UI way way back when Jon was still running the > project and figured it'd be pointless to spend any time on the > current UI. > That was my thinking too. But it might surprise you: So far no PHP GUI emerged that is capable to replace the current one. The current WebUI is the only one that is working and has the most functionallity. > Ultimately, I think the issue is that it's quite a mature product, > so any big changes are going to cause headaches for a lot of the > existing users of it. Therefore, they kind of need someone to ram > them through and say _this_ is how it's going to be done. > I think it is possible to say _this_ is how it is going to be. But we must be honest: Even if we would make a radical change, we must offer a way to migrate data/settings/whatever from old to new. And to be more honest: Currently there is nothing in the pipeline that would force us to break the old world. Everything suggested so far can coexist with the current functionallity. > Consensus paralysis, it could be called. Anyone who is willing to > contribute is waiting for everyone else to agree to everything > before doing anything. > I don't think this is the problem. If some one is really, really, really interessted in one issue then he/she is anyway going to do that. Look at Ken. He is going to do things with binary protocol in PostgreSQL and regardless of what the community is doing, he is going to invest time in that topic. > > On Fri, 7 May 2010 16:55:12 +0200 > > "imposit.com - Webmaster" <webmas...@imposit.com> wrote: > > > > > > PS do you think google saves their images on a filesystem or in > > > a database .... hmm guess :-) > > > > > They save it for sure on the filesystem. Now you can go on and > > tell me that it is saved in a database but that database is for > > sure saved on a filesystem. :) :) :) :) > > Didn't Google spend a lot of time and resources developing their own > distributed, fault-tolerant filesystem for storing their data? I > think Microsoft are the only ones who think stuffing arbitrary > binary data in an SQL database is a good idea. At least, I hope > that's the case. :) > > Maybe the quarantine should have its own backend abstraction layer > with multiple drivers? Maybe preferences should, too: so you have a > driver for the token data; a driver for the user preferences; and a > driver for the quarantine storage. Possibly also a driver for > logging - I'm sure some people would like to have their logs in > their SQL database, too. > > Probably it's a little bit excessive to compartmentalise it that > much, but it would make it pretty flexible to deploy. Plus each of > these "drivers" would be quite small since it'd target such a > specialised area. Gut reaction - horrorfied or merely terrified? > > ------------------------------------------------------------------------------ > > _______________________________________________ > Dspam-user mailing list > Dspam-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspam-user ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
