Jive

Discussions

TSS feedback: Jive

  1. Jive (18 messages)

    Ok. There is a need for redesiging the overall look and feel of TSS. But, for discussion forums, why not use Jive?
    Rickard - do you see any serious faults with Jive? I love the Jive forums and it has most of the features that Gene suggested in a different post.

    Just curious. I would love to see Polls though.

    Threaded Messages (18)

  2. Jive[ Go to top ]

    Hi Sunil,

       Thanks for your suggestion. When TSS was first written there were no open source discussion forum software available. Now it seems we have choices, however we still have an existing infrastructure that works for us.

       The main problem with using an external piece is its integration with our own system. Can we use a common user identity with Jive? Will we have enough control? Is it good enough to throw out are own stuff?

    Things like that. What do you think?

    Floyd
  3. Jive[ Go to top ]

    Floyd,
    The last time I took a good look at Jive, it was open source and free. You can extend jive to integrate with existing systems. User Identity integration is one of the things that could be very easily done in Jive.

    Well, that said... I just took a look at the current jive webside www.jivesoftware.com and it is not free anymore. It is probably open source, but not in a GNU way. But, i dont think it is that expensive tho.

    Anyways, when redisigning the discussion forums, I strongly suggest evaluating Jive. My 2c.

    Regards
    Sunil
  4. Jive[ Go to top ]

      Hi,

      I'm not sure if my question is relevant to this thread but i'm a newbie to EJB and would like to create a discussion forum based on the EJB architecture. Any general guidelines or suggestions how i can make use of Jive and convert it into EJB architecture? I have browsed through the Jive code and realise they wrote some classes and interfaces related to Cache...if now i'm using EJB, would it mean i can totally do away with these Cache classes since the EJB container provides such capabilities? And what kind of changes would arise if i had a database structure different from that of Jive?

      Please help :)
  5. Jive[ Go to top ]

    Hi Floyd and Sunil,

    The forum that runs on Sun's developer site is using jive for the last while now. They took jive and integrated it into their application. There is one login for the entire site. Here is a link to the article sun wrote on integrating jive with the rest of their developer site:
    http://developer.java.sun.com/developer/technicalArticles/javaopensource/jive/

    Hope that gives you some ideas. Unfortunately jive isn't free anymore, unless it is used for non-profit. I'm sure the guys at Jive would love to be able to say that their application runs the forums at TSS as well. ;-)

    Cheers,
    rick
  6. Jive[ Go to top ]

    The main problem with using an external piece is its

    > integration with our own system. Can we use a common user
    > identity with Jive?

    Yes, the user system and authentication layer is fully pluggable. Jive Forums Enterprise also includes a module to read data from LDAP.

    > Will we have enough control?

    Jive has a very rich API that allows for very powerful control over data. For example, displaying something like "the messages created in the last 15 days by user XYZ, sorted in descending order" only takes 3 lines of Java code. Further, the source code is open and modifiable if you need to implement custom features.

    > Is it good enough to throw out are own stuff?

    Build or buy is always a valid question. However, some of the truly advanced features of Jive are hard to justify building internally. For example, the stats package (demo at http://www.jivesoftware.com/jive/stats), email and NNTP integration, spell checking, etc, etc. Jive is also being used on some of the largest communities on the web, so it is rather well tested.

    Of course, we'd also be happy to offer TSS a free copy of Jive. All of us at Jive Software love the site, and it would be great to see some more advanced forum features.

    Regards,
    -Matt
    Jive Software
  7. Jive[ Go to top ]

    Hi Sunil!

    Sorry for the late response. I have looked through Jive, and as others pointed out it's not really OpenSource anymore and hence not *that* interesting.

    Nevertheless, there are bigger issues. I am not at all impressed with the overall architecture and design of Jive. I haven't seen the Jive 2.0 architecture, but unless it's a complete rearchitecturing I don't see much I like there. Sorry.

    I'm in the process of rewriting the current TSS codebase, which will be based on EJB, but will also be using other interesting things such as JSP caching and taglib skinning. When we toss Lucene into the picture, it gets even more interesting. This has a rather long timeframe, but will provide an excellent base for a portal/community site such as TSS.

    It is our intent to eventually OpenSource the whole thing, or parts of it. One step at a time though.

    regards,
      Rickard
  8. Jive[ Go to top ]

    Hi Rickard,

    Are you planning on writing the caching system from scratch, or do you think you'd use an open source implementation, like OpenSymphony. Also I do have another question if you don't mind... what is taglib skinning? I've never heard of it. Maybe you could point me in the right direction?

    Also I completely agree with you on the architecture of jive, and I believe that it has not been changed for 2.0.

    Cheers,
    rick
  9. Jive[ Go to top ]

    Rick,

    The caching will be in two levels: EJB and JSP. EJB caching will be through EntityBeans, nothing strange there. JSP caching is done through OpenSymphony's OSCache, yes.

    Re: Taglib skinning. I just meant that the skins will make heavy use of taglibs in order to be easily changeable. The code will be in taglibs (from WebWork) and actions, so that you can switch skins without having to rewrite any of that.

    Re: Jive 2.0, yes I just downloaded the basic stuff and browsed the Javadocs. Not impressed. Terrible even. Ah well. Until I've written a better one talk is cheap ;-)

    /Rickard
  10. Jive[ Go to top ]

    Rickard,

    Re: Taglib skinning. Ah!! I got ya now. Good idea ;-)

    Thanks,
    rick
  11. Jive -> Meinds?[ Go to top ]

    Rickard,

    It seems you're one of the project admins of Meinds

    <quote-from-homepage>
    Powerful Java based forum/messaging/information software. First version is based on code from Jive 1.2.4.
    <quote-from-homepage>

    Is it stale? Abandoned?

    -Aslak
  12. Jive -> Meinds?[ Go to top ]

    Aslak,

    I helped start the Meinds project when I was at my former job, since we needed a portal thingy. Now I'm *building* a portal thingy, so no need for it. Others may continue on Meinds, of course, but I won't.

    /Rickard
  13. Jive[ Go to top ]

    Hey all,

    I thought I'd post a note as one of the Jive developers.

    First, yes, the current versions of Jive are Developer Source and not Open Source. This means the source code is open, but you must purchase a license for commercial deployments. This is quite simply a business necessity.

    > Re: Jive 2.0, yes I just downloaded the basic stuff
    > and browsed the Javadocs. Not impressed. Terrible even.
    > Ah well. Until I've written a better one talk is
    > cheap ;-)

    Well, we'd offer friendly disagreement. :) Praise of Jive's architecture has been nearly universal, and we've even had many reports of Jive being taught in university classes as an example of good Java design. The thousands of Jive implementations back this up, from Sun to JBoss.org. You simply won't find a more robust, scalable, customizable, and feature-rich forum product out there. Rickard -- care to back up your claims?

    Regards,
    Matt
  14. Jive[ Go to top ]

    Matt,

    Heh, I figured you would reply ;-) I am fully aware that Jive is working very well, and that you have had success with it in many places. No doubt about that.

    Still, as I go through the API's I see many design problems that should be fixed. When I said "terrible" most other programmers I know would probably have said "pretty decent" so it aint *that* bad ;-)

    No, I have no intent on backing up my claims. That would take a lot of time, and we would probably only be arguing ourselves to death over different design decisions. I instead intend to write a forum the way I believe it should be done, and then we can compare. Much more fair and constructive, don't you think ;-) As I said, until I've done it "words are cheap and plenty". 'nuff talk.

    /Rickard
  15. Discussion Component[ Go to top ]

    Hi all,

    before I began with my own EJB discussion component, I also looked at Jive 1.2.4 (Until this version Jive is BSD-like-based Open-Source).But because Jive does not use CMP-EJB (at least this version) and too complicated, I decided to build my own for my OpenUSS project. Like Tan Jasmine said: All the cache classes are useless in CMP-EJB.

    Now I have implemented a simple EJB, CMP based discussion component, which I developed separately from other OpenUSS-Components (I call this Extension "stand-alone" Component "discussion"). After developing this discussion component, I use some integration code (inheritance, etc.
    "discussionfoundation") to plug this in my OpenUSS Foundation Component.

    What I see until now are:

    1) Reuse of the functionality (EJB) is the most important thing.
    - Define the EJB discussion component only as "a discussion
    component" and don't put the whole user authorization codes bla ba within this component (like what Jive has done). Because normally the system you use already has this (simple + integration).
    - Use String to put the userId (simple), so everyone can expand this.

    2) Reuse of the presentation layer (JSP, Servlet, etc.) is
    nice but not that important, especially if you have to integrate that component at your own system. I like to use XMLC, others like to use WebWork, etc. (not necessary).

    I think, the best design of a component is the simplest design. If you cannot explain the design of your component within 5 minutes, than it's just too complicated (XP) ;-)

    I'm really interested in developing a real good and simple
    Open-Source-, EJB (CMP)-based stand-alone discussion component. If TSS wants to implement such an Open-Source discussion component, which is simple enough to integrate with other systems, I'll join you. I think, we all agree it's useless to develop the whole things again and again ;-)

    Best regards,
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
    E-Mail : dewanto@uni-muenster.de
    ICQ : 39343280
    ---------------------------------------------------
  16. Discussion Component[ Go to top ]

    I forget to mention that all of the OpenUSS EJB components (discussion, etc.) are open-source (GPL license).

    Thanks,
    Lofi.
  17. Discussion Component[ Go to top ]

    I assume that you are aware of the drawbacks of using GPL for components?

    You may want to consider LGPL, unless you really want anyone that uses your component to make their whole app GPL.

    /Rickard

  18. Discussion Component[ Go to top ]

    Hi Rickard,

    <quote>
    I assume that you are aware of the drawbacks of using GPL for components?
    </quote>
    Yes :-( It's not my decision to use GPL. At the moment I try to persuade the "right people" for changing OpenUSS license into LGPL.

    <quote>
    I agree with you on all points, and yes, the forum components in TSS will be EJB-CMP-ish and highly decoupled. I say CMP-ish, since they will be written using CMP-style, i.e. abstract get/set's, but will use delegated DAO's for persistence so from a container point of view they are BMP's. This strategy pattern allows for pretty much any kind of persistence manager to be easily plugged in.
    </quote>
    This sounds great! and if you want to make this component open source, I can join you. I'm also planning to extend the capabilities of my discusion component (like notification and search) and this is a waste of time if I know I can use and simply integrate your component ;-). I can make another EJB components like WhoIsOnline, etc... Please tell me, if you are planning this.

    <quote>
    Reuse of the actual presentation layer may not be useful, but it depends quite a lot on how it has been written. The new TSS JSP's will only contain very simple tags and use CSS for all the layout/graphics design issues. So, change a CSS file and you have a brand new portal look&feel. Also, it is very important to be able to reuse code from the presentation layer since you may want different skins to behave identically, and also not write the same code over and over.
    </quote>
    Surely this is useful for its own system, but not much for the integration with other systems. You are lucky, because you can use CSS ;-) OpenUSS cannot use this because many of our students only have e.g. IE 3 (without CSS) ;-). Also Netscape 4.7 sometimes has problems with CSS pages. I think for the most TSS user it is no problem, because all the developers can afford to have better browsers,right
    ;-). Have you tried CSS pages with PDAs (Palm, CE)? Someone knows this?

    Best regards,
    Lofi.

  19. Discussion Component[ Go to top ]

    Lofi,

    I agree with you on all points, and yes, the forum components in TSS will be EJB-CMP-ish and highly decoupled. I say CMP-ish, since they will be written using CMP-style, i.e. abstract get/set's, but will use delegated DAO's for persistence so from a container point of view they are BMP's. This strategy pattern allows for pretty much any kind of persistence manager to be easily plugged in.

    Reuse of the actual presentation layer may not be useful, but it depends quite a lot on how it has been written. The new TSS JSP's will only contain very simple tags and use CSS for all the layout/graphics design issues. So, change a CSS file and you have a brand new portal look&feel. Also, it is very important to be able to reuse code from the presentation layer since you may want different skins to behave identically, and also not write the same code over and over.

    /Rickard