Community archive

Ask something
Discussion Locked

Workspace. addon idea...

0 helpful
57 replies

by jaqui

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

and Question..

When is the Shared Project functionality going to be implemented? any timeline on it?

for a test of that, why not have some members collaborate on a site script that duplicates TR's, with the feature requests that have been most frequently asked for.

it may require adding something like cvs or subversion tools to the workspace though.
[ or one member putting a version control server space up for it. ]
if that happens then that same box could also be used as a platform for testing the script with.

since this script could become part of the foundation for further TR improvements, I doubt that such a project would ever become visible to the general membership, which is why I posted the idea in here.

57 replies

by maxwell edison

I recently started a discussion in this section, and nobody replied for days and days. So I just changed it to "-".

However, after I changed it to "-", it generated 18 replies!

By the way, I would comment on your original suggestion, but it all flew right over my head. When you started talking about cvs and subversion tools, the only relation I could make was to subverting terrorism with some new kind of weapons of mass confusion.

by jaqui

subversion and cvs are colaboration tools, for sharing source code.

The original idea being to get members to "colaborate" on something, using the workspace and maybe a version control system, that would have a benefit for TR as a whole.

by Jay Garmon

...since we run TR on about three different platforms (Jive for community, a proprietary Java-based system for articles/downloads, and a whole other off-the-shelf database for white papers), and we realy don't have the means to replicate all that in a versionable environment. This is a total Frankenstein job.

Even if we're just talking community stuff--discussions/tech q&a/blogs/links--there's still a couple dozen unique, interdependent JSPs hitting a replicated test database thats 90 days out of sync with our live system and hidden behind the company firewall. Not exactly the kind of contraption to idly tinker with.

As much as I'd like to get sort of an "Open TR" project going, I don't see it as immediately feasible.

Now, if you want to talk about an open spec, well, that's different. We could get a private Wiki doc and let some of our chosen favorites spitball a solution for some of our feature problems.

by jaqui

could work.

I was thinking along the lines of having some members, that fit the "trusted" classification work on creating a complete site script to duplicate TR, with the requested features / bugfixes.

this wouldn't require opening any confidential data, as the needed sections for TR are clearly obvious. [ read, we can see the sections for tr, and know there has to be admin functions ]

The resulting code base would be functional as is, and a foundation for TR's own team to customise or use as a starting point for TR itself. [ or even as inspiration on some of the more irritating bugs ]

personally, I would do most of the work with php as cgi, creating the abstraction from the data sources that currently exists, and possibly improving performance overall. [ java server pages tend to get slower as traffic increases more than any other scripting language ]

by jaqui

with all the skilled people here, creating a content management system that would fit TR, yet be available to those that helped develop it if they need one, shouldn't take a huge amount of time.
[ hense the completely new code base rather than TR revealing confidential data ]

ohhh.. table design for a discussion in a mysql db..

I have a sweet one, that will allow for infinite depth of replies, yet is very simple.

[pre]
#
# Table structure for table 'topics'
#
CREATE TABLE topics (
topic_id int(11) DEFAULT '0' NOT NULL auto_increment,
parent_id int(11) DEFAULT '0',
root_id int(11) DEFAULT '0',
name varchar(255),
description text,
create_dt timestamp(14),
modify_dt timestamp(14),
author varchar(255),
author_host varchar(255),
PRIMARY KEY (topic_id)
);
[/pre]
root id is the discussion topic : TR Insiders
Parent IT is thread
Post ID is the post.

reply to this post it would become the parent, the root would be the Thread

might have to add one more level of id for the multi section discussions we have here.
add a 5th level for multiple topic postings.

by Jay Garmon

So you're talking about designing a parallel universe version of TR from the ground up as an open-source project. Interesting. Considering how feature-rich we'd need the site to be, that's one hell of a dev commitment, especially considering that we in all likelihood couldn't give you tie-ins to our live data (or even replicate the data to a dump server--that's a long story about caching and network latency).

Still, I like your moxie, and if I could swing the server space--a seriously huge if, mind you--this could be a heck of a fun exercise. And great PR, I don't mind saying. I still think we'd need a consensus spec document first, just so all our coder are on the same page.

Tell you what, if you get me a half-dozen names of seriously committed users who would be willing to hash out a spec and then help code a prototype, I'll fight for this as a project initiative. I can't make promises, but this sounds incredibly cool. Talk about user-driven Web sites.

by jaqui

and, for Clarity, this list of committed members has to meet approval of TR bosses? [ I would have to limit it to those with TR Insiders access already to meet minimum approval requirements of the list. ]

or is it open to any member that is willing to commit to working on it?

I'm looking at a hosting provider that may be willing to add cvs or subversion, so the server space isn't really an issue.
the host offers mysql as DB, apache webserver, lots of nice little bells and whistles.
[ cheap too, for the plan that may allow adding cvs / subversion it's starting at $16.39 USD / month.. 5 gigs webspace, 50 gigs data transfer ]

If I can take it to the general membership, I'll have 6 by Friday. :)

by apotheon

Perl outperforms PHP somethin' fierce, and is in general a better language, particularly for CGI stuff. I'd probably aim for PHP if I was going to do markup-embedded code, but not for CGI, by choice.

Still, I'd rather work with PHP/CGI than Java.

by jaqui

the entire project is in discussion stage and everything is up in the air.
I do have php scripts right now that can be used as a base, for most aspects of the script.
I even have a script for online collaboration designed for writing articles, ecommerce script, discussion script.

all of which could be used as a baseline for the issues / concerns to be addressed and idea sparks for the actual code.

I posted the table design for the discussion script in a reply to jd in this thread.
basic, yet covers most aspects that would be needed in a more robust discussion table.

by apotheon

I would hope "take it to the general membership" doesn't mean "post a public thread". There are people in the "general membership" who would be great to have involved, but I don't know that I'd be keen on random strangers wanting to get in on the ground floor.

The more I think about this, the more it interests me.

by jaqui

taking it into a generally available forum wouldn't be a good thing, but there are a lot of members that do not have insider access that would be great to have on such a project.

if we can get enough volunteers in the insiders to get an ok, then we can get some of the general members approved for inclusion, by invitation through peer contact.

6 is good for getting approval, but 20 or more for getting something this complex done would be better.

by jaqui

is You, Apotheon and I, probably JD as well.
2/3 of the number needed for getting it started with TR approval.

seems like it will become a go. :)

Then we would have to agree on the language to be used, if TR doesn't demand we do it in java server pages. [ hoping that they don't ]

then the user interface, within the constraint's that TR will set.

going to be quite heavy in the xml for the blog /wiki /rss feed aspects.

by stephen howard-sarin

Jaqui started this thread talking about Shared Projects in Workspace -- functionality that's at least a couple months away. So why focus this (very cool) idea of TR team development on new software for big, public discussions? Why not build something that works best for smaller groups of people, like a Shared Project?

Think of it as the difference between building software for a BBS (which exist by the dozens) and building something for a SIG.

I am not a coder, and you can choose do focus on whatever you like. Just one man's opinion.

Stephen Howard-Sarin
VP, Business Technology Portfolio (incl. TR)
CNET Networks
shs@cnet.com

by jaqui

1) what do you mean by SIG?

2) I started it asking about the shared projects, in order to get a community driven project to create the big project. :)

kind of a put your money where your mouth is to the Membership. Since we do complain about the bugs, and request features to be added, most of us do have the skills, so lets get an entire big content management script together that has the features we ask for, that TR intends to have, and that, hopefully, is bug free.

Yes, a big project.
Yes, a lot of work.
But, for a lot of people in the TR Insider group it's also a learning experience.

The benefit of going after the larger project: CNET / TR don't have to expose any data to members that we don't already have access to. [ outside of features not implemented yet ] No database structure, no access to confidential areas / services.

When completed, altering the database to fit the current one(s) breaks the specific knowledge we would have of the functionality behind TR.

The participants would have the knowledge that we contributed in a very concrete way to the site, and TR gains the PR bonanza of being able to state that the site was scripted by the community.

Those who participate also wind up feeling much better about TR, since we would know, beyond any reasonable doubt, that TR does accept input from members, more than seeing response to complaints alone shows.

All members would know that not only is TR a community site, it is the most responsive community site on the web. [ ie: even phpnuke's website doesn't include all features available for phpnuke ]

by jdclyde

so a conversion program could be written to pull the existing data into the new structure, once it would be ready to be put in place.

by stephen howard-sarin

Sorry for being unclear.

I'm just suggesting that the community coders should focus on areas that minimally overlap with our internal development plans.

We want to create Shared Projects for smaller groups to collaborate (kinda like what's happening in this thread), but we know we won't get it done soon. So that would be an area where the talents and sweat of the community would be a huge advance.

Coding up, say, a better BBS for the main discussions would be highly redundant with our internal efforts, and less efficient.

Or not. The focus of this project is up to you folks!

by jaqui

I would bet that TR's staff coders would change the db specific data in the script to fit the current db.

obscurity of data structure is a defense against hacking of the site.

and that is 4 of the six for sure.

so two more to get Trivia Geek to work on the Administration of TR for permission.

by hal 9000

You certainly pick your time don't you?

Not when I've got heaps of spare time but you have to bring up this when I'm run off my feet [b]You Bar steward :p[/b]

Yes I'm interested though I haven't punched any serious code for quite some time and right at the moment I'll only have after midnight to have a play. I'm game.

Col

by Jay Garmon

There would probably be some online form that we'd have to have participants fill out to get access to the Wiki spec--just so we have an idea of who is actually working on this--but I have no problem with you individually approaching non-TRIs. Anybody who is passionate enough about the product to commit time and resources to this effort would qualify as an Insider in my book. If they are serious about the commitment, we might actually extend them full TRI privileges.

In any case, find me a reliable, competent, passionate build team of TR members, and I don't care where they come from.

by Jay Garmon

There's some internal development love for Wordpress, which is written in PHP. We're current using TWiki for our wiki stuff, and its written in Perl, but it doesn't scale at all. MediaWiki (AKA Wikipedia) is written in PHP. A Wordpress front end bolted onto a MediaWiki database might be the holy grail, but that's just idle chatter.

by jaqui

in alphabetical order:

apotheon
Hal9000
Jaqui
jardinier
jdclyde
Tony Hopkinson

now to get enough bodies to actually complete it.
would need another 12 at least. [ in my opinion ]

well we can add:

faradhi
stargazerr
tjsanko@...

that's 9. I say 20 is a good number to aim for to have a solid team.

by jaqui

I subscribe to the opinion that the only truly stupid question is one you don't ask. :)

While getting the shared project script would be faster, the interest is in more than just one small area like that.

The Discussions may be the most active, but the TQ&A is one that generates the most strong opinions on issues.

The overall layout also causes quite few complaints.

Getting the community to actually commit does require making sure that the areas that generate the most feeling in the members be addressed.
[ look at how long the shared project post that started this thread took to get a reply, yet as soon as it was tied into general site improvements it took off. ]
~lol~

in any community [ read volunteer ] driven project, the member interest defines the area to be addressed.

by apotheon

It makes sense to me to try to guide the focus, first off, toward functionality that isn't covered heavily by current site architecture (and toward functionality that simply doesn't work well). In some cases this would involve serious overlap, and in some cases not so much.

I'd like to see a very decoupled design for this so that we get a bunch of modular pieces that can be combined to form the Voltron of your choosing in setting up a website. In particular, I'd like something I'd be willing to use elsewhere, as well as something for TR itself to use.

We should discuss what sort of licensing to attach to our code, too. I favor something akin to the BSD license, personally, but with inheritance characteristics. Maybe my first concrete contribution to the project should be to finish the damned next release version of CCD CopyWrite once and for all, finally, so we can use that (assuming others don't object to it as a distribution license for the project).

by jaqui

with both points.
we do need to look at the available licenses and pick one. [ as I posted above, I would argue against the gnu-gpl ]

and a modular design is the only true method for something like this.

the base is the authentication of members, news / articles [ site specific ] and site admin functions. everything outside of that is a module that adds the functionality.

by apotheon

Before we start recruiting in mass quantities, it might make sense to start hashing out basic plans and requirements. Such decisions are usually better made by small numbers of people. If later-joining participants have suggestions for how to change our specs, that's great: I'd favor something closer to an "agile" approach than old-school corporate dictated requirements. We should just have some kind of direction in place before muddying the waters with more "democracy".

by apotheon

Having been amongst the developer chatter for MediaWiki, I can say with some certainty that it seems the reason MediaWiki continues to be developed in PHP is that nobody wants to start over with Perl, Python, Ruby, or C/C++, despite developers often wishing it was written in one of those languages instead for purposes of scalability. In fact, if it were started over from scratch today, I'm pretty sure the thing would overwhelmingly have support for being written in Python instead.

Damn, I shouldn't have said that. Now someone's going to want to do this TRI project in Python, and I'm going to have to get bandages for my bleeding eyes from looking at Python code.

by jaqui

we need to get what is required, what language to script in, etc hammered out before we get to many people.

right now there are 7.

we do need to get the requirements from TR as part of that, since without those, we would be working to no real purpose.

We know that discussions, TQ&A, downloads, webcasts, news, wiki/blog, storefront [ books / cds ], collaboration are wanted, but what else do they want?
what features that have been requested by members are going to be implemented, and in what order?

and the big one, which of the open source licences to use?
the gnu-gpl is, in my opinion, not an option, it's to restrictive.

by jaqui

but python, perl and php all have xslt modules to work with xml without having to code in xml.

but xml isn't hard, it's a core for markup languages. that's all it is, the base for which to base a specialised markup on.

by jaqui

in this scripting project.

I've set up a new domain, and sub domain for it with a hosting company.

I'll get a wiki or blog running on it, where we can bang out the details as soon as the dns resolves.

only those who are participating will be given the url.
[ Though the TR staffer who will be our liason with TR on it will also get the data ]

I'll also start a mailing list for the project, where participants can keep in contact through the list if desired.

The benefit of not using TR's hardware is we don't add a lot of traffic to the system, which is throwing errors enough.

by stargazerr

This is a brilliant idea Jaqui. I have spent all of this morning (however little has gone by yet) reading this thread and skipping (mentally).

I dont know as of yet which languages and open source platforms you guys are going to use, since nothing much has been decided. But I would love to help where I can.

]:)

by jaqui

welcome to TRI !!!!
:D

we don't know what the TR powers that be are going to require yet, so we can't really make any decisions on the technical aspects yet.

by apotheon

Nobody knows yet what language(s) we'll be using, whether we'll be building on any frameworks, and so on. We don't even know yet what license we'll use, though I'm hoping for CCD CopyWrite's next version.

I do know that it would be insane to make it any kind of platform-specific, or make it require anything on the client side other than a browser that handles standards-compliant markup. That's not to say there won't be CSS and Javascript involved, but they'll need to degrade gracefully.

I'm going to go put on my asbestos suit now, before Jaqui notices I mentioned Javascript.

by stargazerr

This idea of yours is brilliant ... :)

Whatever the technical aspects might be ... I would love to help. This is a great opportunity to learn and put stuff into practise.

]:)

by jaqui

that I'll push for the script to generate pages that are xhtml1.0-strict standard.
and that we can validate them error free.
even for the css used for layout..validate that also.

usefull end user documentation, simple install and configure, some things are pretty obvious as to goals to work on..

we have to pick either mysql or postgresql for the database to work with, since those are what's available. But TR doesn't use either so the correct db access data will have to be available for all database engines. [ configure that during the install stage, so only one real set of connection data is used. ]

each module will be able to work off it's own database, if so desired by site owner.
[ actually a good thing to do, so that if you have a high traffic site, it can break apart the heavier traffic area(s) into separate database engines / servers and improve the service ]

by apotheon

I'm interested in including Javascript (even perhaps AJAX) that degrades gracefully. I'm also interested in making sure that it can work with flatfile databases that are human-readable, as well, if someone wants to run it that way. In fact, it might make sense to code up a separate database-interface module. The data model should be decoupled from the rest of it anyway, for best design, so that's not really a stretch.

I'm also suddenly thinking that a remote CLI interface would be pretty damned spiff. What I wouldn't give to be able to compose my blog posts in Vim and just enter a command to have it post. Wow.

Ooh, that reminds me -- blog posts. We need a more-seamless means of being able to sync up blog posts between TR and other blogs. I'm not entirely sure how to make it "more seamless" than RSS, though, without serious security issues.

by jaqui

It hasn't ever been formally put out for public knowledge.

but I do beleive that it's 4 different engines, all MS os based.
sybase, mssql / ms server 2003 being some that I vaugely remember being mentioned

by jaqui

abstestos doesn't work..when you are in a blast furnace. ]:)

geez, next you'll want it sprinkled liberally with frontpage extentions and flash.

by jaqui

ye gads!! you mean you would actually concider using activex and vbscript?!?!

that's it, no more nice guy, time to break out the nukes.

by jaqui

this is getting bigger and bigger..

We are going to have to go after basic functionality, then add the features, or we'll get nowhere.

sqllite uses flat files, so making sure it can work with that gets the flat file functionality... partially

as to syncing blogs, that would be a combination, of server settings between both blog hosts. if they don't have the same interval for updating, then the import will be delayed to fit the export.

I do think TR set the update delay themselves.

adding support for uploading a file as a blog entry might be better than opening a console, as if the host is windows based you wouldn't have vim to work with. :P
[ os agnostic script..remember ]

by apotheon

I was just thinking of providing a server interface for a local client using SSH, or something like that. The client side configuration need not even be known to the server.

re: writing it down
Heck no. I type.

by jaqui

I thought I was pushing buttons..like you and the javascript with me. :D

by stargazerr

Javascript? Frontpage? [B]Flash???[/B]

Could you please make me smell my sock and bring me back to consciousness??

]:)

by apotheon

"[i]I thought I was pushing buttons..like you and the javascript with me.[/i]"

Tomayto, tomahto.

ActiveX and VBScript . . . that's just cruel.

by hal 9000

I'll overlook the Peer Mail pointing me to this site and arrange directly with Jay to have Beth in her Leather Suit and Boots standing by to whip you into shape. :p

Or should that have just read whip you? :O

Col ]:)

This discussion is closed to new replies.