| Re: [ecf-dev] GSOC 2012 Enhancing Eclipse Salvo NewsReader |
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,WimOn 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:
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.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.
Ok got the point. Harshan also pointed out the same thing when I had a chat with him.
Typically...for containers...the sequence goes something like this
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?
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.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.
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.
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