Geeklog 1.3.2, 1.4 and Beyond!

Okay, you want a list, here's my list :)

• OOP
  Nuff said.
• 10,000 Users!
  GL needs to scale. We need to look at how we can handle 10,000 users at the same time. What breaks if this happens, and how do we fix it. This will be a database cache and sessions issue (mostly).
• Bite the Cookie!
  The default session management should be straight from the server, zero cookies. We could offer an option from within the Admin screen to allow a user set cookie option for auto-logins, but this is a security hole - no matter how many users ask for it. Cookieless sessions will also solve the whole 'cookie through a firewall' problem, the cookie whingers, etc.
• One Thread to Bind Them All
  (Don't ya love these titles?) A single thread, from beginning to end. We should use a container and object concept for our content. Each entity on the thread contains it's exact location within the thread, in a field called TREE. So, a topic could have a TREE field of '|1|4|7|' (where 1 = site root, 4 = topics, 7 = the topic ID), a message under it would be '|1|4|7|8|') and the reply under it would have a TREE of '|1|4|7|8|9|'. So, if we display the topic, ONE sql call is called to grab ALL the children, rather than rescanning the DB continually (WHERE TREE = '*|7|*' or something).
• I'll See Your Message, And Raise You A Poll
  The ability to create and reply with a number of different content entities. Under a Topic, you could create a Message (say simple on a party). Under this, the user would then create a Calendar entry (the details of the party in the date format, with email alerts, which would appear as a thread under the Message, and in the Calendar). The user could also create a Poll (would you chip in for a stripper?) which would be 'private' to the message (ie, not appear on the mainpage, etc). The user then creates a secure message (limited to his friends) which posts the address and private details. The user could also place a ban on post replies to the poll or calendar entry - they must sit under the message itself. In addition, having content as objects (code speaking) means we can update them easily, plus create new object types. We could even turn off some types if your system doesn't require them. My current idea for content types include Message, Calendar, Poll (used for normal polls, and for ratings), Archive (download lists), Media (images, shockwave, etc). We would need to establish a security system for these also. Perhaps under each object, you can say what will and what will not be available - with an inheritance feature. One topic can be assigned for messages only (limitation inherited), one topic will allow messages only but replies can be polls and media (limitation on all except messages, inherited only on calendar and archive).
• [b]Looks Like We're Surrounded[/b]
  Yep, GLML! Or for those who were not into the 1.3 wishlist and coding, GeekLog Markup Language. A complete markup language to replace the use of HTML within messages. This allows the admin to control what and how things are displayed, plus through the admin screen, allows them to add, alter and remove tags. Want your [b][/b] to be bold AND blue? How about your [b][/b] to be bold for regular users and bold and blue for ADMIN users? Applying the security settings to the markup language allows greater flexibility. For example, only Moderators and Admins get the [img]http://here.com/there.gif[/img] functionality. Also it saves DB space (mostly). The smiley code is a good example. Remember, :) is smaller than anytime. However, this means parsing the results from the database, a bottleneak could sneak in ... so this leads to my next point.
• Attack of the Clones
  Simply put, we need to cache pretty much everything. We need to check if the data has been changed (incorporate a simple checksum along with the index?) and then write the data to disk. We can implement the cache to be the 'front end' of the site also, so that 'http://site.com/news/2001/01' displays the News for January 2001. Or something :) I'm sure you get the idea. These 'static' pages would also help dovetail into using mod_rewrite (see below).
• Where Did That Masked Gif Come From?
  The use of a media.php file would allow us to effectivly control where and how media is stored. Our media.php file would grab the specific media from a location and display it as normal. For example, media.php?loc=smiley&pic=grin.gif would look into the predefined directory assigned the keyword of 'smiley' and pipe the grin.gif image back to the browser. If the image is not there, it can return a flashing 'oops' gif (or something). Aside from the obvious security benefits (the user never knows where the image is coming from), there's the co-location benefits. The location of the 'smiley' images could be in a subdir, another machine, or even in a database. These would need to be set within the Admin screen.
• /Get/Your/Gear/On
  All our php files which work with passed variables need to handle mod_rewrite if it's being used.
• Get Your Ticket to Nirvana
  We all know of it, some of us are even whores to it. Karma. A admin configured system where user comments are rated higher and lower depending on a) your actions and b) the whims of the readers. Higher starting karma for registered users, regular posters, regularly upgraded posts, admin's whim. Lower karma for those who annoy the admin, regularly post messages that are degraded by users.

• You can lead a user to Create, but you cant make them Read
  A larger security model is needed, built on the existing one. Users and Groups are great, but I want more than a binary YES|NO system. Rights assigned to CREATE, VIEW, REPLY, EDIT, MODERATE, KARMA, DELETE, FEATURED, FLOATING, ADMIN, etc. Oh, spot the floating? It's a toggle which allows the message to be 'like' a featured one - they float above the normal ones, and sit under the featured one. An example of this system is a feedback system. A topic called System Feedback is created. Users can CREATE and nothing else. MODERATORS can CREATE and VIEW and REPLY, and nothing else. ADMINS can do anything.
• But I don't own my own machine, I run in a subdir
  This is a personal annoyance for me, as I do just that for a club I help. The security features of GL are great, but we need to be able to cater for pretty much any userbase. Just like cookies as an option, we need to be able to move the 'out of webtree' directory simply and easily. I managed to get this working for 1.3 (didn't get into the release), and I want it in a 1.4 release. Basically we have two key paths, 'SYSPATH' and 'WEBPATH' and all file calls use with these. The WEBPATH usually is something like 'homeuserhtml' and the SYSPATH would be 'homeusergeeklog-system' ... or something. By doing this, a subdir user can move (and reassign) the WEBPATH to 'homeuserhtmlsubdir' and SYSPATH to 'homeuserhtmlsubdirgeeklog-system' ... or even alter the system path to obscure it a little. It's not hard, and it's something asked for ALOT. Hell, it would get the monkey off my back at the least.

Well I'm sure this will get some people thinking. I'll be around to help define this out, and you can be sure I'll be into rebuilding GL into the monster blog it can be. IFor me, this ain't no wishlist, I *WANT* these things implemented into the system I want to use. We're already well on they way.

http://www.boesch-it.de/sw/simpnews.php

The + symbols (links) in the left nav demonstrate the single-thread approach.

more to come...

-----
The reason people blame things on previous generations is that there's only one other choice.

I'm sorry, could you please DETAIL what you actually mean? It's a little hard for a programmer to sit down and build a working spec around only the phrase 'must work' ...

So for some stuff I'd like to see hit a version near us?

• no supervision required
  Some users, or groups, should be able to post news without waiting for moderation. If you're just using this for yourself (geeklog as a home page) you might not want to be bothered by having to approve your own posts everyt time.



• I'll take the little guy
  Different user account options. Some people might not want to allow users to sign up on their geeklog site (really, they might not). Some might want them to sign up as they do now, automatically being approved, getting a random password via email. Some might want to manually approve membership (a little more admin, but if it's a site for family and friends, or of very specific purpose, you might want to be able to say who comes and who goes). These three options are relatively tame, and could be implemented pretty easily. A fourth option, important to me, would be 'custom approval'. Say I had a few extra columns in my database for subscription_expire_date, subscription_rate, subscription_paid. I'd handle all the code to fill in the columns, but I want to assign a user approval method that lets me specify a sql query, and a 'valid' response.



• middle blocks
  I'm convinced that there will be times when the side blocks are too small to do what I want. What if I want to do 'featured screenshot' on my 'screenshot' section, but i want it to show up at 640x480 in a box, or a little less in a box, but not an iconified 100x75 image. Only one example there are probably a lot more, but I want middle blocks. No sweat to find the latest screenshot in a directory and have my function return the marked up image tags, for a php block... Or to pull a random image from a directory (wallpaper of the day, free pr0n of the day, whatever)



• Organization
  infinitely nested parent child relationship of "cateogries" or "sections" or "pages", whatever you want to call them. The flexibility to move whole branches from point A to point B and have it still be a tree. To be able to move a root node to be a child of one of it's children. To be able to have 20 categories named foo, and them all to be distinct.
  
  This is essentially the whole heirarchical category stuff that has been talked about for a little while. It should be flexible enough to be restructured, and not require unique names. I might want to have:
  
  
  Programming
  -> Web
  ---> PHP
  ------>Tutorials
  ---> JSP
  ------>Tutorials
  
  instead of
  
  Programming
  -> Web
  ---> PHP
  ------>PHP_Tutorials
  ---> JSP
  ------>JSP_Tutorials
  
  
  
  'Stories', 'Pages', 'Categories' should be assignable to functionality. Maybe they default to all. But I should be able to assign PHP->Tutorials to (stories/links) or PHP->Scripts to (links). I might want to assign Family->Albums to (plugin - gallery) or something to that effect. I should be able to chose what I want to show in the sections block, but the Family -> Albums page would have no stories, no links and no events associated with it, only plugin properties.



• can i get a sub-Mit
  There have been several occasions when I would have appreciated the form action buttons to be at both the top and bottom of a given dialog, depending on how I work, so that when I've finished my current flow, the next logical step is where the 'save' button is, not all the way back up at the top again. Maybe that's trivial, but make a tool usable and we're getting somewhere.



• standards
  I think the initial themes, templates, and all geeklog output should be XHTML compliant.



• anabolic steroids for links
  I think our 'links' section should develop into a full-fledged bookmark management tool, complete with the ability to import netscape bookmarks or ie favorites or opera bookmarks, etc. We should build on the whole heirarchical categories. Maybe add a function for block inclusion like "Newest Links", "Hottest Links" that people can put in left right blocks if they want, but still see full fledged link management.



• big name plugins
  For a full-fledged 'community' type site I think there has to be all that geeklog is, and, some sort of photo-gallery script, and a forum of some sort, and for people without free bandwidth probably a banner ad system. It seems people have an affinity towards gallery (gallery.sf.net) and John Holmes has worked a way to wrap it in geeklog. Maybe we vote to pick some top app (gallery, phpbb2, and phpads) and get working to fully integrate them into geeklog as plugins (including coming up with layouts to match our current included themes), or build our own or something.



• relations
  Or more specifically, what's related to me. Another comment from either the mailing list or SF, but the ability to do keywording. So you specify a list of keywords, either for more correct meta searching, or to just drag out a list of related items at the bottom of the story.



• wow, aren't you interesting.
  I'd like to be able to see someones karma, or maybe more specifically to be able to say "this guy is interesting". Then by clicking on his username I can see all his comments, all his stories, etc. Or, maybe I can subscribe to this guy, and in a side block have something like 'dreamscapes latest comments', or 'dreamscapes latest posts'. or subscriptions: dreamscape(5).



• can o worms
  Subscriptions in general sound good to me. Maybe I can subscribe to a story and be notified whenever it gets updated, edited or commented on. Maybe I can subscribe to a gallery (plug-in issues) and find out whenever photos get comments or photos get added. I'm sure there are other uses for subscriptions...

Thats starting to stretch my brain a little. I'm agreeing with most (more likely all) of what has been listed so far, and trying to add new ideas, not just repeat the ones made before. That is why I didn't talk a whole lot about permissions, but, a feature request on SF asked to be able to disable 'calendar' and maybe something else for certain groups, i think this could be accomplished and more with build out of the permissions.

This is where I'm confused I guess. In my world you could basically use a really good link management tool to do all your downloads as well. Correct me if I'm wrong, but if things workout the way I we think they will with heirarchical categories and a revamped link section, you should be able to make a category/section called "downloads" and maybe even say it's only a link area. Then when people click on the "downloads" section they enter that part of the link library.

I guess I might be confused on what the difference between a download and a link is. In my world a link can be a reference to anything. Web sites on another server, your favorite news item on your geeklog site, a tarball of some really cool TTF's on your site (or someone elses). make the links what you want.

I think you'll get all the functionality you'll want for "downloads" although it might not be called "downloads" until you name it (:

Users can opt to have their info PUBLIC or PRIVATE. The current geeklog default would be PUBLIC. PRIVATE would show user name only. An enhancement would be to provide check boxes for each item a user wanted to be shown when their username was clicked on.

More fields for user info. To facilitate the use of geeklog for the purpose I need, fields for snailmail, phone, etc. would be useful additions. How about a field for user creation date? Also, check boxes for inclusion on email and or snailmail lists would be great. Perhaps BLOG or ORGANIZATION-PORTAL could be install-time options?

Data mining tools. This might be as simple providing a button to generate spread-sheet compatible OUTFILE dumps of tables like USERS to the admin. This allows the group to generate mailing labels and phone trees from the registration information. For the techno-phobic secretary of this group, I'm using the bloated functions phpmyadmin for this (BTW, phpmyadmin is AWESOME). But, even this 'thin' client is too scary for her. Maybe more value-added mining tools could be devised as well.

Comments?