Community
Participate
Working Groups
There is an API out there to access bulletin boards and there has been some interest in providing a ECF provider to do this. API: http://bbapi.tigris.org/
Adding Erkki since he was the originator of this idea and also holds the API ;)
The source code of the provider implementations (phpBB & vBulletin) are now available: http://bbapi.tigris.org/source/browse/bbapi/trunk/ After I work out a few issues, I'll get the simple ECF wrapper container up as well. The code quality is currently not very good, and the implementations are not complete. But I do have some old code that has more functions implemented but had a different API - I need to copy, paste & refactor that code.
I started adding support for Google Groups to the Bulletin Board API. Joshua Block has said that an API will work fine if it has 3 implementations so I've been (passively) looking for one that would be a bit different from phpBB and vBulletin and now discovered Google Groups :) Actually, another implementation I would like to do add before release would be one that uses a different protocol than HTTP -- maybe direct database access, e-mail or something like that.
The initial ECF based version is now available in the source repository: http://bbapi.tigris.org/svn/bbapi/trunk/ (http://bbapi.tigris.org/source/browse/bbapi/trunk/ for anonymous web access) The projects containing the ECF port are: org.eclipse.ecf.bb org.eclipse.ecf.bb.commons (this is for use by implementations and is separate from org.eclipse.ecf.bb only for making ecf.bb independent of org.apache.commons.httpclient) org.eclipse.ecf.provider.phpbb org.eclipse.ecf.example.bbreader (the example reader, with a bit more functionality than before) I'll also attach a Team Project Set. During porting BBAPI to ECF, I also removed some API and made some of it internal, so only the more mature parts remained as public. I added a method for getting timestamps from posts and fixed some bugs in the phpBB provider.
excellent, this looks cool!! Will look more into depth.
Created attachment 47807 [details] Team Project Set
I started using the issue tracker @ tigris.org to keep more detailed track of enchancements and bug fixes than this report here. http://bbapi.tigris.org/issues/ -- the sub-component is ecf-bb. Also, should I accept this bug here? I'm not very familiar with eclipse.org bugzilla policies / best practices -- do only commiters accept bugs or others as well?
Created attachment 47825 [details] Team Project Set Added commons-httpclient to the Team Project Set.
Example is now an RCP application (well, almost -- for some reason the new wizard doesn't show up unless I include org.eclipse.ide) based on Common Navigator and it allows to add new bulletin boards connections (with a wizard) and remove ones that are already added. The next thing to do with this example is to make the tree updating use jobs instead of doing it in the event thread.
(In reply to comment #9) > Example is now an RCP application (well, almost -- for some reason the new > wizard doesn't show up unless I include org.eclipse.ide) based on Common > Navigator and it allows to add new bulletin boards connections (with a wizard) > and remove ones that are already added. The next thing to do with this example > is to make the tree updating use jobs instead of doing it in the event thread. > Hi Chris, Peter, and Erkki, I was hoping that all four of us would be able to work with Erkki Lindpere over the next 2-3 weeks with the ultimate goal of incorporating/committing his bulletin board API contribution into ECF. I'm going to be pretty busy over the next week with Google SOC finals, doing politics with Google to get them supporting ECF, looking for work for myself, and then I'm on vacation for a few days next week (18-25)...and so can't really to help fully with the review/revision/coordination with Erkki on this API work until after 8/28...and I don't want Erkki to be left in the lurch after putting so much effort with his contribution. So would like to ask that Chris and Peter take the lead on reviewing/revising/incorporating Erkki's work if possible. If well coordinated, I don't really see that there is a tremendous amount of remaining work...and I would like to share the remaining effort among all of us...with each of us reviewing/providing feedback to Erkki (first task for all of us: getting/trying/providing feedback), and Erkki letting us all know what additional needs to be done (and letting us help him do some of that work). I think we should oordinate via this bug #150756. Erkki I assigned this bug to you...I need to check on the official procedure, but bugzilla did it so I assume it's OK :). If you don't want it assigned to you LMK and I'll change assignment. Does this seem reasonable/doable? Do all have some cycles for this over the next, say four weeks? Erkki does this sort of seem doable/appropriate for you? Thanks, Scott
Created attachment 50181 [details] Team Project Set Added org.eclipse.ecf to the Team Project Set
I've updated the code to work with the refactored ECF. IBulletinBoard renamed -> IBulletinBoardContainerAdapter org.eclipse.ecf.bb : By removing generic type parameters, the execution environment is set to F1.1 (CDC 1.1 / Foundation 1.1). Probably could be even lower, but is there a point when ECF itself requires Foundation 1.1? The other bundles are implementations & examples, so they would remain 1.5 for now -- seemingly even the API implementations can retain generic type parameters, but I haven't tested if it also works in runtime yet. I will continue the work later tonight.
Created attachment 53252 [details] Team Project Set This has the bb packages & bundles renamed to bulletinboard, includes ecf and ecf.core.identity
Created attachment 53253 [details] Team Project Set BB Reader example renamed to plural form (ecf.examples.bbreader) as per the naming conventions. Everything should now have EE set (except httpclient, but that should eventually come from Orbit, I think), F1.1,J2SE-1.4 for ecf.bulletinboard, J2SE-1.5 for everything else. Everything not meant to be API is now in *.internal.* packages and exported with x-internal. There is one problem with this though: in ecf.bulletinboard, IThread.getPoll() references an internal interface IPoll. The poll support has never gone farther than those 3 interfaces: IPoll, IPollOption and IPollVote. I currently think those interfaces are good and should be the base for any future work in supporting polls (I'd like to do that some time), but maybe I should remove the getPoll() method from IThread so it wouldn't reference an internal class? Or is there a way to make interface methods not API? Maybe a JavaDoc convention?
Also, I think this makes BBAPI ready to be moved to ECF (unless something in the list below stops that). But I've changed my opinion about the task list I sent to you guys some time ago: I think those items are not that big a deal to stop moving this to ECF now. But some stuff that is remaining that must definitely be done at least by 1.0: 1) better javadocs 2) are unit tests required? I'm not sure how that should be done, perhaps with a dummy bb implementation? But that wouldn't actually test anything interesting... 3) logging, make sure nothing is writing to system.out etc. 4) FindBugs or some other static analysis of the code? 5) fix some bugs :) 6) UI?
The extensions in ecf.examples.bbreader were broken after the renaming, now fixed.
I started refactoring the provider implementations. I'm hoping to move some of the ugly parsing code to a common base class for both phpBB & vBulletin providers. The value I see in this: 1) easier to maintain. So far the maintenance of both providers has been requiring a lot of copy&pasting. 2) easier to implement other providers. This is dubious though, as I'm basing this on two bulletin boards that are fairly similar (maybe the most similar to each other of all the bulletin boards out there) and any other impl. might be different enough not to find any of the common base classes useful. I think 1) is enough to justify this work though. When it's done I think I will publish the vBulletin provider source code as well.
Querying the * thread list of a forum * user group list * global member list and group membership lists is now mostly generic and the differences only in regular expressions and URLs. In the process, vBulletin provider now got some basic group support. But I'm unable to find a vBulletin instance where I'd get to see all the things that can be done with groups. Right now I've only managed to get a list of groups that are joinable, but no group membership info. I wonder if a pseudo group should be created for "All Users". I think vBulletin actually has this internally. Possibly phpBB too. In that case, also the distinction between IMessageAuthor and IMember could be dropped and whether the author is a registered user could be queried by asking if it belongs to a group. But actually, maybe not, there are more differences between guests and members.
(In reply to comment #12) > org.eclipse.ecf.bb : By removing generic type parameters, the execution > environment is set to F1.1 (CDC 1.1 / Foundation 1.1). Probably could be even > lower, but is there a point when ECF itself requires Foundation 1.1? I don't think it can actually be lower because your IBBObject implements IIdenitifiable, an ID has a toURI method that returns a java.net.URI which is not available in an F1.0 environment. (In reply to comment #14) > There is one problem with this though: in ecf.bulletinboard, IThread.getPoll() > references an internal interface IPoll. If it's internal and you reference it, you're going to have a source incompatibility when you move it out, and I think binary too? If you remove it nowand then add it back later, there are incompatibility problems again since all IThread implementations are broken since they don't have a getPoll() method that returns an IPoll. The only way to resolve this problem without breaking (I think) is to either have an IThread2 that extends IThread or have an IThreadExtension which you retrieve via getAdapter(Class), or not since it doesn't look like you IThread actually implements IAdaptable.. Not very elegant. I don't personally see the big deal of incompatibility...okay, it is a big deal, but the fact of the matter is that ECF's internals are being reorganized everyday or two at the moment during these last few weeks' refactoring effort in an attempt to harden things down and get the right specifications in place in our APIs. We are breaking applications today in hopes of not having ugly issues at 1.0. Since this API is provisional, implementors should expect breakage anyway, so at the end of the day, I think you should keep the getPoll() method in there.
(In reply to comment #19) Maybe the best thing then would be to remove the ".internal" package infix from the poll classes and simply mark them as experimental in JavaDoc? But I think there must anyway be methods added to the interfaces at some point, at least to the IBulletinBoardContainerAdapter. About using IAdaptable : do you think it would perhaps make sense to make IBBObject extend IAdaptable so it would be easier to add adapters if a necessity arises?
(In reply to comment #20) > Maybe the best thing then would be to remove the ".internal" package infix from > the poll classes and simply mark them as experimental in JavaDoc? I think I like this idea better. See [1] for an example of an excellent javadoc warning header. > About using IAdaptable : do you think it would perhaps make sense to make > IBBObject extend IAdaptable so it would be easier to add adapters if a > necessity arises? I think so sine the adapter pattern is so widely used in Eclipse. Even if you may have no uses for it (I am only assuming this from the fact that IBBObject does not extend IAdaptable at the moment, I could be wrong since I don't have your code checked out), I'm sure some implementors would appreciate it. [1] - http://dev.eclipse.org/viewcvs/index.cgi/platform-vcm-home/plugins/target/org.eclipse.ftp/src/org/eclipse/ftp/IClient.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
There actually seems to be a standard for marking things experimental: http://wiki.eclipse.org/index.php/Provisional_API_Guidelines#Javadoc . I used that for now, but thanks for that link, that seems like a good example too. I should look through all the public API JavaDocs soon. I'm also thinking about the fact that since particular providers might support only part of the BBAPI features (for example, NNTP doesn't have user groups nor a public list of users), is there a standard practice for handling that. I have thought of: 1) Making some methods return null for unimplemented features 2) or throw an UnsupportedOperationException 3) creating boolean functions, for example isMemberGroupsSupported(), isMemberListSupported()... but that could get ugly. 4) predict what kind of functionality might be either completely unsupported or fully supported and create different interfaces for those. for example, split IBulletinBoardContainerAdapter into interface IMemberSupport() { getMessage(ID) getMemberGroups() getMemberGroup(ID) getMembers() getMember(ID) } and interface IForumSupport() { getForums() getTopLevelForums() getForum(ID) getThread(ID) getMessage(ID) }
(In reply to comment #22) > I'm also thinking about the fact that since particular providers might support > only part of the BBAPI features (for example, NNTP doesn't have user groups nor > a public list of users), is there a standard practice for handling that. Well, I don't know if it's necessary to split out IForumSupport, but I guess the question you have to ask yourself is what is your API supposed to do? If it's to let people see a bunch of groups in which there are messages bundled up into threads, then I don't believe it's necessary since, well, that's what your API does, it should be the "root-level API container". To provide support for additional stuff, you can use the adapter pattern if you wish, which is the filetransfer API's approach. In the presence API (see IPresenceContainerAdapter), the interface provides some getSomeInterface() methods that can return null if it's not supported by the implementing provider. "Standard practice"? I would lean towards adapters since that's how it is everywhere, but if you envision more support (as many as IPCA above), then that method isn't too bad imo.
6 bbapi plugins added to ECF CVS area in org.eclipse.ecf/incubation/plugins.
