Vacation ended, made up my mind, here is what I want to do
florin at bnv-bamberg.de
Thu Jun 8 10:52:32 PDT 2000
> Now that's been said here are some things I'm currently working on.
> I've attempted to install the sourceforge.net software (actually just a
> bunch of html pages enriched with php scripts that access mysql
> databases) locally but without avail. Something's wrong and I'm having a
> hard time figuring out where the problem exactly is. My original plan
> was to incorporate some of sourceforge.net's features on the
> linuxfromscratch.org site such as the bug tracking feature, news
> bulletins and more. Well that isn't working out but it gave me a better
> idea: why not doing it from scratch. Much more fun and I'd learn more
> from it anyways. sourceforge.net's modules are hard to separate from the
> rest so it'll be probably quicker to just start from scratch and look at
> their php scripts how they do certain things.
> This means I'm brushing up my SQL and started to learn PHP scripting.
> It's not all that hard. I've already created my first test page that
> connects to the mysql database daemon, opens a database, sends a query
> and puts the output on the website.
> My next 'project' will be creating a nice page for the LFS-polls.
> Instead of posting it to this list every so often you can go to the
> website and do it there. Enter your starting distro, glibc version, gcc
> version, kernel version, book version and whether you succeeded or not.
> Results will be immediately available which is easier than maintaining a
> static list here on this mailinglist.
> Such a poll php script is rather easy to create. I just have to code it.
> Coding the information retrieval is rather easy. Only takes a few
> minutes to type in the lines and a few more minutes to apply some pretty
> formatting. The thing I have to teach myself now is to create a form
> which will be sent to a database. It's not that hard to do, I just have
> to lookup the SQL commands (like I said, I'm still brushing up my SQL
> knowledge. It has been a few years since I last did any SQL) to do it.
> I'm beginning to like this PHP and SQL stuff. I see the posibilities to
> make website updates so much easier. The entire site contents can be
> dynamic and can be updated by issueing a few SQL queries. The only thing
> that needs to be done before the site can be transformed into this is
> Paul setting up mysql and the apache php module.
Do you feel like looking for an adventure? Check out
The oldes line of code is about 1 week (except for the CGI stuff, which I
"stole" from another project), and it's alltogether not larger than 300
lines (again, except from the CGI stuff), written in C++. And yet it'a a
simple CGI file browser.
But let me tell you the whole story (hope I don't get off-topic [again]):
I'm currently busy with two things, mainly (there are actually four):
o setting up a freind's simple internet shop
o setting up a library management system for my school
o (maybe setting up a commerce data base for my dad's store)
I was looking for some e-commerce applications, and I even found some. But
I got into troubles installing them, so I done it from scratch.
My idea was to use a fs data base (that is to store the information in
regular files). I've done some benchmarking with reiserfs. Those consisted
in creating 50,000 directories, in each subdirectory a file called 'test'
with 3k of data. I read from 1000 random files a random amount of bytes,
between 1 and 2000. The result was really impressing. The first read
took about 10 seconds, which is fairly long, the second hardly went over 4
secs and the third was about 50 ms (!!). The following reads were all at a
magnitude of ms. Increasing the number of files over a certain range
(10000 in my case) led to minimal times of 4 secs, which is, I suppose,
due to lack of memory. Although only about 10MB were read (1k per file),
the kernel seems to alloc a full block (4k) per file. However, what I#m
trying to say is that such an fs is really fast in reading, althoug a
little bit memory-consuming for small files. But if really need _a_lot_ of
files to make it slow (I have 48 MB of RAM and I was able to read 6000
files without problems).
Searching would be done via a full-text searching engine (mifluz -- I
don't recall the URL, but freshmeat might help). I didn't test it yet, I
only hat a look at the docs and subscribed to the mailing list, but they
claim to be really fast, too.
The only thing that remains is visualisation. First idea was to create
some kind of CVS repository and led WebCVS handle the output. I hoped
attaching modules to WebCVS in order to present the files the way I liked
it would be easy. Well, WebCVS is about 1300 lines of Perl and I'm not too
goog in writing Perl code. It seems well structured, but its main purpose
is CVS, not visualization.
So I wrote my own stuff.
I tried to separate view from control from application model (this is
called MVC -- Model View Controller -- right?). Right now it consists of
two types of classes: Device and Entry.
A typical Device implementation is HTMLTabDev, which formates the output
to HTML tables. A typical Entry implementation is DirEntry, which displays
the contents of a directory (a directory being a special case of a file,
or, in our case, a data base entry). To get more concrete: each device has
a method in(const char *key, const char *name, const char *ref) and each
entry has two methods, itemize(Device *dev) and expose(Device *dev).
Clear text: an Entry (for example a directory, or a file containig
information about a book or some article in an internet shop) can either
expose itself on a page (that is show all its contents) or itemize itself
in a list.
The Device gets via the in()-command contents for each cell of a table.
The contents are ATM only text (which optionally can be hrefs), but may
also be some <img>-tags and so on.
More cells compose a line (so-called "Session"). So, a certain entry can
write one or more "Sessions" to a device. DirEntry for example either
writes one "Session" on itemize() [it writes its own name in a single cell
on a single line], while it calls its sub-entries to itemize() themselves
on expose() [that way exposing its contents -- that would be no entry or
more entries, depending on the way you wish to see it].
If it sounds complicated, read it again, and if it still sounds
complicated, read the source. It's simple!
As future plans I planned to replace DirEntry by some generic FSEntry, and
then re-write DirEntry in a more Directory-Specific way, and add some
FileEntry (e.g. for regular files) and/or UnitEntry for some directory
containing an atomic piece of information in one directory.
To set the last sentence more clear: Some internet shop would have several
HTMLs for each article, as well as some JPEGs and other stuff, which
should not be accessed piece by piece but as a whole. That's what I
planned to use UnitEntry for.
As soon as this runs, a searching system is required (as said, maybe based
on mifluz). As soon as _that_ runs, almost everything is possible.
Reimplementing some derrivated UnitEntry and a rewrite of some main()
function in some CGI-s ript shoud be enough for switching from a book
store to a bug tracking system...
I'll be on holiday the next three weeks, so I won't be able to work on it
too soon. That's why I actually didn't want to make all this public, but
if I wait too long it'll be too late, so, have a look at it and use it if
you like it.
This is not the function you are interested in. [...]
(from the readdir(2) manpage)
Mail archive: http://www.pcrdallas.com/mail-archives/lfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
News Reader access: news.pcrdallas.com
Unsubscribe: email lfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)
More information about the lfs-dev