Non-OO interface to mysql

Discussion in 'Perl Misc' started by Lars Eighner, Dec 20, 2008.

  1. Lars Eighner

    Lars Eighner Guest

    Just another in a series of periodic requests asking if anyone has run
    across a non-OO interface to MySQL.

    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 20, 2008
    #1
    1. Advertising

  2. Lars Eighner

    Guest

    On Sat, 20 Dec 2008 21:55:46 +0000 (UTC), Lars Eighner <> wrote:

    >Just another in a series of periodic requests asking if anyone has run
    >across a non-OO interface to MySQL.


    Are you looking for one?

    sln
    , Dec 20, 2008
    #2
    1. Advertising

  3. Lars Eighner

    Tim Greer Guest

    Lars Eighner wrote:

    > Just another in a series of periodic requests asking if anyone has run
    > across a non-OO interface to MySQL.
    >


    I don't know of any off hand, but I'm assuming there could be something
    out there, or you could write your own method. However, I don't see a
    reason to seek such a thing out, just to avoid OO (so I assume there's
    more to the question), and that could be a pretty big wheel to
    reinvent, especially with all of the error checking, etc. Is there
    more to the issue than that (being OO or not)? If so, you might get a
    more suitable suggestion than just a non OO solution.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
    Tim Greer, Dec 20, 2008
    #3
  4. Lars Eighner

    Lars Eighner Guest

    In our last episode,
    <Itf3l.18820$>,
    the lovely and talented Tim Greer
    broadcast on comp.lang.perl.misc:

    > Lars Eighner wrote:


    >> Just another in a series of periodic requests asking if anyone has run
    >> across a non-OO interface to MySQL.
    >>


    > I don't know of any off hand, but I'm assuming there could be something
    > out there, or you could write your own method.


    Err...no. The idea is to avoid methods.

    > However, I don't see a reason to seek such a thing out, just to avoid OO
    > (so I assume there's more to the question),


    The idea is precisely to avoid OO (best) or at least to have function type
    calls (second best).

    The problem is PHP has function-type (or function looking) mysql interface,
    but sucks for string and text manipulation in general. Perl has good text
    and string manipulation, but has DBI objects (and even the Mysql.pm is now
    really just an alias for the DBI objects, with method-type calls.

    > and that could be a pretty big wheel to
    > reinvent,


    precisely why I keep hoping to find it has been done.

    > especially with all of the error checking, etc. Is there more to the
    > issue than that (being OO or not)?


    Nope, that's it: avoiding OO so far as possible and OO type calls even if
    OO behind the scenes cannot be avoided.

    > If so, you might get a more suitable suggestion than just a non OO
    > solution.



    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 21, 2008
    #4
  5. Lars Eighner

    Guest

    On Sat, 20 Dec 2008 21:55:46 +0000 (UTC), Lars Eighner <> wrote:

    >Just another in a series of periodic requests asking if anyone has run
    >across


    I'm sure you could program somethin like ADO.
    But It sounds like your interested in biting your nuts off.

    sln
    , Dec 21, 2008
    #5
  6. Lars Eighner

    Lars Eighner Guest

    In our last episode,
    <>,
    the lovely and talented
    broadcast on comp.lang.perl.misc:

    > On Sat, 20 Dec 2008 21:55:46 +0000 (UTC), Lars Eighner <> wrote:


    >>Just another in a series of periodic requests asking if anyone has run
    >>across


    > I'm sure you could program somethin like ADO.


    Alternate Dimension Overhead?
    Alien Dominated Orchids?
    Anodized Dominican Organization?

    What?

    Surely the O could not stand for 'Object' since the idea is not to use
    objects.


    > But It sounds like your interested in biting your nuts off.


    Whatever that means.

    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 21, 2008
    #6
  7. Lars Eighner

    skeldoy Guest

    On Dec 20, 10:55 pm, Lars Eighner <> wrote:
    > Just another in a series of periodic requests asking if anyone has run
    > across a non-OO interface to MySQL.


    You could always create a security nightmare/spaghetti-nest by
    invoking the mysql-tool from backticks.. ;)
    `mysql -u root database -e "select * from table;"` or something to
    that accord.

    Still. Not really sure why one would do such a thing. Gonna side with
    the "biting of the nuts"-man there.
    skeldoy, Dec 21, 2008
    #7
  8. Lars Eighner

    Lars Eighner Guest

    In our last episode,
    <>, the
    lovely and talented skeldoy broadcast on comp.lang.perl.misc:

    > On Dec 20, 10:55 pm, Lars Eighner <> wrote:
    >> Just another in a series of periodic requests asking if anyone has run
    >> across a non-OO interface to MySQL.


    > You could always create a security nightmare/spaghetti-nest by
    > invoking the mysql-tool from backticks.. ;)
    > `mysql -u root database -e "select * from table;"` or something to
    > that accord.


    Well, yes, that's how I will go if I have to build it myself. What I asking
    is if the functions for parsing the return already exist somewhere.


    > Still. Not really sure why one would do such a thing. Gonna side with
    > the "biting of the nuts"-man there.

    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 21, 2008
    #8
  9. On 2008-12-21 16:03, Lars Eighner <> wrote:
    > In our last episode,
    ><>, the
    > lovely and talented skeldoy broadcast on comp.lang.perl.misc:
    >> On Dec 20, 10:55 pm, Lars Eighner <> wrote:
    >>> Just another in a series of periodic requests asking if anyone has run
    >>> across a non-OO interface to MySQL.

    >
    >> You could always create a security nightmare/spaghetti-nest by
    >> invoking the mysql-tool from backticks.. ;)
    >> `mysql -u root database -e "select * from table;"` or something to
    >> that accord.

    >
    > Well, yes, that's how I will go if I have to build it myself. What I asking
    > is if the functions for parsing the return already exist somewhere.


    Oh my god. That's really the worst way to implement it.

    Write simple wrapping functions around DBI, if you prefer to write
    $rows = mysql_selectall_arrayref($dbh, "select * from table");
    instead of
    $rows = $dbh->selectall_arrayref("select * from table");

    Or write wrapper functions around the C API if you prefer writing XS to
    writing Perl (but then, why would you write in Perl in the first case?).

    But parsing the output of mysql is just plainly insane.

    hp
    Peter J. Holzer, Dec 21, 2008
    #9
  10. On 2008-12-21 22:12, Keith Keller <-francisco.ca.us> wrote:
    > On 2008-12-21, Lars Eighner <> wrote:
    >> Nope, that's it: avoiding OO so far as possible and OO type calls even if
    >> OO behind the scenes cannot be avoided.

    >
    > As someone else posted, you could simply write your own function-style
    > wrappers around the DBI methods. Compared to basically rewriting DBI in
    > a functional style from scratch,


    Rewriting DBI in a functional style might be interesting (SQL already
    has some properties of functional languages). But Lars doesn't strike me
    as a Lisp or Haskell fan.

    hp
    Peter J. Holzer, Dec 21, 2008
    #10
  11. Lars Eighner

    Lars Eighner Guest

    In our last episode, <-francisco.ca.us>, the
    lovely and talented Keith Keller broadcast on comp.lang.perl.misc:

    > On 2008-12-21, Lars Eighner <> wrote:
    >> In our last episode,
    >><Itf3l.18820$>,
    >> the lovely and talented Tim Greer
    >> broadcast on comp.lang.perl.misc:
    >>
    >>> However, I don't see a reason to seek such a thing out, just to avoid OO
    >>> (so I assume there's more to the question),

    >>
    >> The idea is precisely to avoid OO (best) or at least to have function type
    >> calls (second best).


    > What exactly do you hope to gain by avoiding OO?


    1) The horrible slowness and waste of resources.
    2) Little ASCII art pictures of arrows in code (especially where the arrows
    point the counterintuitive way)

    >> Nope, that's it: avoiding OO so far as possible and OO type calls even if
    >> OO behind the scenes cannot be avoided.


    > As someone else posted, you could simply write your own function-style
    > wrappers around the DBI methods. Compared to basically rewriting DBI in
    > a functional style from scratch, these wrappers would be fairly
    > straightforward to write.


    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 21, 2008
    #11
  12. Lars Eighner

    Uri Guttman Guest

    >>>>> "LE" == Lars Eighner <> writes:

    LE> In our last episode, <-francisco.ca.us>, the
    LE> lovely and talented Keith Keller broadcast on comp.lang.perl.misc:

    >> On 2008-12-21, Lars Eighner <> wrote:
    >>> In our last episode,
    >>> <Itf3l.18820$>,
    >>> the lovely and talented Tim Greer
    >>> broadcast on comp.lang.perl.misc:
    >>>
    >>>> However, I don't see a reason to seek such a thing out, just to avoid OO
    >>>> (so I assume there's more to the question),
    >>>
    >>> The idea is precisely to avoid OO (best) or at least to have function type
    >>> calls (second best).


    >> What exactly do you hope to gain by avoiding OO?


    LE> 1) The horrible slowness and waste of resources.

    you don't know how fast it is until you compare it. premature
    optimization and all. the DB itself is way slower than any OO perl code
    you would use. this is a very silly (which means stupid) argument
    defending your point.

    also programmer time is way more expensive than cpu time. do you want to
    waste all your hours developing this thing or just buy a faster cpu?

    LE> 2) Little ASCII art pictures of arrows in code (especially where
    LE> the arrows point the counterintuitive way)

    just turn your head around and the arrows point in the right way. you
    have a strange view of coding if that is what really bothers you. don't
    go near c or pl1 which had that arrow style for decades.

    >>> Nope, that's it: avoiding OO so far as possible and OO type calls
    >>> even if OO behind the scenes cannot be avoided.


    that makes less and less sense. what if mysql was written in c++ or uses
    some c++? would you avoid it? you have an irrational fear like any other
    phobia. it is all in your mind and not in the code.

    that being said, OO isn't for every problem but a blanket refusal of all
    OO especially for your silly reasons means you aren't a good
    programmer. OO is a useful tool but like any tool can be
    abused. ignoring OO is just abusing yourself.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
    Uri Guttman, Dec 22, 2008
    #12
  13. Lars Eighner

    Tim Greer Guest

    Lars Eighner wrote:


    >
    >> What exactly do you hope to gain by avoiding OO?

    >
    > 1) The horrible slowness and waste of resources.


    I know there are certain people that act like OO is going to kill
    efficiency, but it will not. There is good OO code and bad non OO
    code. The more important aspect is database design. The modules now
    are absolutely not going to impose a problem. You could spend a very
    long time trying to create an alternative and it still might not be any
    faster.

    Either way, to have all of the maturity, checking, etc. that the current
    modules do, it's going to take a lot longer to develop an alternative
    just to not be OO, then it would to just use OO and move onto more
    interesting things. If you wish to, by all means, there's nothing
    wrong with creating a non OO interface, but I don't think it's
    legitimate. It's not horribly slow and it doesn't waste resources. If
    you're concerned with speed, why not use C? Why use Perl at all?

    > 2) Little ASCII art pictures of arrows in code (especially where the
    > arrows point the counterintuitive way)


    If you were willing to work with OO code in Perl, it would probably take
    only a few hours (though maybe days or weeks, depending on the time you
    have and interest, as well as the goal) to get really good at it.

    Again, if you want to do it, go for it. I don't see this as a
    legitimate debate though. You could probably make something faster
    that's non OO, but I doubt that OO is that big of an aspect in this
    case and all that work for just avoiding OO seems like the wasted
    resources.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
    Tim Greer, Dec 22, 2008
    #13
  14. Lars Eighner

    Lars Eighner Guest

    In our last episode,
    <>,
    the lovely and talented Uri Guttman
    broadcast on comp.lang.perl.misc:

    >>>>>> "LE" == Lars Eighner <> writes:


    > LE> In our last episode, <-francisco.ca.us>, the
    > LE> lovely and talented Keith Keller broadcast on comp.lang.perl.misc:


    > >> On 2008-12-21, Lars Eighner <> wrote:
    > >>> In our last episode,
    > >>> <Itf3l.18820$>,
    > >>> the lovely and talented Tim Greer
    > >>> broadcast on comp.lang.perl.misc:
    > >>>
    > >>>> However, I don't see a reason to seek such a thing out, just to avoid OO
    > >>>> (so I assume there's more to the question),
    > >>>
    > >>> The idea is precisely to avoid OO (best) or at least to have function type
    > >>> calls (second best).


    > >> What exactly do you hope to gain by avoiding OO?


    > LE> 1) The horrible slowness and waste of resources.


    > you don't know how fast it is until you compare it. premature
    > optimization and all. the DB itself is way slower than any OO perl code
    > you would use. this is a very silly (which means stupid) argument
    > defending your point.


    > also programmer time is way more expensive than cpu time. do you want to
    > waste all your hours developing this thing or just buy a faster cpu?


    > LE> 2) Little ASCII art pictures of arrows in code (especially where
    > LE> the arrows point the counterintuitive way)


    > just turn your head around and the arrows point in the right way. you
    > have a strange view of coding if that is what really bothers you. don't
    > go near c


    I think you mean c++, not the same thing as c.

    > or pl1 which had that arrow style for decades.


    > >>> Nope, that's it: avoiding OO so far as possible and OO type calls
    > >>> even if OO behind the scenes cannot be avoided.


    > that makes less and less sense. what if mysql was written in c++ or uses
    > some c++? would you avoid it? you have an irrational fear like any other
    > phobia. it is all in your mind and not in the code.


    > that being said, OO isn't for every problem but a blanket refusal of all
    > OO especially for your silly reasons means you aren't a good
    > programmer. OO is a useful tool but like any tool can be
    > abused. ignoring OO is just abusing yourself.


    > uri


    --
    Lars Eighner <http://larseighner.com/>
    Bush's third term begins Jan. 20th with an invocation by Rick Warren.
    Obama: No hope; No change; More of the Same.
    Lars Eighner, Dec 22, 2008
    #14
  15. Lars Eighner

    Uri Guttman Guest

    >>>>> "LE" == Lars Eighner <> writes:

    >> just turn your head around and the arrows point in the right way. you
    >> have a strange view of coding if that is what really bothers you. don't
    >> go near c


    LE> I think you mean c++, not the same thing as c.

    and that is your useful comment to my post? begone with ye and code no
    more.

    btw, i have done procedural code in many langs as well as OO style code
    in assembler and C. i have wrapped OO modules in perl into procedural
    things and there is even a module out there that can do that for you.

    basically it comes down to you unsupportable fears. if you want help
    with perl coding, ask it here. to conquer you fears, seek therapy.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
    Uri Guttman, Dec 22, 2008
    #15
  16. >>>>> "LE" == Lars Eighner <> writes:

    LE> In our last episode, <>, the
    LE> lovely and talented Uri Guttman broadcast on
    LE> comp.lang.perl.misc:


    LE> 2) Little ASCII art pictures of arrows in code (especially where
    LE> the arrows point the counterintuitive way)

    >> just turn your head around and the arrows point in the right
    >> way. you have a strange view of coding if that is what really
    >> bothers you. don't go near c or pl1 which had that arrow style
    >> for decades.


    LE> I think you mean c++, not the same thing as c.

    You are aware that the -> operator comes from C, no?

    foo->bar is syntactic sugar for (*foo).bar.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Dec 22, 2008
    #16
  17. On 2008-12-21 23:31, Lars Eighner <> wrote:
    > In our last episode, <-francisco.ca.us>, the
    > lovely and talented Keith Keller broadcast on comp.lang.perl.misc:
    >> On 2008-12-21, Lars Eighner <> wrote:
    >>> In our last episode,
    >>><Itf3l.18820$>,
    >>> the lovely and talented Tim Greer
    >>> broadcast on comp.lang.perl.misc:
    >>>
    >>>> However, I don't see a reason to seek such a thing out, just to avoid OO
    >>>> (so I assume there's more to the question),
    >>>
    >>> The idea is precisely to avoid OO (best) or at least to have function type
    >>> calls (second best).

    >
    >> What exactly do you hope to gain by avoiding OO?

    >
    > 1) The horrible slowness and waste of resources.


    If you care about that, why are you coding in Perl? Compared to any
    language that compiles to native code (even indirectly via a
    JIT-compiler, like most Java implementations) it's horribly slow. And
    compared to any language which uses an explicit type system, it's a
    horrible waste of computer resources. (But it frees a lot of human
    resources, and for a given time budget, the Perl programmer may even be
    able to write a faster and less resource-intensive program than the C
    programmer).

    Now, let's do a little reality check on the "horrible slowness":


    #!/usr/bin/perl
    use warnings;
    use strict;

    use Benchmark 'cmpthese';

    my $phandle = 23;
    my $ohandle = MyClass->new();
    my $arg = "this is an argument";

    cmpthese(-3,
    {
    'proc' => sub { foo($phandle, $arg) },
    'oo' => sub { $ohandle->foo($arg) },
    });


    sub foo {
    my ($handle, $arg) = @_;
    return $arg;
    }


    package MyClass;

    sub new {
    my ($class) = @_;
    my $self = {};
    return bless $self, $class;
    }

    sub foo {
    my ($self, $arg) = @_;
    return $arg;
    }
    __END__

    This little program compares a "procedural" subroutine call with an
    oo-style method call.

    Rate oo proc
    oo 783445/s -- -7%
    proc 838852/s 7% --

    Hooray, procedural calls are 7 percent faster. That's a whopping 84
    nanoseconds per call. But let's run it again:

    Rate proc oo
    proc 786957/s -- -7%
    oo 842802/s 7% --

    Oh, this time oo is 7 percent faster.

    If you repeat that a few times you will see that in about 50 % of the
    cases the procedural call is slightly faster than the oo call and in
    50 % of the cases the oo call is slightly faster - or in other words,
    the difference is not even measurable with a simple benchmark.

    hp
    Peter J. Holzer, Dec 22, 2008
    #17
  18. Lars Eighner

    Klaus Guest

    On Dec 21, 8:53 pm, "Peter J. Holzer" <> wrote:
    > On 2008-12-21 16:03, Lars Eighner <> wrote:
    >
    > > In our last episode,
    > ><>, the
    > > lovely and talented skeldoy broadcast on comp.lang.perl.misc:
    > >> On Dec 20, 10:55 pm, Lars Eighner <> wrote:
    > >>> Just another in a series of periodic requests asking if anyone has run
    > >>> across a non-OO interface to MySQL.

    >
    > >> You could always create a security nightmare/spaghetti-nest by
    > >> invoking the mysql-tool from backticks.. ;)
    > >> `mysql -u root database -e "select * from table;"` or something to
    > >> that accord.

    >
    > > Well, yes, that's how I will go if I have to build it myself.  What Iasking
    > > is if the functions for parsing the return already exist somewhere.

    >
    > Oh my god. That's really the worst way to implement it.
    >
    > Write simple wrapping functions around DBI, if you prefer to write
    >     $rows = mysql_selectall_arrayref($dbh, "select * from table");
    > instead of
    >     $rows = $dbh->selectall_arrayref("select * from table");


    No need to write wrapper functions. A plain...

    $rows = DBI::mysql_selectall_arrayref($dbh, "select * from
    table");

    ....should work.

    --
    Klaus
    Klaus, Dec 22, 2008
    #18
  19. On 2008-12-22 12:53, Klaus <> wrote:
    > On Dec 21, 8:53 pm, "Peter J. Holzer" <> wrote:


    [Non-OO DB interface]

    >> Write simple wrapping functions around DBI, if you prefer to write
    >>     $rows = mysql_selectall_arrayref($dbh, "select * from table");
    >> instead of
    >>     $rows = $dbh->selectall_arrayref("select * from table");

    >
    > No need to write wrapper functions. A plain...
    >
    > $rows = DBI::mysql_selectall_arrayref($dbh, "select * from
    > table");
    >
    > ...should work.


    No, because $dbh is not an object of the class DBI, but of the class
    DBI::db.
    DBI uses quite a lot of classes internally, and several of them depend
    on the DBD driver actually in use, so you generally don't know (and
    shouldn't care) which class an object belongs to (just which interface
    it implements, to borrow some terminology from Java).

    hp
    Peter J. Holzer, Dec 22, 2008
    #19
  20. Lars Eighner

    C.DeRykus Guest

    On Dec 22, 4:04 am, "Peter J. Holzer" <> wrote:
    > ...
    > #!/usr/bin/perl
    > use warnings;
    > use strict;
    >
    > use Benchmark 'cmpthese';
    >
    > my $phandle = 23;
    > my $ohandle = MyClass->new();
    > my $arg = "this is an argument";
    >
    > cmpthese(-3,
    > {
    > 'proc' => sub { foo($phandle, $arg) },
    > 'oo' => sub { $ohandle->foo($arg) },
    > });
    >
    > sub foo {
    > my ($handle, $arg) = @_;
    > return $arg;
    >
    > }
    >
    > package MyClass;
    >
    > sub new {
    > my ($class) = @_;
    > my $self = {};
    > return bless $self, $class;
    >
    > }
    >
    > sub foo {
    > my ($self, $arg) = @_;
    > return $arg;}
    >
    > __END__
    >
    > This little program compares a "procedural" subroutine call with an
    > oo-style method call.
    >
    > Rate oo proc
    > oo 783445/s -- -7%
    > proc 838852/s 7% --
    >
    > Hooray, procedural calls are 7 percent faster. That's a whopping 84
    > nanoseconds per call. But let's run it again:
    >
    > Rate proc oo
    > proc 786957/s -- -7%
    > oo 842802/s 7% --
    >
    > Oh, this time oo is 7 percent faster.
    >
    > If you repeat that a few times you will see that in about 50 % of the
    > cases the procedural call is slightly faster than the oo call and in
    > 50 % of the cases the oo call is slightly faster - or in other words,
    > the difference is not even measurable with a simple benchmark.
    >


    Totally agree but this particular code gives OO an
    edge due to method caching.

    A slight tweak: $arg . ("a".."z")[int(rand(26))]
    consistently tilts for the faster procedural call ...
    at least for some small Solaris and Linux sample
    runs.

    --
    Charles DeRykus
    C.DeRykus, Dec 23, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wildepiet
    Replies:
    0
    Views:
    1,861
    Wildepiet
    Jun 14, 2004
  2. cyberco
    Replies:
    8
    Views:
    487
    cyberco
    Feb 25, 2006
  3. Xah Lee
    Replies:
    15
    Views:
    584
    Sherm Pendley
    Mar 23, 2007
  4. Xah Lee
    Replies:
    15
    Views:
    630
    Sherm Pendley
    Mar 23, 2007
  5. Replies:
    4
    Views:
    347
    timjowers
    Nov 2, 2007
Loading...

Share This Page