× Warning! This forum is in archival status. New contributions may not work.
[campsite-dev] Phorum integration
  • 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
  • 8 Comments sorted by
  • 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
  • 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
    --------------------------------------------------------
  • 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
    --------------------------------------------------------
  • 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
  • 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
  • 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
  • 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.
  • 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