Forum OpenACS Development: social networking functionality for acs-subsite? TIP?

I've been told that I have not followed procedure with respect to adding some social networking defaults to OpenACS. Apparently, I should have asked OCT. I apologize, if the code submission offended anyone.

Here's the reasoning I used:

Default meta tags are a wanted feature:
https://openacs.org/forums/message-view?message_id=213051
https://openacs.org/forums/message-view?message_id=112612
https://openacs.org/forums/message-view?message_id=2570780

Social networking features are as relevant to OpenACS as any other UI feature.

OpenACS can run circles around much of the social networking software out there.

By adding the minimum recommended meta tags of the open standard OpenGraph protocol, OpenACS might be visible to a much larger market audience.

The code doesn't modify any existing functionality.

It seems like a win-win: OpenACS + social networking

A TIP seemed unnecessary.

The code modified www/blank-master.tcl file, and added a template to acs-subsite/lib/share-bar

acs-subsite seems the most appropriate for sharing social networking features instead of having them scoped per package. Should the code be moved to another package?

cheers,

Torben

1. http://fisheye.openacs.org/browse/OpenACS/openacs-4/packages/acs-subsite/lib/share-bar.adp?r=HEAD
2. http://fisheye.openacs.org/browse/OpenACS/openacs-4/packages/acs-subsite/lib/share-bar.tcl?r=HEAD
3. http://fisheye.openacs.org/browse/OpenACS/openacs-4/www/blank-master.tcl?r1=1.50&r2=1.48

That rule holds for me, for DaveB, Emmanuelle, Gustav - it holds for all OCT members.

If OCT members are required to TIP for such things, why in hell do you imagine that *YOU* are so special that *YOU* don't need to TIP???

Please explain your reasoning as to why you're so much smarter than those of us on the OCT that you get to exempt yourself from the rules that the OCT imposes upon itself.

Also note that since you're not an OCT member, you can't submit a TIP on your own, but rather must get an OCT member to endorse it.

You might want to drop the "I don't have to TIP because I don't want to" attitude ...

"acs-subsite seems the most appropriate for sharing social networking features instead of having them scoped per package. Should the code be moved to another package?"

You're not even sure you're doing this in the right place, and *still* you argue that you don't need to follow the same TIP process that OCT members like myself must follow?

The TIP rules, as I understand them, don't have this requirement[1].

OK, fine, we relaxed that requirement (it was discussed in the beginning).

Great, you get to start a TIP.

It doesn't mean you get to hack core without TIP'ing.

I don't think I'm special. I really didn't think this social networking thing was worth distracting the OCT from other work. It seems like a very small, incrementally positive thing. Nothing more. As an afterthought, based on your reaction, I'm wondering if there is some kind of MIT/facebooky vs. MIT.alt feud thing motivating this dialog.

Oh, good grief, Torben, stuff a sock in the conspiracy theory orifice.

You've been told you need to TIP before adding functionality to core.

This is not new.

I'm fairly confident, yet remain open-minded and do not assume to understand all core-developer issues

This statement alone justifies our policy that changes of this sort require a TIP.

Create or show me the package, and I'll move it there.

That's not how it works, Torben.

Remove your commits. We'll discuss afterwards if you choose to TIP.

you wrote: "You have a personal habit of breaking stuff in core and others have had to spend time fixing it in the past ..."

I supposed it could be viewed that way. I have mistakenly broken core functionality from inadvertently breaking package.info XML standards so the core couldn't read it --twice.

Yet, to my defense, I've also taken initiative to help fix things that were inadvertently broken by code improvements from others, digging in where I had little understanding. The outcomes were positive, even if my own net contribution was only in helping others to see the problem and motivating them to fix it.

I will TIP all core changes, including the one in dispute. Sorry for the confusion on removing the code.. I'm working on it..

For the record, the share bar is at (and soon to be removed from) packages/acs-subsite/lib/share-bar

They aren't active by default, out of consideration for use cases like this.

The OpenGraph meta tags are active by default, but they do not leak any more information than is already available from the same page content/resource_url: title, favicon.ico, domain, url.

Anyway, they're on their way out.. into a package.. maybe facebook-api, ecommerce, a new package? anyway..

cheers,

Torben

My current understanding is that /lib adp includes cannot be shared across packages within the ACS templating system, as a security measure etc. If true, then acs-subsite seems the most appropriate location, since the include is relevant to the master templates. If there's a better way, please let me know.

The meta_defaults provide default meta tag values if unique ones are not specified. The defaults should be called just prior to page rendering (to provide the greatest opportunity for setting by page related calls). The blank-master seems the most logical place. They could be controlled by a parameter, and not utilized by default.

One specific use has been to inherit from subsite, and in fact the APM has been altered to accomodate the specific case of a package that somehow implements subsite semantics, either of its own accord, or thru inheriting from another which (somehow) implements subsite semantics.

For an example of this, see: layout-manager and layout-managed-subsite.

If you play with this, you might find there is a whole new layer or set of layers that make it so that alterations don't need to be in core.

-Jim