Auto-conf meeting logs

The final meeting.

August 19 2007

The final meeting.

<onnadi3>	Good day, lemmy, rcjsuen
<rcjsuen>	onnadi3: Hi
<lemmy>	Hi
<lemmy>	Do we have an agenda?
<onnadi3>	Wwe need to figure out what I should do to round up before the submission date
<onnadi3>	Which is tomorrow, I believe
<lemmy>	Yep, tomorrow is pencils down
<onnadi3>	1. Upload my code to code.google.com
<onnadi3>	2. Make the changes you guys suggested to the documentation
<onnadi3>	No. 3 would be post on my blog about the wonders of Discovery, but you guys haven't commented on the draft I put up
<onnadi3>	Should we just skip it?
<lemmy>	we should stick to the plan and try to get as much pr as possible.
<onnadi3>	okey-doke
<rcjsuen>	yup, I agree
<lemmy>	and the comment is still on my todo list.
<onnadi3>	:-)
<rcjsuen>	onnadi3: I left a one sentence comment like 10 minutes ago
<onnadi3>	Hmm, perhaps bugzilla was still down, then
<rcjsuen>	It was synchronizing this mornign.
<lemmy>	1. Upload my code to code.google.com. Is there anything to arrange for? 
<onnadi3>	Not really. They just want to see what you've done all summer. 
<onnadi3>	rcjsuen: I don't see any need to mention SoC. It was just a vehicle for achieving our ends :-)
<benny`work>	onnadi3, do you know where to upload the stuff? can't find anything about where to do it
<onnadi3>	benny`work: This article explains everything http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2
<benny`work>	onnadi3, thanks 
<onnadi3>	lemmy, rcjsuen: Anything else you'd like me to do before pencils down?
<rcjsuen>	Don't think so.
<rcjsuen>	maybe generate API docs but I don't know where to host that
<onnadi3>	cool
<kynes>	pombreda, ping
<onnadi3>	Well, I think that's all that's on the agenda
<onnadi3>	IS there any need for us to meet tomorrow?
<rcjsuen>	I don't think so.
<onnadi3>	Alrighty. I'll shoot y'all an e-mail when I've uploaded everything
Aug 19 13:45:58 	onnadi3 is sad that it's all over
<rcjsuen>	onnadi3: Thank you for all your hard work.
<onnadi3>	rcjsuen: Thank *you* for lurking on IRC all the time and answering all questions :-)
<rcjsuen>	Just trying to pay back to the Eclipse community ;)
<rcjsuen>	onnadi3: I see you approached the occasional straggler also, thanks
<onnadi3>	:-)
<onnadi3>	Well, I better finish rounding up my SoC. Markus, Remy, I'll talk to you all later
<lemmy>	ttyl

August 14

Action items

• E-mail Alex Blewitt to see if SoCers can post articles to EclipseZone about their projects
• Write an article on Discovery and post it as many places as possible
• Write documentation for Discovery in docbook format
• Check out how Mac Eclipse does their JRE discovery

<onnadi3>	I've got meeting items here http://wiki.eclipse.org/Auto-conf_meeting_agenda
<lemmy>	ok, lets get started: How to get Discovery into the Eclipse Platform
<lemmy>	what do you mean by that?
<onnadi3>	Well, I would like my work to be used by other projects
<lemmy>	do you mean how to make discovery part of the eclipse sdk?
<onnadi3>	Yeah :-)
<onnadi3>	Is there a process for it?
<lemmy>	that is something we cannot enforce. we rather have to hope for adoption. surely we can promote discovery with blog posts and examples. but at the end of the day, the platform team will decide.
<onnadi3>	okay
<onnadi3>	That kinna leads into the second item
<lemmy>	exactly. ;)
<onnadi3>	zx suggested making a screencast
<rcjsuen_>	yeah, item 1 really goes down to PR and usability
<lemmy>	i've never done a screencast. you're talking something like a flash movie?
<onnadi3>	Yeah...
<onnadi3>	Perhaps an article would suffice. Can anyone post on Eclipsezone?
<lemmy>	at best we would have both. personally I don't like screencasts, i rather like to read normal text.
<onnadi3>	Me too
<lemmy>	we can ask alex blewit
<lemmy>	+t
<lemmy>	he is the "editor in chief".
<onnadi3>	ah, that guy
<onnadi3>	Does he lurk here?
<lemmy>	what about http://www.eclipse.org/articles/ ?
<rcjsuen_>	Nope, he doesn't.
<onnadi3>	Hello Remy :-)
<lemmy>	we should write him an email. maybe in the name of all soc projects.
<onnadi3>	That'd be great
<onnadi3>	I think  Eclipse corner will be easy enough
<onnadi3>	Oops. "hat is, articles that contain time-sensitive material or are likely to expire in a relatively short period of time do not belong on Eclipse Corner"
<rcjsuen_>	Depends what "short" means.
<onnadi3>	True, but isn't beta software the definition of time-sensitive material? :-)
<onnadi3>	Doh. We don't need to belabor this point. We can always post on Planet Eclipse. That's got mad readership
<rcjsuen_>	yeah
<rcjsuen_>	you could just paste some simple code
<rcjsuen_>	then include a zip
<rcjsuen_>	with the full thing
<rcjsuen_>	or whatever
<onnadi3>	So I guess, the bottom line is 1) E-mail Blewitt, and 2) post to Planet Eclipse
<lemmy>	onnadi3: are you going to write an email to alex? otherwise i can do it too.
<onnadi3>	lemmy: Well, if its going to be in the name of all of SoC then you should prob'ly do it. Otherwise I will
<lemmy>	onnadi3: i don't think i'm a better suited represent for soc... but ok, i'll write the email.
<onnadi3>	Oh, you don't know him personally?
<onnadi3>	Sorry, I thought you did
<onnadi3>	I can write it, in that case
<lemmy>	yeah, simply cc soc-dev
<onnadi3>	No problem
<rcjsuen_>	Don't think anyone in here really knows him that well.
<lemmy>	for agenda item #3 i suggest http://www.eclipse.org/articles/article.php?file=Article-Authoring-With-Eclipse/index.html
<lemmy>	although for a basic how to hack the wiki might be fine too.
<onnadi3>	Hmm, if DocBook can publish to HTML, then I'll go with it
<lemmy>	html, pdf, ...
<onnadi3>	good
<lemmy>	docbook doesn't contain the layout, just the structure.
<rcjsuen_>	DITA also does html / pdf, it can also transform to eclipsehelp, though I'm not familiar with the eclipsehelp bit
<lemmy>	for docbook i've done the transformation to html and pdf lately.
<onnadi3>	Alrighty. I'll start off with DocBook and switch to DITA if I hit snags
Aug 14 15:27:22 -->	jevgeni (n=def@ip50.cab81.tln.starman.ee) has joined #eclipse-soc
<lemmy>	he is hard to miss, isn't he? ;o
<lemmy>	the British accent is very strong
<lemmy>	btw. onnadi3 have you had a look at the mac jre discovery code in 3.4m1?
<rcjsuen_>	I didn't even realize there was a 'Search' button.
<rcjsuen_>	Maybe it just looks for specific path names
<rcjsuen_>	like jre/bin/
<lemmy>	rcjsuen_: the search button on the jre page is older. but it isn't a smart search, just recursive.
<rcjsuen_>	ic
<onnadi3>	From the description, it does exactly what our Discovery does
<onnadi3>	Searches a location for JREs
<lemmy>	but only on mac osx
Aug 14 15:31:14 -->	michaelr (n=no@S010600184d82fd75.cg.shawcable.net) has joined #eclipse-soc
<onnadi3>	true :-)
<lemmy>	but it is definitely worth to check how they do it.
<onnadi3>	okay
<rcjsuen_>	I wonder how it works
<rcjsuen_>	maybe like if (Platform.getOS().equals(Platform.MAC)) or whatever the actual method/field names are
<--	Pookzilla has quit ()
<onnadi3>	Well, that's it for the agenda. I'm still mailing the CDT-dev folks to try and get the Make insertion working
<onnadi3>	I tried the instructions they gave, but nothing happened
<rcjsuen_>	onnadi3: that's nice
<onnadi3>	:-)
<--	jevgeni has quit ("Bye!")
<Ali>	could you please send me a link to the sourceforge project for that? I didnt see it on teh wiki (I may have missed it though)
<onnadi3>	lemmy, rcjsuen_: When do I have to turn in all the code/docs/etc. in so you guys can evaluate?
<rcjsuen_>	Ali: eclipse-incub is the name
<rcjsuen_>	so sourceforge.net/projects/eclipse-incub
<lemmy>	as early as possible. continuous evaluation. ;)
<rcjsuen_>	onnadi3: dunno, let's see
<rcjsuen_>	probably next Friday
<rcjsuen_>	http://code.google.com/support/bin/answer.py?answer=60325&topic=10729
<onnadi3>	Alright, as soon as possible but before Friday, it is :-)
<onnadi3>	So our final meeting will be on Monday, the 20th, then?
<lemmy>	do we want to have an additional meeting in between?
<Ali>	thanks a lot. Is there any information on what is left to be implemented, what features have ben implemented and such?
<onnadi3>	lemmy: If we do, I'd rather it be between friday and sunday inclusive. That way I'd have stuff for y'all to comment on
<Ali>	I saw a comment at the bottom of the wiki regarding RSE
<Ali>	I am glad to see things are moving forward there :-)
<lemmy>	onnadi3: so we leave the precise date open but target the weekend?
<onnadi3>	Sure thing
<onnadi3>	Are there any other items to discuss today?
<lemmy>	not from my side
<lemmy>	ok, ttytomorrow
<rcjsuen_>	bye
<onnadi3>	alrighty. Bye :-)

   ===August 6 2007===

Markus explained how to use OS-specific fragments.

Aug 06 11:35:44 <onnadi3>	I still haven't figured out how to incorporate code from OS-specific fragments
Aug 06 11:35:54 <onnadi3>	I haven't worked on that bug since I posted it
Aug 06 11:36:04 <onnadi3>	~196660
Aug 06 11:36:42 <lemmy>	bugzilla is probably still down
Aug 06 11:37:13 <onnadi3>	I can access it just fine. (why didn't KOS-MOS autocomplete?)
Aug 06 11:37:59 <lemmy>	bugzilla was down earlier today. maybe KOS-MOS needs a restart?!
Aug 06 11:38:15 <onnadi3>	strange
Aug 06 11:39:14 <KOS-MOS>	See bug 196660 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=196660
Aug 06 11:39:20 <onnadi3>	yay!
Aug 06 11:40:21 <onnadi3>	So, have you ever written OS-specific fragments before?
Aug 06 11:40:40 <lemmy>	yep
Aug 06 11:41:13 <onnadi3>	Could you send me the fragment's manifest or any other code so I can figure out how to do it in Discovery?
Aug 06 11:43:37 <lemmy>	onnadi3, swt itself uses fragments.
Aug 06 11:43:46 <lemmy>	which are pretty much platform dependent.
Aug 06 11:44:28 <onnadi3>	I just can't figure out how to make certain code/classes appear on one OS and not in another
Aug 06 11:44:42 <onnadi3>	Perhaps its not too important. We could alway just bundle em all together
Aug 06 11:45:36 <lemmy>	we could
Aug 06 11:46:40 <onnadi3>	okay
Aug 06 11:46:43 <lemmy>	the interfaces of each fragment has to be the same, but the impl might differ. actually i would move the interfaces into the host plug-in and let the fragments implement the interfaces.
Aug 06 11:47:32 <lemmy>	making certain classes appear only on a certain os kinda destroys the fragment purpose anyway.
Aug 06 11:47:39 <onnadi3>	So, we'd publish a JREFinder-win or JREFinder-osx?
Aug 06 11:47:47 <lemmy>	nope
Aug 06 11:48:18 <lemmy>	we publish a jrefinder and a jrefinder-win-fragment and a jrefinder-osx-fragment.
Aug 06 11:48:42 <lemmy>	a customer deployes all three inside osgi and osgi takes care of loading the right fragment.
Aug 06 11:49:01 <lemmy>	osgi checks the platform filter to determine which fragment to load.
Aug 06 11:50:23 <--	moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has left #eclipse-soc
Aug 06 11:50:34 <onnadi3>	Hmm, but then we're back at square one because I don't know how to set the OS filter. I've really tried and tried but there seems to be no articles that explain how to do it
Aug 06 11:50:57 <lemmy>	swt demonstrates it perfectly. Just extract org.eclipse.swt_3.3.0.vNNNN.jar and org.eclipse.swt.os.ws.arch.NNNN.jar
Aug 06 11:51:26 <lemmy>	onnadi3, os filters are explained in the osgi r4 spec. either the compendium or the core.
Aug 06 11:51:37 <onnadi3>	oh
Aug 06 11:52:16 <onnadi3>	I have the core here. Let me check it again
Aug 06 11:52:17 <lemmy>	in our case it is even easier than it is for swt. we don't need to care about arch and ws. we only need to care about os.
Aug 06 11:52:38 <lemmy>	(& (osgi.os=linux) (osgi.arch=x86))
Aug 06 11:53:04 <lemmy>	it's a ldap style "query".
Aug 06 11:56:00 <onnadi3>	Hmm, I found a small section in core about fragments. I think once I look through that and then through the jars (I didn't think of looking there), I'll be able to get this figured out
Aug 06 11:56:44 <lemmy>	in our case the platform filter will probably look just like "(osgi.os=linux)" and "(osgi.os=win32)"...
Aug 06 11:58:03 <onnadi3>	cool
Aug 06 11:59:58 <onnadi3>	Ah, I'm beginning to understand it now. The section on filters is hidden in the "Service Layer" section. That's how come I'd never seen it before

July 30 2007

<lemmy>	So what is on our agenda?
<rcjsuen_>	k we're good
<rcjsuen_>	i 'm outside the lab right now >_>
<onnadi3>	All that was left was to decide what we're to do about CDT i.e. to go ahead and discover whether Make exists on a system or not
<lemmy>	the other stuff is already done?
<onnadi3>	Well...I've implemented it and it compiles
<rcjsuen_>	lol
<onnadi3>	But I'm getting synchronization errors
<onnadi3>	(I dread Concurrency)
<rcjsuen_>	synchronization?
<rcjsuen_>	ah
<onnadi3>	I'm working on it. I hope it won't be a big deal
<onnadi3>	So, Markus, do you still think we should go ahead with just finding make on a system?
<lemmy>	yes, as it will help us to understand what we can generalize and refactor.
<onnadi3>	That's true
<rcjsuen_>	yes
<lemmy>	for example the rule set/heuristics should come from a xml file. I don't want to touch code/recompile if I add a new location.
<onnadi3>	Hmm, but the IFinder.refresh() can't be specified declaratively
<lemmy>	Why not?
<onnadi3>	Well, for instance in JREFinder, refresh() needs to call Platform and then run a loop in order to pick out the the right VMType to do the testing with
<onnadi3>	If you're going to have loops, then its no longer really declarative, is it?
<lemmy>	I don't get why this renders a xml file impossible.
<onnadi3>	Well, it doesn't make it impossible but it doesn't seem to be worth the trouble of avoiding recompilation if we'll end up writing loops and conditionals in XML
<lemmy>	conditional xml? why?
<--	rcjsuen has quit (Read error: 110 (Connection timed out))
<onnadi3>	If you can, please look at  JREFinder.isJREDirectory(). It makes use of loops and an if-statement
<lemmy>	btw. i'm still missing the jrefinder.ui plug-in
<onnadi3>	Oh? I committed that
<lemmy>	I'm talking about JREFinder.find() and the potentialJRELocations getting filled.
<lemmy>	This could be done with a simple/non conditional xml.
Jul 30 11:46:39 -->	moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has joined #eclipse-soc
<lemmy>	there is no jrefinder.ui plug-in. :o
<onnadi3>	Yeah. But what I'm saying is that IFinder also needs a refresh() method which uses relatively complex constructs that would not be suitable for XML. So we have to decide if we really want discovery plugin writers to have to separate their IFinder code into a Java part and an XML part
<lemmy>	Yes, because the xml changes independently of the refresh and more frequently.
<onnadi3>	Hmm...
<onnadi3>	That's true, too :-)
<onnadi3>	(BTW, I named the ui plugin wrongly and that's why it isn't showing up...yet)
Jul 30 11:51:52 -->	rcjsuen (i=rcjsuen@nat/ibm/x-d827998b15814402) has joined #eclipse-soc
<onnadi3>	lemmy: should we enforce the XML rule or  just let plugin writers use XML if they see fit?
<lemmy>	I don't see a reason to enforce it.
<onnadi3>	oh OK. So you meant use XML for JREFinder, then?
Jul 30 11:56:06 -->	soulreaper_ (i=soul@p54A66704.dip.t-dialin.net) has joined #eclipse-soc
<lemmy>	onnadi3, yep
<lemmy>	btw. newer swallow Exceptions.
<lemmy>	try { ... } catch(Exception e) { // do nothing } is really bad.
<lemmy>	JREFinder.readLInes()
<onnadi3>	But the silly BufferedReader throws exceptions when it hits EOF. I couldn't think of another way to test for EOF
<onnadi3>	And the API doesn't have an isEndOfFile() method
<lemmy>	What kind of exception does it throw in that case?
<--	rcjsuen_ has quit (Read error: 110 (Connection timed out))
<onnadi3>	**ahem** an IOException. I'll put that in right away :-)
<rcjsuen>	it shouldn't
<rcjsuen>	you're calling reader.readLine()?
<onnadi3>	Yeah
<rcjsuen>	If it's done
<rcjsuen>	it should return null
<lemmy>	onnadi3, the problem with catching Exception is, that it catches all RuntimeException. And somebody might be interested in certain RuntimeExceptions
<onnadi3>	Ah. Null. I didn't see that...
<onnadi3>	Good call, Markus. Will change it
<--	soulreaper has quit (Read error: 110 (Connection timed out))
<onnadi3>	Alright. Bottom line: we should get JREFinder to use a an external representation (e.g. XML) for storing the potential JRE locations
<onnadi3>	lemmy, rcjsuen: I don't think there's anything else left to discuss; Do y'all?
<rcjsuen>	I don't think so off hand.
<onnadi3>	okey-dokey. I'll do some more bug hunting and update bugzilla once this undiscovery thing is done, then

July 28 2007

• Weekly meetings moved to 11:30am EDT/7:30pm CST
• Designed the interface IFinder that all finders will share. See Bug 198121

<onnadi3>	rcjsuen, lemmy: Should we go ahead and get started?
<lemmy>	sure
<rcjsuen>	yes, let's do that
<onnadi3>	I would like us to go over the outstanding bugs so I can get an idea for fixing them
<rcjsuen>	before my teammates come in ;p
<onnadi3>	1. Improve configuration of new Discovery Finders
<onnadi3>	~198121
<KOS-MOS>	See bug 198121 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121
<rcjsuen>	query https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPEN
<rcjsuen>	ED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<rcjsuen>	or not
<rcjsuen>	i see it got mangled
<onnadi3>	rcjsuen: how'd you get to that page?
<rcjsuen>	what page
<rcjsuen>	the query?
<onnadi3>	yeah
<rcjsuen>	i just constructed one from bugzilla
<onnadi3>	could you give me the parameters? I've tried it unsuccessfully before
<lemmy>	why does find() return null? why not make the method abstract?
<rcjsuen>	I guess this one is better ;) https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
<rcjsuen>	even tho we see the other bugs but anyway
<onnadi3>	lemmy: It returns null because I haven't yet implemented it. I should have noted that
<onnadi3>	Let me give the sequence of calls to Finder
<rcjsuen>	yeah that's what i figured
<rcjsuen>	so i didn't say anything there
<onnadi3>	a. You construct the Finder
<onnadi3>	b. You call find() whenever you want the service discovered
<onnadi3>	c. You call unfind() whenever you want the service undiscovered. There is also a separate thread that monitors the found service and calls unfind() at regular intervals
<onnadi3>	that's it
<lemmy>	"You" is who in the JRE scenario?
<onnadi3>	"You" is the person subclassing Finder e.g. JREFinder, MakeFinder etc.
<lemmy>	That I don't get
<lemmy>	Let me put it this way, who calls this methods during runtime?
<onnadi3>	The JREFinder plugin, for example
<rcjsuen>	In its start method?
<lemmy>	Doesn't the JREFinder implement the Finder?
<rcjsuen>	onnadi3: Query for all discovery bugs https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&component=org.eclipse.soc.discovery query for open ones https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=org.eclipse.soc.discovery
<lemmy>	s/implement/extend
<rcjsuen>	lemmy: you mean who instantiates it and calls find(), right?
<onnadi3>	That is one way. The other would be to expose the Finder class and have it called whenever the user clicks a button. That is how the JREFinder plugin is built right now actually
<lemmy>	rcjsuen: yep
<onnadi3>	I guess we should use "finder plugin" for the plugin and "JREFinder" for the class. And yes, JREFinder implements Finder
<lemmy>	So the finder plug-in calls find() on JREFinder and passes the result to the ECF discovery API?
<onnadi3>	lemmy: Actually, how I described it was that calling find() would automatically pass the result to the ECF Discovery API
<onnadi3>	rcjsuen: thanks for the links
<rcjsuen>	so what exactly is the Collection for?
<rcjsuen>	Or wait the Colection is what's been found or?
<lemmy>	so find() passes it to the PluginDiscoveryService ds instance?
<onnadi3>	rcjsuen: the Collection is not strictly necessary. I thought it would be nice to have a list of what was found
<rcjsuen>	ah kk
<lemmy>	I would separate it into find() and populate().
<lemmy>	populate() passes the find() result to ds
<onnadi3>	lemmy: Shouldn't we have instead, find(), populate() and findAndPopulate()?
<onnadi3>	So that plug-in writers don't have to do populate(Finder.find())
<rcjsuen>	onnadi3: if we go that route i'd prefer a find() and a find(boolean populate) for populating, I don't like findAndPopulate ;p
<lemmy>	rcjsuen: this look so c-ish
<onnadi3>	okey-dokey :-)
<lemmy>	looks
<rcjsuen>	lemmy: funny, beacuse I don't know C at all
<rcjsuen>	except hello world
<rcjsuen>	and how to make a struct
<rcjsuen>	I think that's about it
<lemmy>	Why have a parameter to change the behavior of a method? make two methods out of it. :)
<onnadi3>	But wouldn't it just be simpler to have the one method that find()s, populate()s and returns the found services?
<rcjsuen>	lemmy: I'm just applyign the same idea from JFace viewers refresh/update and SWT widgets layout methods
<lemmy>	rcjsuen: they are pretty c-ish too. ;o
<rcjsuen>	onnadi3: so by that you mean we have a populate() method that's populating _and_ returns the found services, yesA?
<lemmy>	Anyway, I still don't get the whole picture...
<rcjsuen>	lemmy: having to call dispose() is pretty C-ish ;)
<onnadi3>	rcjsuen: Yeah
<lemmy>	rcjsuen: dispose(*widget) would be c-ish. dispose() is rather c++-ish. .P
<onnadi3>	rcjsuen: that was a yeah regarding your comment about populating and returning
<rcjsuen>	onnadi3: I see.
<rcjsuen>	true, we're not doing free(this)
<onnadi3>	:-)
<lemmy>	We have the PluginDiscoveryService which acts as the general API for consumers like JREInjector. Consumers get discovery results from the PluginDiscoveryService for a given type.
<lemmy>	Also we have Finders which report discovery results to PluginDiscoveryService
<lemmy>	reporting results to PluginDiscoveryService is something in the responsibility of the Finders?
<onnadi3>	lemmy: Yes, since there is no one else for them to report to
<lemmy>	onnadi3: what's with Finders registering themselfs at the PluginDiscoveryService?
<lemmy>	Then the PluginDiscoveryService would call find() on all registered finders
<lemmy>	registering could be done via OSGi services (but that's just the technical side of it).
<onnadi3>	I think its the other way round. The Finder takes a pointer to the PluginDiscoveryService so that it can call registerService()
<lemmy>	are we talking about registering the finder at the plugindiscoveryservice?
<lemmy>	that is the basic necessity, if plugindiscoveryservice should be responsible for calling find()...
<onnadi3>	The reason why we can't have PDS calling find() on all Finders is because you never know when someone will want a service found e.g. in the case of having a GUI button that starts the finding process
<lemmy>	onnadi3: true, but it means also that we cannot issue a global find() on all finders.
<lemmy>	question is, what is the main use case.
<lemmy>	PluginDiscoveryService might offer discover() and discover(IServiceType)
<onnadi3>	what does discover() do? Call find() on all Finders?
<lemmy>	while the first is for issuing a general find() on all finders independent of the type, the latter is for calling find() on specific finders.
Jul 28 10:06:01 -->	sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
<rcjsuen>	I like that.
<onnadi3>	Doesn't that make what we did with JREFinder impossible then? i.e. have a GUI that initiates the find process. I'm not saying that JREFinder is the best model for structuring finders...
Jul 28 10:07:09 -->	kreismeister (n=Miranda@eclipse/developer/Eclipse/Kreismeister) has joined #eclipse-soc
<lemmy>	onnadi3: The gui would be finder independent.
<onnadi3>	Ah yes
<lemmy>	The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
<rcjsuen>	mmm yes
<lemmy>	If there is no Finder for the given IServiceType registered, nothing would happen.
<lemmy>	onnadi3: calling the specific finder directly also has the disadvantage, that you cannot easily have different finders for the same type.
<lemmy>	imagine a RegistryJREFinder and a FilesystemJREFinder.
<onnadi3>	lemmy: jolly good point
<lemmy>	They both discovery the same IServiceType "JRE"
<lemmy>	Finder would then only implement IDiscoveryResult find() and unfind(IDiscoveryResult) maybe renamed to refresh(IDiscoveryResult)
<lemmy>	But this would leave PluginDiscoveryService responsible for keeping and updating IDiscoveryResults for undiscovery.
<lemmy>	I'm not sure if this is a big disadvantage.
<onnadi3>	It can always delegate to the Finders, can't it?
<lemmy>	All this matches stuff could be handled inside the Finder
<lemmy>	onnadi3: PluginDiscoveryService will delegate the unfind/refresh of the IDiscvoeryResult to the Finder, but it needs to keep track of IDiscoveryResults.
<onnadi3>	I believe it already does that
<lemmy>	perfect :)
<onnadi3>	If we have Finders registering with PluginDiscoveryService through extension points, how will (for instance) the GUI be able to initiate a find()?
<rcjsuen>	isn't that the discovery(IServiceType.JRE) thing?
<lemmy>	The GUI will need to get the PluginDiscoveryService instance and call discover() on it.
<lemmy>	rcjsuen: exactly
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
<lemmy>	Getting the PluginDiscoveryService reference in the GUI can be done via OSGi.
<--	sonnyblack has quit (Read error: 110 (Connection timed out))
Jul 28 10:21:18 *	sonnyblack_ is now known as sonnyblack
<onnadi3>	Aaaaah
<onnadi3>	I see
<onnadi3>	rcjsuen: Could you please tell us the method names you would have preferred for the Finder class?
<rcjsuen>	isMatch -> matches
<lemmy>	I've just submitted a IFinder proposal as a bug comment
<rcjsuen>	dunno about initPotentialMatches(), unfind is pretty weird but dunno if there are better options
<rcjsuen>	lemmy: to 198121?
<lemmy>	yep
<onnadi3>	lemmy: what is the boolean in refresh() supposed to be?
<rcjsuen>	now bugzila worked
<lemmy>	onnadi3: pretty much what unfind() did.
<rcjsuen>	Eh?
<onnadi3>	Sorry, I meant what is the return value of refresh()?
<lemmy>	but IFinder is stateless. I doesn't keep track which IDiscoveryResults have been found before.
<lemmy>	boolean
<lemmy>	valid
<lemmy>	is the given IDiscoveryResult still valid or not
<rcjsuen>	hm
<rcjsuen>	validate(IDR) maybe? ;p
<rcjsuen>	that's kinda like refresh
<rcjsuen>	we're validating it again
<rcjsuen>	or maybe not
<lemmy>	true :)
<rcjsuen>	maybe validate implies a shortop
<rcjsuen>	whereas refresh is a longop?
<rcjsuen>	hm
Jul 28 10:29:45 *	rcjsuen rubs his chin.
<--	kreismeister has quit (Read error: 104 (Connection reset by peer))
<onnadi3>	Shouldn't we also have a method that refreshes all the previously found IDiscoveryResults?
<rcjsuen>	like a validateAll()?
<onnadi3>	Yeah
<rcjsuen>	hm
<lemmy>	onnadi3: IFinder.refreshAll()?
<onnadi3>	And it could return a Collection of still valid IDRs
<lemmy>	but this implies that IFinder knows about previously discovered IDiscoveryResults.
<rcjsuen>	Maybe take a Collection and pass back a Collection of valid ones?
<onnadi3>	Oh!!! I see your point, Markus. PDS is already keeping track of IDRs
<lemmy>	well, this is just convenient API then.boolean validate(IDiscoveryResult) is the minimum.
<lemmy>	Well, one problem arises with IFinder not keeping track of IDiscoveryResults. PDS needs to know by which specific IFinder instance the IDiscoveryResult has been found earlier.
<lemmy>	The RegistryJREFinder probably cannot verify an IDR discovered by the FilesystemJREFinder
<onnadi3>	Akk! This means that PluginDiscoveryService will have to handle polling when it comes to undiscovery
<lemmy>	The IDS instance could store the IFinder by which is has been found.
<lemmy>	polling? PDS certainly is responsible for refreshing IDS and hence needs to ask the various IFinders regularly.
<lemmy>	Btw validate sounds more like verification of an IDS. I tend to refresh
Jul 28 10:37:39 -->	kreismeister (n=Miranda@p57AB7FBA.dip.t-dialin.net) has joined #eclipse-soc
<lemmy>	verification in terms of "is this IDS really a Sun JRE 1.4"...
<onnadi3>	lemmy: what is IDS?
<rcjsuen>	I'm fine with refresh
<lemmy>	s/IDS/IDR
<onnadi3>	okey-dokey. So  i guesswe're pretty much done with this bug, apart from naming?
<rcjsuen>	yeah
<onnadi3>	Bug no.2: Decide on the CDT tools to provide discovery for
<lemmy>	I got a question, ca we move our meeting permanently to monday afternoon ~17:30pm?
<onnadi3>	Sure, if it works with Remy
<rcjsuen>	What time is that
<lemmy>	11:30
<rcjsuen>	ooo, that collides directly with my weekly meeting
<rcjsuen>	Although that meeting isn't that important
<rcjsuen>	cuz we can bring our notebooks
<rcjsuen>	it's an informal status update
<rcjsuen>	I think it's fine
<lemmy>	perfect, so next meeting is 07/30 11:30am EDT
<onnadi3>	ALrighty
<rcjsuen>	ok
<onnadi3>	So,  Bug no.2: Decide on the CDT tools to provide discovery for
<onnadi3>	~197885
<KOS-MOS>	See bug 197885 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=197885
<onnadi3>	(I like doing that :-))
<onnadi3>	Shall we be sticking with CDT?
<lemmy>	I'm still +1 for CDT even if it means we only do discovery of make
<rcjsuen>	yeah
<rcjsuen>	i never see people complain about setting up pdt
<rcjsuen>	(well install is hard)
<onnadi3>	So, we need to test if make is in the PATH, and if it is not, find where it is installed on the system 
<lemmy>	well, we wan't to discover all installations ofmake and not just the one in make.
<lemmy>	s/make/path
<onnadi3>	The thing is the CDT interface doesn't really have a drop-down list like JDT does
<onnadi3>	All it has is a text box where you can enter the name of the make command you want to use
<lemmy>	postponed until Monday? The other bug will keep you busy anyway, right?
Jul 28 10:57:21 -->	sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
<onnadi3>	sure :-)
<onnadi3>	Sweet meeting y'all
<onnadi3>	See ya soon