Menu
▾
▴
nms-cgi-devel
|
From: Wizard <wi...@ne...> - 2003-01-22 18:02:20
|
> CGI::NMS::Config::DynaFile ? That'll do. > Sorry, you've lost me there. What problem ? This: $obj = CGI::NMS::Config->new( "LMachine/NMS/Config" ); Is that a file relative to CWD or is it a registry key? Meaning which module do I use? I could try each in turn, but that could be dangerous. Everything that I can think of would negate the whole idea of using a wrapper. It doesn't make sense to have anything user-specified in the script to specify where to find the EXTERNAL configuration. That's just dumb. Any suggestions? Let me know, Grant M. |
|
From: Nick C. <ni...@cl...> - 2003-01-22 23:17:06
|
On Wed, Jan 22, 2003 at 12:57:27PM -0500, Wizard wrote:
> > Sorry, you've lost me there. What problem ?
>
> This:
>
> $obj = CGI::NMS::Config->new( "LMachine/NMS/Config" );
No, there is no code in CGI::NMS::Config, it is a pure virtual class or
an interface class or whatever they're called this week. Its primary
function is to document the interface that the CGI::NMS::Config::*
classes must provide.
To create a config object, you need to know what type you're creating:
$obj = CGI::NMS::Config::Win32Reg->new( "LMachine/NMS/Config" );
$obj = CGI::NMS::Config::DynaFile->new( "LMachine/NMS/Config" );
If we want a script to be able to choose what config module to use based
on the string, we'll need to add a scheme switch, maybe something like
this:
{
package CGI::NMS::Config::Switched;
sub new {
my ($pkg, $arg) = @_;
if ($arg =~ s/^Win32Reg://) {
require CGI::NMS::Config::Win32Reg;
return CGI::NMS::Config::Win32Reg->new($arg);
}
elsif ($arg =~ s/^DynaFile://) {
require CGI::NMS::Config::DynaFile;
return CGI::NMS::Config::DynaFile->new($arg);
}
else {
die "invalid config switch arg [$arg]";
}
}
}
... so now we can do things like:
$obj = CGI::NMS::Config::ByScheme->new( "Win32Reg:LMachine/NMS/Config" );
--
Nick
|
|
From: Wizard <wi...@ne...> - 2003-01-23 17:42:36
|
Ok, I think I have a general idea of where I am going. Here's what I have:
Present Issues:
File Format - As stated in an earlier message, I'm going with NML, which
for the time being looks suspiciously like XML. I will do my best to hide
any format-dependent functionality so that it can be replaced if desired.
Configuration Parameters - I have a general understanding of what is
wanted, but I really don't know how to implement it, so I'm going to make my
module CGI::NMS::Config.pm. It will implement the ->get( $keyname ) method,
and perhaps some other methods (I'll post if I need anything else). I will
tag all of my calls in the code so that they can be easily replaced should
someone decide to push my module to a subclass role. This is really
self-serving, but it shouldn't be too painful to replace.
Features (this version):
o WWWBOARD->NMSBOARD conversion utility
o Views:
List
Thread
Message
Search
o External Configuration(s)
o Ability to have multiple lists using one installation
Done by calling (...view.pl?cfg=./nms.cfg)
o IP/User/domain deny/allow (and maybe allow/deny)
o Post Moderating by User or All
o Email Alerts or Subscription Alerts
o External Templating (both template file & Cfg-based)
That's it I think for now. If I've forgotten anything, let me know.
Grant M.
|
|
From: Nick C. <ni...@cl...> - 2003-01-24 23:03:11
|
On Thu, Jan 23, 2003 at 12:37:34PM -0500, Wizard wrote: > Ok, I think I have a general idea of where I am going. Here's what I have: > > Present Issues: > File Format - As stated in an earlier message, I'm going with NML, which > for the time being looks suspiciously like XML. I will do my best to hide > any format-dependent functionality so that it can be replaced if desired. > Configuration Parameters - I have a general understanding of what is > wanted, but I really don't know how to implement it, so I'm going to make my > module CGI::NMS::Config.pm. It will implement the ->get( $keyname ) method, > and perhaps some other methods (I'll post if I need anything else). I will > tag all of my calls in the code so that they can be easily replaced should > someone decide to push my module to a subclass role. This is really > self-serving, but it shouldn't be too painful to replace. > > Features (this version): > o WWWBOARD->NMSBOARD conversion utility > o Views: > List > Thread > Message > Search > o External Configuration(s) > o Ability to have multiple lists using one installation > Done by calling (...view.pl?cfg=./nms.cfg) > o IP/User/domain deny/allow (and maybe allow/deny) > o Post Moderating by User or All > o Email Alerts or Subscription Alerts > o External Templating (both template file & Cfg-based) > That looks good. -- Nick |
|
From: Paul R. <pa...@ro...> - 2003-01-21 17:16:43
|
> > 2. We will rarely, if ever, need to delete a message from > > the middle > > of the file > > Is this correct? If I'm getting what you're saying, we will need to delete > messages from the beginning middle and end of a file if they contain more > than one message. > But in the normal (quota management) case, you'd delete oldest-first -- i.e. from the beginning. If you batch this up a bit, it's not too bad. > Also, there's the issue of advertising posts and just plain inappropriate or > offensive posts. > True, but hopefully not *that* frequent. > > Building the index can be quite fast if we store content-length > > (probably as > > a line count) as above. > > I'm guessing that what you are proposing is fixed-length records. This could > be substantially faster on most systems, but is it easily portable? > Not at all. Either store the length in bytes, or the lenght in (variable) lines. > This kinda brings up another concern/thought. If we use either this format > or Simon's, don't I lose the benefit of a data-defined hierarchy? I > understand that they both try to solve this using indexing, but I still have > to deal with multi-level indents/nesting. In other words, with either of > these formats, don't I have to presort all of the data, assigning index > levels to each entry based upon the index level of the parent. With my > format (XML or not), the hierarchy is predetermined by the nesting of each > element, which means that they are already presorted. This means I only have > to increment/decrement the indent level based upon the data tags > encountered. I may be wrong, but it just sounds like a much simpler > implementation to me (and where I'm doing it, that sounds good :-). KISS > principle? > You're assuming (a) that we'll precompute the indent level, which I don't assume is a great idea. Also assuming that the indent level will continue to be correct when earlier (potentially parent) messages are deleted. Pre-computing, storing, re-computing what is essentially a presentation detail seems to be anti-KISS to me. > > Message display can still be quite efficient if we further extend > > the index > > to include the offset (by line, byte, whatever) of the message in > > the larger > > file. We seek (or quickly skip lines), we grab exactly content-length > > lines, and off we go. > > I do like the idea of this, but I would like to know it will work > everywhere. > Everywhere that the file seek functions work. Or everywhere you can read a line at time, which is... everywhere. You're still reading them, but not parsing. -paul |
|
From: Nick C. <ni...@cl...> - 2003-01-21 18:09:27
|
On Tue, Jan 21, 2003 at 12:16:44PM -0500, Paul Roub wrote: > > > > Is this correct? If I'm getting what you're saying, we will need to delete > > messages from the beginning middle and end of a file if they contain more > > than one message. > > But in the normal (quota management) case, you'd delete oldest-first -- i.e. > from the beginning. If you batch this up a bit, it's not too bad. I don't like one big file including message bodies. The only simple way to delete a post (without risk of loosing the whole lot if the script is killed or the server reboots half way through) is to write out a new copy of the file and then rename it over the old version. That limits the total size you can have to *half* your quota, and makes it impossible to delete messages via the admin script once the account is over half quota. The users won't like that. Also, some system backup utils will dump only files modified since the last backup, and these will work much better with each message body in a separate file. -- Nick |
|
From: Nicholas C. <ni...@un...> - 2003-01-21 22:08:00
|
On Tue, Jan 21, 2003 at 12:16:44PM -0500, Paul Roub wrote: > Everywhere that the file seek functions work. Or everywhere you can read a > line at time, which is... everywhere. You're still reading them, but not > parsing. If the file seek functions aren't working, I suspect they'll be the least of our problems. Are there any file systems that can't seek? (And anywhere you can read a line at a time you can read a block of bytes, so you can still fake a seek.) seeking is O(1). Reading line at a time is O(N) If a file gets over a disk block in size, then seeking direct to the right point saves ever needing to pull that block from disk. As others have said (oops, not in an easy position to quote messages), different approaches have different advantages and disadvantages every message in its own a file is good for backups, and good for middle deletions. However it's slow to open every file in turn, and if a server quotas by disk blocks used, there will be a lot of wasted space. Every message in the same file avoids lots of opens, seeks are (moderately) fast, and there's little wasteage from small files. However, middle deletes are slow, potentially expensive in terms of disk quota needed, and backups will be larger. Do we get the best of both worlds with many messages per file? Is 1 file per thread practical? Nicholas Clark |
|
From: Wizard <wi...@ne...> - 2003-01-21 23:18:48
|
What if for now I do something like this (pseudo code):
$data_file = "nms.dat";
&print_header( $cgi_function_parameter );
$q = NMS::Data::NML->new( $data_file );
if( $cgi_function_parameter eq 'message' ){
$q->print_message( $cgi_msg_id ); # this is separate file?
} elsif ( $cgi_function_parameter eq 'thread' ) {
$q->print_thread( $cgi_thread_id );
} else {
while ( $q->some_left() ){
$q->print_thread();
# and perhaps
$q->next();
}
}
...
I'll be using the newly-defined 'NML hierarchical file format' ("Liar! It is
not XML! It only looks like it when you squint!") for storage. Because the
object is now data-hiding, it doesn't really matter what it is. We can
convert it to whatever the consensus is anytime before we ship. Does that
make sense, or should I just wait?
Let me know,
Grant M.
|
|
From: Nicholas C. <ni...@cc...> - 2003-01-21 13:57:05
|
On Tue, Jan 21, 2003 at 01:44:18PM +0000, Simon Wilcox wrote: > On Tue, 2003-01-21 at 12:08, Wizard wrote: > > Here's what I have in mind for WWWBoard2, along the lines of TFMail: > > XML is a bitch to parse without using modules that we don't want to have > people install. It's also slooooow. I'd suggest a format that has one <AOL/> :-) > message per file and an index of related messages, perhaps something > like this: > > id: 14 > respondsto:12 > subject:NMS scripts are great! > user:The Professor > email:fr...@fs... > date:20/01/03 > moderate:0 > body: > Some body text on multiple > lines up to the end of > the file > > Then the index looks like: > > 12+: 14 17 18 > > and contains a list of messages and the responses to it. The + indicates > that the message is the head of a thread. Might this create lots of small files very quickly? If so, this would be a pain. (Although it reduces the problem of locking files - you only need to lock whichever file holds the next message number to use) If so, either create subdirectories on demand and put some maximum number of files per subdirectory (eg 100, 256, 1000) Alternatively store more than one message per file, and extend the index format to store message number, file start offset and length for each message. (And binmode the file, so that seeks work nicely on Windows servers) Just a thought, and possibly going down completely the wrong track. Nicholas Clark |
|
From: Simon W. <es...@ou...> - 2003-01-21 14:04:40
|
On Tue, 2003-01-21 at 13:56, Nicholas Clark wrote: > On Tue, Jan 21, 2003 at 01:44:18PM +0000, Simon Wilcox wrote: > > and contains a list of messages and the responses to it. The + indicates > > that the message is the head of a thread. > > Might this create lots of small files very quickly? > If so, this would be a pain. (Although it reduces the problem of locking > files - you only need to lock whichever file holds the next message > number to use) Yes, it might. I hadn't actually thought of the locking issue but that's another plus point in it's favour. > If so, either create subdirectories on demand and put some maximum number of > files per subdirectory (eg 100, 256, 1000) Good approach. Perhaps a message id in the form of 001001 which can be broken out easily into directory and file. What's the limit where linux swaps from a tree search to a linear search algorithm ? we should stick below that. > Alternatively store more than one message per file, and extend the index > format to store message number, file start offset and length for each > message. (And binmode the file, so that seeks work nicely on Windows > servers) Could work but maybe more complicated than we need. > Just a thought, and possibly going down completely the wrong track. No, I think it is a good point. S. |
|
From: Nick C. <ni...@cl...> - 2003-01-21 14:41:54
|
On Tue, Jan 21, 2003 at 07:08:20AM -0500, Wizard wrote:
> Here's what I have in mind for WWWBoard2, along the lines of TFMail:
[SNIP]
How about having a 'send mail to admin when there's a post'
feature (which people have asked for in wwwboard) and making the
threading optional ?
Will it be fixed at one message per page, or will it be possible
for this thing to render a whole thread (or several threads) on
a single big HTML page ?
If those are features that you're interested in putting in then
it would be possible to configure this thing as a guestbook
instead of using it as a wwwboard, which would be a bonus. We
get two advanced scripts for the price of one.
> 1.> WWWBoard2 stores XML for the main page and all messages.
> 2.> WWWBoard2 transforms this when requested using a header, footer and data
> template, like this (pseudo-code):
> <List-View>
> a.> Request for virtual wwwboard.html (which is now wwwview.pl)
> b.> The wwwheader.html file is read and printed.
> c.> The XML is parsed into the wwwdata.html and printed
> d.> The wwwfooter.html file is read and printed.
>
> Note: Yes, I realize that a single template would be simpler for the user,
> but it would require much more complex parsing, which would be much slower
> (and more server load).
If you're going to be using a template then you don't need header and
footer files, since the users can just put the header HTML at the top
of the template and the footer HTML at the bottom.
I don't think that would be any slower than reading in the two extra
files.
> Perhaps I could include a utility to pre-parse a
> full HTML template? I am not using XSLT for the simple reason that it would
> be much more complex, parsing-wise, and as we're not using CPAN modules, I'm
> not going to reinvent the wheel. This may happen sometime later when we've
> converted the masses.
>
> <Message-View>
> a.> A particular message is selected (wwwview.pl?message=419)
> b.> If exist wwwmheader.html else wwwheader.html is parsed w/title &
> printed.
> c.> The XML message is parsed into the wwwmessage.html and printed
> d.> If exist wwwmfooter.html else wwwfooter.html is parsed w/thread &
> printed.
The existing wwwboard shows the thread as a message hierarchy at the top
of the message view page, will wwwboard2 be able to do that ?
> I suspect that the XML for the main page will look like this:
>
> <MessID name="14">
> <subject>NMS scripts are great!</subject>
> <user>The Professor</user>
> <email>fr...@fs...</email>
> <date>20/01/03</date>
> <moderate>0</moderate>
> <MessID name="17">
> <subject>Re: NMS scripts are great!</subject>
> <user>The Wizard</user>
> <email>de...@nu...</email>
> <date>22/01/03</date>
> <moderate>0</moderate>
> </MessID>
> </MessID>
>
> Note the nesting. This would require recursive calls to the data templating
> mechanism which I just realized and need to think about (suggestions
> welcome).
If you're rendering the index page then the user could define a template
for the page as a whole:
<html>
<head><title>wwwboard</title></head>
<body>
<h1>Thread Index</h1>
<hr />
<ul>
[% messages %]
</ul>
</body>
</html>
... and they would define a separate template that tells the script how
to render the index line for a particular message:
<li>
<b>[% user %]</b> ([% email %]) ([% date %])
[% IF there_are_followups %]
<ul>
[% messages %]
</ul>
[% END %]
</li>
... and the template code would apply the second template recursively
when it hit the [% messages %] directive in the main template, and
you'd get the tree structure appearing.
--
Nick
|
|
From: Wizard <wi...@ne...> - 2003-01-21 15:05:06
|
> How about having a 'send mail to admin when there's a post' > feature (which people have asked for in wwwboard) and making the > threading optional ? Actually, I was thinking it might be nice if we could have a subscription sendmail, so that you could sign-up for specific message responses. I actually already have something like this for NeonDB (http://www.neonedge.com/neondb.html - which I still have to finish). Let me know what you think, but first things first. > Will it be fixed at one message per page, or will it be possible > for this thing to render a whole thread (or several threads) on > a single big HTML page ? Do you mean message text also, or just per thread displays? Regardless, if were using a script to parse and display, I guess we can pretty much do what we want. > > If those are features that you're interested in putting in then > it would be possible to configure this thing as a guestbook > instead of using it as a wwwboard, which would be a bonus. We > get two advanced scripts for the price of one. > > > 1.> WWWBoard2 stores XML for the main page and all messages. > > 2.> WWWBoard2 transforms this when requested using a header, > footer and data > > template, like this (pseudo-code): > > <List-View> > > a.> Request for virtual wwwboard.html (which is now wwwview.pl) > > b.> The wwwheader.html file is read and printed. > > c.> The XML is parsed into the wwwdata.html and printed > > d.> The wwwfooter.html file is read and printed. > > > > Note: Yes, I realize that a single template would be simpler > for the user, > > but it would require much more complex parsing, which would be > much slower > > (and more server load). > > If you're going to be using a template then you don't need header and > footer files, since the users can just put the header HTML at the top > of the template and the footer HTML at the bottom. > > I don't think that would be any slower than reading in the two extra > files. Maybe, but I don't have to parse the files at all if their just static. With a Header/Footer combo file, I have to parse to where the data templates should start and reparse or retain until all of the data has been output in order to put the footer. I'll DProf both and we'll see. > The existing wwwboard shows the thread as a message hierarchy at the top > of the message view page, will wwwboard2 be able to do that ? This is the idea. The XML hierarchy duplicates the message hierarchy. > If you're rendering the index page then the user could define a template > for the page as a whole: <SNIP> If I'm getting what you wrote, that's the whole idea. Grant M. |
|
From: Olivier D. <dr...@sh...> - 2003-01-21 18:53:25
|
Greetings,
While we're at it throwing ideas, how would the speed of XML or
otherwise formatted single-file parsing compare to something like
DB_File? As far as I know, DB_File is part of Perl (at least on my
system) and it would save a lot of parsing work out.
On Tue, Jan 21, 2003 at 07:08:20AM -0500, Wizard wrote:
> <MessID name="14">
> <subject>NMS scripts are great!</subject>
> <user>The Professor</user>
> <email>fr...@fs...</email>
> <date>20/01/03</date>
> <moderate>0</moderate>
> <MessID name="17">
> <subject>Re: NMS scripts are great!</subject>
> <user>The Wizard</user>
> <email>de...@nu...</email>
> <date>22/01/03</date>
> <moderate>0</moderate>
> </MessID>
> </MessID>
Let me take a stab at this one too with a filesystem based hierarchy of
DB files:
/msgindex.db
/000001.db
/000001/msindex.db # replies of /000001.db
/000001/000001.db
/000001/000002.db
/000001/000003.db
/000001/000003/msgindex.db # replies of /000001/000003.db
/000001/000003/000001.db
/000001/000003/000002.db
/000001/000003/000003.db
/000001/000004.db
/000002.db
/000003.db
/000004.db
/000005.db
...
msgindex contain a list of all the posts in a directory. We can quickly
check the directory tree for threads of messages. The xxxxxx.db files
contain the post data.
Building an index (link) page seems simple enough. Modifying post would
probably be slow (I think it does in place) but we usually don't modify
posts. Deleting messages (unlink and delete msgindex reference), entire
threads (rm -rf the directory) even is joke.
The only issue I can see is DB_File has only been part of Perl since
v??? and that the space requirements might be an unecessary strain on
quota'd systems/users. On this, anyone knows how file size for DB_File
compare to let say something equivalent in XML? We could also use CSV
or some other database schema.
What do you think?
-Olivier
--
__-/| ? ? |\-__
__--/ / \ (^^) / \ \--__
_-/ / / \ / ( ) / \ \ \-_
/ / / / ~( ^^ ~ \ \ \ \
/ Oli Dragon dr...@sh... \
/ Sfwr Eng III ( McMaster University \
/ / / __--_ ( ) __--__ \ \ \
| / / _/ \_ \_ \_ \ \ |
\/ / _/ \_ \_ \_ \ \/
\_/ / -\_\ \ \_/
\/ -) \/
*~
___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
~~~--<******************************************************>--~~~
|
|
From: Wizard <wi...@ne...> - 2003-01-21 19:22:06
|
> While we're at it throwing ideas, how would the speed of XML or > otherwise formatted single-file parsing compare to something like > DB_File? As far as I know, DB_File is part of Perl (at least on my > system) and it would save a lot of parsing work out. It requires Berkeley DB which I'm not sure is available to all windows boxen. If you meant DBM files (which I believe is a different animal), that's part of Perl 5.0 and we could use that. I don't know about the speed thing, but I could test it. > We could also use CSV or some other database schema. If we were going to go with some specific stand-alone Database mechanism, I think I'd chose to use DBD::XBase for the SQL support (allowing for conversion to Enterprise DBs), and include the CPAN modules. It works, is pure perl, and supports a reasonable subset of SQL92(?). I've used it with NeonDB. I am assuming however that all perl installs would include DBI by default. Grant M. |
|
From: Olivier D. <dr...@sh...> - 2003-01-21 22:04:05
|
On Tue, Jan 21, 2003 at 02:17:14PM -0500, Wizard wrote:
> > While we're at it throwing ideas, how would the speed of XML or
> > otherwise formatted single-file parsing compare to something like
> > DB_File? As far as I know, DB_File is part of Perl (at least on my
> > system) and it would save a lot of parsing work out.
>
> It requires Berkeley DB which I'm not sure is available to all windows
> boxen. If you meant DBM files (which I believe is a different animal),
> that's part of Perl 5.0 and we could use that. I don't know about the speed
> thing, but I could test it.
I thought DB_File was BerkleyDB 1.x... It requires external libraries?
It's not the impression I got from the documentation :o|
> > We could also use CSV or some other database schema.
>
> If we were going to go with some specific stand-alone Database mechanism, I
> think I'd chose to use DBD::XBase for the SQL support (allowing for
> conversion to Enterprise DBs), and include the CPAN modules. It works, is
> pure perl, and supports a reasonable subset of SQL92(?). I've used it with
> NeonDB. I am assuming however that all perl installs would include DBI by
> default.
The reason for my suggestion of DB_File is because the Perl code is
extremely trivial and compact. A single `tie' or `dbopen' and you have a
hash tied to the database data. From there it's all $hash{your_field}
which is a lot simpler than SQL queries...
I think requiring DBI might be a bit too much for "easy to use"
scripts... I mean there are plenty of online board software out there.
That use fancy DBMSs like MySQL, PostgreSQL or Oracle. Security might be
a our main concern and is rarely addressed but I think we also need to
make it as easy as edit a config file and upload a few files (which I
think qualifies for all of our current scripts). This is key also to
keep the support request numbers down which seems to be a bit of an
issue at the moment.
On the other hand, using DBI opens the way to a wide variety of
databases which could ultimately be left to the user to choose in the
configuration file.
Oh Joy :o)
-Olivier
--
__-/| ? ? |\-__
__--/ / \ (^^) / \ \--__
_-/ / / \ / ( ) / \ \ \-_
/ / / / ~( ^^ ~ \ \ \ \
/ Oli Dragon dr...@sh... \
/ Sfwr Eng III ( McMaster University \
/ / / __--_ ( ) __--__ \ \ \
| / / _/ \_ \_ \_ \ \ |
\/ / _/ \_ \_ \_ \ \/
\_/ / -\_\ \ \_/
\/ -) \/
*~
___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
~~~--<******************************************************>--~~~
|
|
From: Nicholas C. <ni...@un...> - 2003-01-21 22:33:28
|
On Tue, Jan 21, 2003 at 05:09:53PM -0500, Olivier Dragon wrote: > On Tue, Jan 21, 2003 at 02:17:14PM -0500, Wizard wrote: > > > While we're at it throwing ideas, how would the speed of XML or > > > otherwise formatted single-file parsing compare to something like > > > DB_File? As far as I know, DB_File is part of Perl (at least on my > > > system) and it would save a lot of parsing work out. > > > > It requires Berkeley DB which I'm not sure is available to all windows > > boxen. If you meant DBM files (which I believe is a different animal), > > that's part of Perl 5.0 and we could use that. I don't know about the speed > > thing, but I could test it. > > I thought DB_File was BerkleyDB 1.x... It requires external libraries? > It's not the impression I got from the documentation :o| Perl ships with complete source for SDBM_File, and that should compile anywhere. The module that might be most useful is AnyDBM_File, which uses whichever out of NDBM_File, DB_File, GDBM_File, SDBM_File, ODBM_File are working. The two problems that immediately spring to mind with *DBM files are how to lock them to protect against multiple writes (auxiliary file?), and whether it's important that we don't know what file name they actually create for us. (In fact, sometimes they create two files with different extensions) It ain't perl if AnyDBM_File doesn't work (perl5-porters, or at least Andy Dougherty will back me up on that) - in that no-one sane will have configured all 5 out, and their perl will have failed a regression test if they did. What proportion of ISPs aren't sane? How do we work round them - back to flat files? > On the other hand, using DBI opens the way to a wide variety of > databases which could ultimately be left to the user to choose in the > configuration file. In an ideal world it would be possible to create an interface that makes it simple for the end user to swap from files on disk to DB files to DBI. [Beware of low flying pigs :-(] Nicholas Clark |
|
From: Simon W. <es...@ou...> - 2003-01-21 22:41:58
|
On Tue, 21 Jan 2003, Nicholas Clark wrote: > Perl ships with complete source for SDBM_File, and that should compile > anywhere. The module that might be most useful is AnyDBM_File, which uses > whichever out of NDBM_File, DB_File, GDBM_File, SDBM_File, ODBM_File > are working. The two problems that immediately spring to mind with *DBM > files are how to lock them to protect against multiple writes (auxiliary > file?), and whether it's important that we don't know what file name they > actually create for us. (In fact, sometimes they create two files with > different extensions) A good reason to avoid db_files is the locking problems that come with them. > In an ideal world it would be possible to create an interface that makes it > simple for the end user to swap from files on disk to DB files to DBI. The interface is fairly simple: ->get( id ); ->save( id, \%data); # or something like that ->delete( id ); ->get_thread_from( id ); # if you're feeling generous. ->new( \%data ); The implementation knows where to go to get things and is reasonably clever enough that if multiple messages are stored in a single flat file per thread then it will slurp them all and cache them just in case. It takes care of saving them and updating any necessary index files. Simon. -- "2 to the power of 100,000 to 1 and falling...." |
|
From: Simon W. <es...@ou...> - 2003-01-21 22:44:26
|
On Tue, 21 Jan 2003, Olivier Dragon wrote: > I think requiring DBI might be a bit too much for "easy to use" > scripts... I mean there are plenty of online board software out there. > That use fancy DBMSs like MySQL, PostgreSQL or Oracle. Security might be > a our main concern and is rarely addressed but I think we also need to > make it as easy as edit a config file and upload a few files (which I > think qualifies for all of our current scripts). This is key also to > keep the support request numbers down which seems to be a bit of an > issue at the moment. hear hear ( or is it here here ?) =20 > On the other hand, using DBI opens the way to a wide variety of > databases which could ultimately be left to the user to choose in the > configuration file. Beware the demon that is feature creep ! Our mission/goal/whatever is to provide software that can be installed=20 with the minimum of effort. As soon as you start down the DBI route you=20 end up with all sorts of headaches that are probably better solved by=20 other projects. my =A30.02 Simon. --=20 "Is there any tea on this spaceship ?" =20 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X