[campsite-dev] Phorum integration - Newscoop Development Discussions on Sourcefabric Forum

import

Well, Phorum integration isnt quite as easy as planned, but its getting
there. Basically the backend Phorum database API isnt so good. It
relies on global variables to "pass" parameters, and a lot of the code
necessary to create messages & forums lies outside of this backend
database layer.

So I've started creating an OO API to Phorum (lets call it OO-Phorum)
that is much easier to use and things are going well with that. Right
now some parts of Phorum are re-implemented in the classes, and in
some cases I call the Phorum API.

But I have now run into an issue with how to deal with the fact that
users in phorum are different from users in Campsite. Phorum has its
own user table, which is used all over the place in the backend (via
those lovely global variables), and we have our own user table.

An example of why we need to fix this is so that the Campsite
subscriber who posts a comment to an article has his name & email show
up with the comment.

So there are a number of ways I can think of that might solve this problem:

1) Whenever a message is posted, check if the Campsite user exists in
the Phorum table. If not, create the user, then post the message.
This mechanism could also be used to update the Phorum user table (for
example, if a user changes his email address).

2) Dont use the backend Phorum API at all (which relies on Phorum
users existing), but instead reimplement all the functionality we need
inside OO-Phorum. Implement an API that allows you to plugin
different user implementations so that OO-Phorum doesnt care which one
it is using. The drawback to this technique is that the standard
Phorum web interface probably wont work since the Phorum code wouldnt
be able to find any Phorum users.

3) Copy the Campsite users into the Phorum table and keep the two
tables in sync all the time (yuk).

If we dont care about the standard Phorum web interface then #2 is
better. But since that's the reason we are using Phorum in the first
place, its a pretty hard sell. Smile

But if we were able to convince the
Phorum developers to move to the OO interface, then we would
eventually get what we wanted.

But I'm guessing we'll have to go with #1 unless someone has a better idea.

Comments?

- Paul

import

IMHO the ideal solution would be 2 - rewriting Phorum API and the Phorum itself. But I suppose that's not possible now so the only "quick fix" is 1.

Mugur

Paul Baranowski wrote: Well, Phorum integration isnt quite as easy as planned, but its getting
there. Basically the backend Phorum database API isnt so good. It
relies on global variables to "pass" parameters, and a lot of the code
necessary to create messages & forums lies outside of this backend
database layer.

So I've started creating an OO API to Phorum (lets call it OO-Phorum)
that is much easier to use and things are going well with that. Right
now some parts of Phorum are re-implemented in the classes, and in
some cases I call the Phorum API.

But I have now run into an issue with how to deal with the fact that
users in phorum are different from users in Campsite. Phorum has its
own user table, which is used all over the place in the backend (via
those lovely global variables), and we have our own user table.

An example of why we need to fix this is so that the Campsite
subscriber who posts a comment to an article has his name & email show
up with the comment.

So there are a number of ways I can think of that might solve this problem:

1) Whenever a message is posted, check if the Campsite user exists in
the Phorum table. If not, create the user, then post the message.
This mechanism could also be used to update the Phorum user table (for
example, if a user changes his email address).

2) Dont use the backend Phorum API at all (which relies on Phorum
users existing), but instead reimplement all the functionality we need
inside OO-Phorum. Implement an API that allows you to plugin
different user implementations so that OO-Phorum doesnt care which one
it is using. The drawback to this technique is that the standard
Phorum web interface probably wont work since the Phorum code wouldnt
be able to find any Phorum users.

3) Copy the Campsite users into the Phorum table and keep the two
tables in sync all the time (yuk).

If we dont care about the standard Phorum web interface then #2 is
better. But since that's the reason we are using Phorum in the first
place, its a pretty hard sell. Smile

But if we were able to convince the
Phorum developers to move to the OO interface, then we would
eventually get what we wanted.

But I'm guessing we'll have to go with #1 unless someone has a better idea.

Comments?

- Paul

---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2

import

At 12:16 20.04.2006, you wrote:
>2) Dont use the backend Phorum API at all (which relies on Phorum
>users existing), but instead reimplement all the functionality we need
>inside OO-Phorum. Implement an API that allows you to plugin
>different user implementations so that OO-Phorum doesnt care which one
>it is using. The drawback to this technique is that the standard
>Phorum web interface probably wont work since the Phorum code wouldnt
>be able to find any Phorum users.

for the flat article comments this might be the easiest way... if
this is about the full threaded forum functionality, then i think it
would be too much work.

Micz Flor - micz@mi.cz

content and media development http://mi.cz
--------------------------------------------------------
http://www.campware.org -- http://www.suemi.de
http://www.redaktionundalltag.de
--------------------------------------------------------

import

At 12:16 20.04.2006, you wrote:
>1) Whenever a message is posted, check if the Campsite user exists in
>the Phorum table. If not, create the user, then post the message.
>This mechanism could also be used to update the Phorum user table (for
>example, if a user changes his email address).

how would you *check* if the user exists? is this only the case if
the user is logged in? or would you depend this on the name given in
the phorum form? this might be weird, since somebody might have the
name 'paul' registered - and another paul will post something and
this gets automatically assigned to the registered paul?

i would suggest to do this check only if user is logged in. is that possible?

Micz Flor - micz@mi.cz

content and media development http://mi.cz
--------------------------------------------------------
http://www.campware.org -- http://www.suemi.de
http://www.redaktionundalltag.de
--------------------------------------------------------

import

Hi folks,

One question and one suggestion:

(1) QUESTION:

On 4/20/06, Micz Flor wrote:
> At 12:16 20.04.2006, you wrote:
> >1) Whenever a message is posted, check if the Campsite user exists in
> >the Phorum table. If not, create the user, then post the message.
> >This mechanism could also be used to update the Phorum user table (for
> >example, if a user changes his email address).
>
> how would you *check* if the user exists? is this only the case if
> the user is logged in? or would you depend this on the name given in
> the phorum form? this might be weird, since somebody might have the
> name 'paul' registered - and another paul will post something and
> this gets automatically assigned to the registered paul?

I'm new to the code, but why would this even be an issue? I assume
both Phorum and Campsite have a unique username field that he'd check
of off? What does being logged in have to do with it?

(2) SUGGESTION:

Why not just jimmy up a SQL VIEW to accomplish all this? Assuming
Phorum uses Mysql as a backend, make the Phorum user table a VIEW of
the Campsite user table. This, obviously, will only work if Phorum
and Campsite both use the same database. However, VIEWs more or less
work on any SQL backend, so that's a plus. Unless Phorum is doing
something real weird underneath, this should work.

Peter

import

At this point I am very unhapy with the design. If you imagine server
with 20 campsite databases, 20 banner rotator databases, 20 phorum
databases... Where this thing ends? It is awfull to maintain.

In my opinion campsite should make the step to concentrate all apps to
one huge database for each instance.
However last time I upgraded campsite on a server that holded other than
campsite tables in campsite database, the upgrade was not proper. I hope
it is fixed now.

Anyways. I would love to have one database, inside all campsite tables
with cs_ prefix, phpadsnew with some prefix and phorum with some prefix.

I also call for rules that should contain something like "the prefix for
the module is mod__ in which case the phorum
would use tables with prefix mod_phorum_

Next depends on the developers. If we wish to let phorum people to
develop their app and simply use it, I vote for creating only user sync
depending on APIs. If we want to maintain campsite version of phorum, I
would let them to share user table.

And I believe the best way to integrate phorum to campsite is to look at
its API and create campsite module called Phorum_connector, that will
expand Admin interface features and proper sync methods.

This will allow later creation of PHPBB_connector or something and keeps
the code clean and campsite a nice application.

Ondra

On Thu, 2006-04-20 at 12:04 -0400, Peter Hartman wrote:
> Hi folks,
>
> One question and one suggestion:
>
> (1) QUESTION:
>
> On 4/20/06, Micz Flor wrote:
> > At 12:16 20.04.2006, you wrote:
> > >1) Whenever a message is posted, check if the Campsite user exists in
> > >the Phorum table. If not, create the user, then post the message.
> > >This mechanism could also be used to update the Phorum user table (for
> > >example, if a user changes his email address).
> >
> > how would you *check* if the user exists? is this only the case if
> > the user is logged in? or would you depend this on the name given in
> > the phorum form? this might be weird, since somebody might have the
> > name 'paul' registered - and another paul will post something and
> > this gets automatically assigned to the registered paul?
>
> I'm new to the code, but why would this even be an issue? I assume
> both Phorum and Campsite have a unique username field that he'd check
> of off? What does being logged in have to do with it?
>
>
> (2) SUGGESTION:
>
> Why not just jimmy up a SQL VIEW to accomplish all this? Assuming
> Phorum uses Mysql as a backend, make the Phorum user table a VIEW of
> the Campsite user table. This, obviously, will only work if Phorum
> and Campsite both use the same database. However, VIEWs more or less
> work on any SQL backend, so that's a plus. Unless Phorum is doing
> something real weird underneath, this should work.
>
> Peter

import

On 4/20/06, Ondra Koutek wrote:
> At this point I am very unhapy with the design. If you imagine server
> with 20 campsite databases, 20 banner rotator databases, 20 phorum
> databases... Where this thing ends? It is awfull to maintain.

The phorum tables *are* stored in the same database as Campsite. What
I was saying is that there are two different user *tables*.

> Anyways. I would love to have one database, inside all campsite tables
> with cs_ prefix, phpadsnew with some prefix and phorum with some prefix.

Coming in 3.0.

> Next depends on the developers. If we wish to let phorum people to
> develop their app and simply use it, I vote for creating only user sync
> depending on APIs. If we want to maintain campsite version of phorum, I
> would let them to share user table.
>
> And I believe the best way to integrate phorum to campsite is to look at
> its API and create campsite module called Phorum_connector, that will
> expand Admin interface features and proper sync methods.

Heh, you havent seen the Phorum code. If I could do that, I would.
It would be wonderful if the API provided by Phorum was clean, robust,
documented, didnt rely on global variables to pass parameters, and
didnt have the code scattered across many files. But since it is that
way, we have to get down and dirty, which is why I was asking the
question in the first place.

> This will allow later creation of PHPBB_connector or something and keeps
> the code clean and campsite a nice application.

PhpBB has similar problems as Phorum in its design.

- Paul

import

Other things - good.

About phorum. I believe to following facts:
1) we want to have campsite clean
2) All external parts of campsite should talk to campsite through
campsite API
3) External parts are the external problem.

next if I plan development, I simply follow my app model.
If external part does not have something I desperately need like API and
I still wish to use the external app, my way would be to develop API for
the external part, or choose another external part.

Anything other calls for future campsite cleaning and problems.

but I might be wrong.

Ondra

On Thu, 2006-04-20 at 17:40 +0100, Paul Baranowski wrote:
> Heh, you havent seen the Phorum code. If I could do that, I would.
> It would be wonderful if the API provided by Phorum was clean, robust,
> documented, didnt rely on global variables to pass parameters, and
> didnt have the code scattered across many files. But since it is that
> way, we have to get down and dirty, which is why I was asking the
> question in the first place.

import

On 4/20/06, Ondra Koutek wrote:
> Other things - good.
>
> About phorum. I believe to following facts:
> 1) we want to have campsite clean
> 2) All external parts of campsite should talk to campsite through
> campsite API
> 3) External parts are the external problem.
>
> next if I plan development, I simply follow my app model.
> If external part does not have something I desperately need like API and
> I still wish to use the external app, my way would be to develop API for
> the external part, or choose another external part.

Yes, in this respect we have similar minds - this is exactly what we
are doing: developing a nice OO API to the Phorum code.

- Paul

Howdy, Stranger!

Categories

Poll

Top Posters