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

Hi all,

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

Collapse
Posted by Dave Bauer on
Torben,

Thanks for your contribution. I'll check out the code as many public installs of OpenACS could use this type of feature.

Traditionally, changes that affect every page through changes in blank-master should be discussed with the OCT to get feedback and advice. The OCT is responsible for maintaining all core packages, and individual members will take on specific packages at various times. For example, I review all changes to acs-content-repository for historical reasons.

In this case, it might be possible to create the share-bar as an optional feature that can be used by any subsite package. There have been many changes with package type extension and template inheritance that might change the best way to implement this kind of feature.

Collapse
Posted by Don Baccus on
Torben, you've been around for a long time, and you know full well that changes such as this to core require a TIP.

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?

Hi Don,

It's a stressful time, isn't it?

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.

You wrote: "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."

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

You wrote: "You're not even sure you're doing this in the right place.."

I'm fairly confident, yet remain open-minded and do not assume to understand all core-developer issues. If others are working on social networking features, I'm for moving it into a social-networking package. Create or show me the package, and I'll move it there.

1. TIP rules: https://openacs.org/forums/message-view?message_id=115576

Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Don Baccus on
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.

1. TIP'ing is our process, well established, and no secret.

2. You have a personal habit of breaking stuff in core and others have had to spend time fixing it in the past ... while this doesn't mean we'll be more strict in our requiring you to TIP than we are on ourselves, it does mean that your thinking that we'll be *more* lax than we are on ourselves or others just ain't going to happen.

Hi Don,

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..

Collapse
Posted by Don Baccus on
Note that my pointing out that this change requires a TIP has NOTHING to do with the merit of the code itself (though it does seem that answering the "is this the right place to do this?" question would logically come *before* committing a change).

It is about process, and you are not exempt.

Collapse
Posted by Don Baccus on
Please remove your commits for the time being, until we can discuss the best way to implement this feature.
I don't want to get involved in the process discussion, but maybe I can defuse the tone of this thread a bit with some real user feedback on the commit and additional support for reverting this as a core addition and resubmitting it in a dedicated package.

I appreciate the contribution Torben, but these social bookmarking additions really only work on publicly available resources. Sharing via delicious/digg/twitter/facebook/etc. doesn't work for an installation like ours where 95% of the subsites are only accessible to registered users. In fact someone using the links you added to core on our site might actually result in them sharing the title and url of potentially sensitive resources on these very public sites (it is reasonable for them to assume that if we included them in our installation they should be used). Again, this speaks for it being optional, off by default and in a dedicated package.

On a related note: I think Gustaf has added something similar to XoWiki pages, but included it as an option within that package.

Hi Carl,

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

Collapse
Posted by Don Baccus on
Not ecommerce ... it should be something along the lines of a utility package, no?
Don, yeah, not ecommerce. I moved the share-bar there temporarily, until I compose a TIP.
Collapse
Posted by Jim Lynch on
On moving the commits to an existing package...

ecommerce seems completely off the topic, and additionally it's not a complete working package, as it has code with example formulas where a programmer would necessarily come in and have to read the code. It also seems to be a singleton, where it would be more useful to have more than one.

facebook-api is not quite on topic either, it's about an openacs instance talking to facebook, and adding features to subsite doesn't seem germain to that functionality.

So, I'd say a new non-core package is what is called for here.

A question: is it possible to get what you're trying to add here to work without altering any core package? I mean completely, with no compromise.

If not, what are the compromises?

-Jim

Hi Jim,

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.

Hi Torben,

Includelets located in lib/ directories are meant to be shared. To use an includelet from another package you just need to provide the full path from the site root to the includelet.

for example: <include src="/packages/$package/lib/$includelet">

Collapse
Posted by Jim Lynch on
In newer versions of openacs, there is an added feature which implements "weak inheritance of a package", which at least allows templates in one package (the "inherited" package) to be used from another (the "inheriting" package).

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

Thank you, Jim. I like avoiding the acs-core when possible (unless appropriate).

Given the utility of Layout Manager, it is probably going to be part of acs-core. I like the idea.

Hopefully someone with existing experience and knowledge of these features will implement social networking. Realistically, due to other project priorities, I will not be pursuing this for a couple of years.

Thank you, Emmanuelle.