[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] GSOC 2012 Enhancing Eclipse Salvo NewsReader
|
I guess that will work.. I don't think it is a problem to cast because on that level you should know the implementation details. Is there a way to use generics to avoid casting? Not important now, we can always fix it later.
On Wed, Jul 11, 2012 at 10:24 AM, tishan pubudu kanishka dahanayakage
<dtishanpubudu@xxxxxxxxx> wrote:
Wim,
When implementing new abstract model I introduced a new class INNTPSSF holding protocol specific methods of SSF and ISSF with generic functionality. So when we return ISSF to for example NewSweverConnectionWizard then we have to always cast it before using its functionality. So I started using <protocoSpecific>SSF inside <protocolSpecific>Container. As an example inside connect().
On Wed, Jul 11, 2012 at 1:32 PM, Wim Jongman
<wim.jongman@xxxxxxxxx> wrote:
Yes, return the SSF object.On Wed, Jul 11, 2012 at 6:17 AM, tishan pubudu kanishka dahanayakage
<dtishanpubudu@xxxxxxxxx> wrote:
Hi,
On Wed, Jul 11, 2012 at 1:14 AM, Wim Jongman
<wim.jongman@xxxxxxxxx> wrote:
Hi,
I agree with the direction and the comments.
To understand the last part. The question is to put the API in the specialized container (inheritance) or to let the API return the specialized class (composition) correct?
yes. You are correct Wim. Specialized classes means as an example ServerStoreFacade.
Regards,
Wim
On Tue, Jul 10, 2012 at 8:28 PM, tishan pubudu kanishka dahanayakage
<dtishanpubudu@xxxxxxxxx> wrote:
Hi Scott,
Thanks for replying.
On Tue, Jul 10, 2012 at 10:36 PM, Scott Lewis
<slewis@xxxxxxxxxxxxx> wrote:
Hi Tishan,
A couple of quick comments. Unfortunately, I don't have lots of
time at the moment...but if you wish to talk/discuss further then
let me know.
On 7/9/2012 11:13 AM, tishan pubudu kanishka dahanayakage wrote:
Hi all,
I have
completed the abstract model(org.eclipse.ecf.channel.model) and
protocol independent
adapter(org.eclipse.ecf.channel.IChannelContainerAdaptor). Hope
you went through it. Each protocol dependent model will depend
on channel.model. Two significant model classes are INewsSource
and IMessage. They are abstracted type of INewsGroup and
IArticle. Also IServer, IserverStoreFacade, IServerConnection
etc were taken up to abstract layer and their protocol specific
version is named INNTPServer, INNTPServerStoreFacade, etc
respectively.
Currently I am moving
the salvo implementation to new API. I am facing some
complications when doing that.
1. creating the
container
Lets
considering NewNewsServerWizard in Salvo.ui. In all most all
other implementations (xmpp, msn) the container is created
inside the init() method. But in this particular case I cant
create the container like that because I dont know the container
type beforehand and so cant pass the ID/containerTypeDescription
to containerFactory. One solution that comes to my mind is to
write some code to process the url (fetched through ui)and then
figure out the ID/containerTypeDescription.
I would recommend simply waiting until the wizard finish() to create
the container instance. If you want to have the wizard figure out
from the url (or something else from the UI input)...then that seems
fine/good to me.
Ok got the point. Harshan also pointed out the same thing when I had a chat with him.
2. Invoking protocol
specific implementation.
After
creating the container we can get the generic functionality
through getAdapter() and invoke them. For this to transfer some
relevant data(Newsgroup/Foum name, Server)I introduced
ITranactioncontext. iIs it ok?
Typically...for containers...the sequence goes something like this
1. Create container (through factory)
2. (optionally) Add any IContainerListeners (to be notified when
connect/disconnect/dispose are called)
3. (optionally) call container.connect(targetID, connectContext)
4. Call getAdapter(adapterclass) with the adapter class of interest
5. Check the resulting adapter for null and throw/do something in
case it's null
6. Use the adapter
Except the listeners other steps are done.
Another approach came to my mind when continuing the work. Since
salvo use serverStoreFacade to achive most of the task and
IServerStoreFacade is a generic model what about having
public IServerStoreFacade gerServerStoreFacade() ;
in IChannelContainerAdaptor? omething like this has been done in
xmpp implementation. But the problem here is somewhere we have
to cast IServerStoreFacade to respective type to get the
protocol specific implementations.
I don't see anything wrong with this approach...but I have to admit
I don't have a clear understanding of the API (and the underlying
protocol(s)) at this point...I think this is more of a question
appropriate for Harshana and/or Wim...given my limited knowledge of
what's there.
One general comment about breaking down an API into 'sub-APIs'...I
think this is most appropriate when a) the API is fairly complex
(more than just 2 or three methods), and 2) the API has fairly
logical structure...e.g. roster management, im/chat, search, etc.
I'm not sure whether what you describe above meets these criteria or
not...so that's my hesitation about saying something direct about
whether this is a good idea in this case or not.
Yeah. That is the point. This API is kind of complex and with some effort can be broken-down to sub part. I'll further think about this.
In general though...it seems like good progress. Are these
interfaces available somewhere in source and/or javadoc form? I
would like to stare at them myself. Another thought...it might be
useful to write some test code (even if you don't have the actual
implementation finished)...just to look at how the API might/will be
used.
Yeah it is available at [1]. But I think I haven't committed the completely implemented API. These days I am working on moving the salvo to a container implementation.
Thanks,
Scott
Hoping answers to
these problems to continue with my work.
--
Regards,
Tishan
[1] https://github.com/tishan89/Newsreader
--
Regards,
Tishan
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Regards,
Tishan
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Regards,
Tishan
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
