[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] planning for ECF fall release
|
Hi Wim,
On 9/23/2011 4:21 AM, Wim Jongman wrote:
Hi,
We make strong progress with the newsreader contribution but we must
decide first if this is going to be included in ECF or in another
project. I would not want the newsreader to be some example project
that utilizes an ECF NNTP container.
Why? I agree that the Salvo newsreader could be a distinct
project...if there is bandwidth available for running/doing a completely
separate project, but even in that case I think it would still make
sense to have dependencies to ECF apis (as other Eclipse projects
do)...as long as those APIs are appropriately abstracted and in keeping
with the 'ECF family' of APIs (see below).
The plan is to make the underlying data source independent. So it
could be NNTP but it could also be any other post/reply structure.
The post/reply pattern can be found in many communication:
NNTP servers
Forum Software
Mailing Lists (mailman)
Bug reports
.....
It would be nice if this post/reply pattern could be made abstract.
For this the ECF container structure would be a nice way to go right?
Yes, I think so. For everyone's info...many moons ago, there was some
work on an abstract 'bulletin board' api...and it's still in the
incubation area for ECF:
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles
see particularly the o.e.e.bulletinboard project/bundle (api) and then
the supporting (o.e.e.bulletinboard.commons) and providers...i.e.
o.e.e.provider.phpbb and vbulletin, I think.
This was an attempt to create an abstract bulletinboard API...which
would/could share some things with what you are calling a 'post/reply'
api...I think.
I am not the original author of this API (at the moment, I can't
remember who did contribute it)...and it's been some time since I looked
at it (and many things have happened with ECF since then...particularly
around remote services, etc).
AbstractPostReplyContainer
NNTPContainer extends AbstractPostReplyContainer
I would like to see the API cleanly separated from the container types
(and therefore from the protocols)...e.g.
IPostReplyContainerAdapter (entry point adapter for access to PostReply
api).
But there's nothing about your approach that conflicts with what I'm
saying...I'm just suggesting greater separation (by using interfaces for
API).
Thanks,
Scott
