Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

[UPDATE] April 24, 2003 -

Quote Reply
[UPDATE] April 24, 2003 -
 
Hi All :)

I'm sort of back in the swing here, and the code is falling together a
bit nicer than I would have expected already.

A brief update:

The main program I'm working on is an Auction system. It will generalize
to a classifieds and personals fairly easily, and it will (hopefully) fully
integrate Community, GForum and Links, as well as GMail into one "whole"
package to which you can add in any of the parts, and realize increased
functionality.

The auction system will include a fully functional user-uploaded image
management system. I need to differentiate this from the ImageSQL system
I'm working on (the upgraded version of the MultiUp/Image system from almost
two years ago). What the integrated system will do is allow users to upload
one or more (this is flag settable, and then limitable). The "one" image
system uses a field in the liks database, and takes the place of the Logo/Graphic
Upload plugin. In the multi image system, this field has "special" characteristics,
which you can use, or choose to ignore, in which case all images are "equal".

The "back end" reason for this, is a very, very large database of images I need
to get on-line and manage, and only want to do ONCE. What this means, is no matter
how the system will crash, no matter where in the backup process I am, it can be
rebuilt. The whole system depends on the fact that the images are uploaded from
an off-line source (meaning they are already backed up). This is my situation.
If it's not yours, just make sure you back up your data (image) directories <G>.

The program will "read" each directory, directory tree, and such, and will
"import" the images into the image database. How this happens is the part that
is under construction. I'm still figuring out what I need, and my "rules" changed
in that I'm now managing the whole 200,000+ (more or less) image base.

The initial read in, will create a default directory/category structure based
on the directory names imported. As each directory is edited, moved, or otherwise
updated, this information will be stored both in the SQL database (for main
management) and in a flat file (Files.bbs analog) in the physical directory
the images were read from. So, when you update a description or groups of an
image, that data is written not only to the database, but the the flat-file
in the actual physical database (this of course can be turned off if you are
using read-only media). What this allows, is you to re-build your SQL databse
from the image-library on disk, should your SQL server go belly up. (If you
keep your SQL databases and the image databases on different physical devices,
and perhaps on different machines, this should be as secure as anything besides
a regular backup system and RAID device <G>

In "manual" mode, you will give it a directory, or directory tree, and it will
read in that directory, and then go through the motions above.

In long years of managing image libraries, the _easiest_ way of adding in
large numbers of images, or collections, is to copy them to disk, where you
want them, then tell the software to "Go get" and provide the software with as
much pre-defined information as you can -- download file name, description,
groupings, keywords, etc. Adding them one at a time, is beyond maddening <G>


The third project is an AVS type system, using tokens (a micro-payment system)
where a user makes one charge, that fills their account, and then they can
spend the tokens across the network, and payments, royalties, etc are based
not only on sign up, but on where the tokens are spent (ie: content delivery,
not the best marketing).

The fourth project is to take all the above, and weave it into one community,
with images, classifides, personals, in depth user profiles, editor management,
rewards and kudos, newsletters, calendars, postcards, etc. Pretty much a well
integrated "COMMUNITY" <G>. You can think non-adult, but if you think "adult"
you will be more in-line, since most of the features translate more to the
pay-as-you-go adult market than the free-to-all public market. This will most likely
be an OEM type version of links, etc. You buy your license, then can access this
program group, which will install on top of your Links SQL license. ( you will add
in Gforum, Gmail, etc if you have the liceses for them. Most user scripts will have
been rewritten, and only the "core" GT/program libraries will remain mostly
untouched. I'm using "Links SQL" as the base, since the other programs are
fully functional stand-alone apps already, and just need tweaking to fit into the
whole. All the "special" features will be built up from the Links SQL install, since
it's the most flexible and modifiable of the GT Suite.

The fith etc project is getting the existing plugins I have repackaged into
one group, one install, and upgraded for links 2.12, with a calendar program
tossed in.
-- anyone has a working SQL calendar they want to donate to jumpstart this,
I'm interested <G>. It looks like the Date::Calc and Calendar::Plot have
90% of the code, and it's a matter of wrapping it in GT-specific code,
adding in the SQL back end, and adding in the features like private event
lists, and such. (Private event lists are things that only show up when YOU
view the calendar... )
-- I'm hoping to have this all out (Project 5 <G>) by mid next month, at the latest.


1) Any suggestions (CONSTRUCTIVE) are always welcome.
2) Any help to work on this, write portions of it, or design portions is welcome.
3) This will be "open source" GPL, CopyLeft, or whatever. It's "free" to use,
modify, alter, and charge for SUPPORT, for anyone who has a valid GT SQL license,
provided all alterations you make to the program are shared with the general
community as the "License Fee". Not sharing your alterations (if nothing else,
upon request) is/will be the only Copyright Violation. Piddly minor changes, are
excluded, but any and _ALL_ bug fixes, or code modifications need to be shared.
4) etc... <G>


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] [UPDATE] April 24, 2003 - In reply to
PS: as I said in another post, I lost 2 years of notes, things to do, requests, etc when my computer was stolen, so any refresh of things I promised to take care of, or look into are welcome too. ;)


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] [UPDATE] April 24, 2003 - In reply to
Sounds great - I am very interested in the AVS part - can a donation jumpstart that too? Smile

Klaus

http://www.ameinfo.com
Quote Reply
Re: [klauslovgreen] [UPDATE] April 24, 2003 - In reply to
<G> Might jump start it.

But, more likely, any donations will probably prioritize what gets done first ;)

Honestly, donations of working or mostly working code are much more appreciated :)

Code should be written in module/subroutine form, so they can be "used" or "included" as needed.

BTW: the AVS portion is somewhat dependent on Alex getting the payment gateway code working, and released, since until then, it's mostly just a "token" system <G> (pardon the pun....)


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] [UPDATE] April 24, 2003 - In reply to
s/Alex/Jason/

=)

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] [UPDATE] April 24, 2003 - In reply to
<G>

I wasn't sure who, so as head honcho, you took the jibe.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Last edited by:

pugdog: Apr 24, 2003, 11:11 PM