Re: Some Newbie Questions :-)
On Sunday, April 21, 2002, at 12:25 , Jamie wrote:
[..]
> 1) I've installed a couple of modules but with some of the i get
> errors where the module TEST::More couldn't be found, and i can't find
> it either.
the CPAN can be your friend -
http://search.cpan.org/search?mode=module&query=TEST%3A%3AMore
either your version of CGI.pm is 'old' and did not have this,
hence it is time to go to the CPAN and down load the modules.
{ that you are bench marking means that you are a cut above most! }
> 2) Should i use text files for my data or dive straight into something
> like MySQL? I'll propably need the SQL stuff later on, but is there
> any general rule as regards to size/ number of lines/records?
never build a database larger than the Disk Array can mirror,
with appropriate hot swappable redundent drives. 8-)
{ always remember to organize your transitioning of mirrored
devices appropriately so that your OLTP transaction database
can be re-indexed as a decision basis database - for data mining,
so as not to degrade the performance of your OLTP but provide
a fast and reasonable turn around for data mining
Or is that a bit over the top on the DB thing }
> 3) I need to generate some graphics on the fly. If i use static images
> i need to generate around 8000 files, but if i build them on the fly i
> only need around 150. I haven't seen much in regards of graphics with
> Perl, but is it feasible. (I'm downloading the Imagemagic module AWS
> :-))
which do you have more of: Disk or Processor. You could always
use say a beowoulf cluster to front end for you... 8-)
> 4) I'm looking at using cookies and authenticated logins, are there
> any good (Well OK Easy :-)) demos around.
Two differentiable problems -
plan a) your apache server mandates authentication to access the
cgi/perl_mod/tomcat stuff - hence you should not worry about it
{ unless you are making the 'browser side' player as well }
b) your apache server is not doing this for you and you need to
get up close and personal with perldoc MD5 - et al about
how to do things like SSLv2 connections - so that you can
protect the passwd in an encrypted form - as well as all of
the basic backend DBfoo that goes with username/passwd
associations
May I offer the Way Ugly, and do not try this at home - really
BAD way to make an 'all singing, all dancing' CGI/CLI piece
of code - where I of course had to 'login' to the server because
of plan a - rather than having done plan b - so I could leave
the core heavy lifting to the apache folks and the radius server.
http://www.wetware.com/drieux/src/unix/perl/UglyCode.txt
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some Newbie Questions :-)
(Sorry for the duplicate, Jamie, forgot to forward to the list!) --- Jamie <[EMAIL PROTECTED]> wrote: > ... > 2) Should i use text files for my data or dive > straight into something > like MySQL? I'll propably need the SQL stuff later > on, but is there > any general rule as regards to size/ number of > lines/records? > ... I've just gone through a similar decision process. It depends entirely on your situation. Some questions you need to consider are: 1) What tools does my platform support? 2) How much data do I have now, and how fast will it grow? 3) How many users do I envision, both concurrent (for record locking, etc.) and total (when security gets more important)? I would definately recommend some kind of SQL database solution for most commercial, and certainly enterprise-wide, applications. I've heard good things about mySQL, but not used it. At the high end, Oracle is one of the most solid there is. I can't quote any exact quantitative recommendations, but I personally wouldn't consider text files for anything bigger than a dozen files of maybe a few hundred records in each. For one thing, in any system of any size, ease and efficiency of record selection and sorting becomes very important, and SQL makes these things very easy. There are SQL drivers for text files, but I would still be concerned with how efficient they could be for large amounts of data. At some point, you've got to have indexes. On the other extreme, there are cases where a SQL database may be overkill. One of my personal projects is a very basic content management system for non-profits and small businesses, tailored to outfits with modest sites virtual-hosted by third-party ISPs and with up to 1/2 dozen content managers, maybe volunteers. I needed to find a storage mechanism that would be easily supported by most ISPs. Some IPSs support mySQL, but not all, and I wanted to be as compatible as possible. (I selected Perl as a language due to its almost universal support by ISPs.) I seriously considered XML storage, but decided that my own learning curve in using it would be too steep for the timetable I wanted to meet, and Perl-based XML tools seem to be in limited supply. So I settled on text CSV files. For my needs, this seemed to make sense. The AnyData::CSV (see CPAN) module supports record selection from CSV's, and I implemented a multi-level sort just using Perl's sort function. (I think it also has a DBI interface option, which I have not investigated.) So those are some considerations for you. In the end, it depends on your situation and it's a judgement call. - John __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
