Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Auto-conf meeting backlogs2
23 June 2007
- Bugzilla move
Tasks are: 1) move old Discovery over to ecf.discovery's interface, and 2) write a JREFinder that works for Windows and Linux. We won't start adding these to Bugzilla until our component has been moved to Bugzilla first.
- state paperwork (soc.eclipse.org move)
Oge should move all the old code to soc.eclipse.org
18 June 2007
This is a discussion I had with Scott Lewis (slewis2) on org.eclipse.ecf.discovery in general, and its overlap with our org.eclipse.iscovery. Bottom line: it overlaps quite a bit and we should consider implementing its interfaces.
<rcjsuen> Oge could you discuss with Scott?
<onnadi3> Sure thing
<onnadi3> slewis2: I'm trying to understand how
ecf.discovery works. Could you please tell me if my
understanding is correct?
<slewis2> have you taken a look at test code?
<onnadi3> The one included with jmdns?
<slewis2> no...in plugin org.eclipse.ecf.tests.discover
y
<slewis2> in tests module of repo
<onnadi3> I don't think so
<onnadi3> Gimme a minute :-)
<slewis2> ok...we can chat too...proceed
<onnadi3> It seems like a service provider e.g. a Web
server communicates its presence by generating an
IServiceEvent
<onnadi3> Other bundles that require the Web server,
register as IServiceTypeListeners
<onnadi3> Once they get the event, tehy can extract
the IServiceInfo and find out thte port and
inetaddress of said server
<onnadi3> Is that how ecf.discovery works?
<slewis2> essentially that's right...although the
generating of an IServiceEvent is done implicitly
via registerService()
<slewis2> RE: receiving the event and IServiceInfo...ye
s...if the port and inetaddress is what's
needed...typically there will be more/other
service-specific info...as properties
<onnadi3> what class contains registerService()?
<slewis2> you mean impl?
<slewis2> (or interface)?
<onnadi3> Well, I'm not sure. How are services
registered?
<slewis2> the IDiscoveryContainerAdapter has the
interface (discovery API)
<slewis2> services are registered via IDiscoveryContain
erAdapter.registerService(IServiceInfo serviceInfo)
<slewis2> the jmdns implementation of the IDiscoveryCon
tainerAdapter is in org.eclipse.ecf.provider.discover
y plugin, o.e.e.p.discovery.container.JMDNSDiscoveryC
ontainer class
<onnadi3> Sorry, I'm just trying to locate the class
<slewis2> np...which one?
<slewis2> I can find URLs to src if you like
<onnadi3> I'm looking for org.eclipse.ecf.provider.disc
overy.container.JMDNSDiscoveryContainer
<onnadi3> A URL would be great, thanks
<slewis2> http://dev.eclipse.org/viewcvs/index.cgi/org.
eclipse.ecf/plugins/org.eclipse.ecf.provider.jmdns/sr
c/org/eclipse/ecf/provider/jmdns/container/?root=Tech
nology_Project
<onnadi3> Ok. So in the case of a hypothetical Web
server, what would it register its service to?
<slewis2> It would a) create an appropriate instance
of IServiceInfo, then call IDiscoveryContainerAdapter
.registerService(svcInfo)
<slewis2> then listeners would/will be asynchronously
notified
<slewis2> the conventions on type names are different
for different providers (e.g. jmdns has _http._tcp
for example) but the API leaves the service type as
typeless (String) so other providers can use other
conventions
<slewis2> and even zeroconf's is just convention
<onnadi3> Hmm, so if this Web server didn't exist on
the local machine, I would write a plugin that
polled the server every so often and then registered
or unregistered the WebServerServiceInfo as
necessary, right?
<slewis2> you could do that...if you wanted to act as
a discovery 'proxy' for the web server...but it
would be better to just add service registration to
the web server
<slewis2> if you can, obviously
<onnadi3> Alright! I think I see it now. ecf.discovery
is kinna like a 'protocol' that servers and clients
can use to keep aware of each other
<slewis2> it's not a real protocol in the traditional
sense, as there's nothing implied about what goes on
wire between processes, but it is a high-level API
for processes to keep aware of each other...note
there's nothing inherently asymmetric ('server' or
'client') about it...any process can use as 'server'
or 'client'
<slewis2> API implies asynch notification between
processes, at level of 'service type'
<onnadi3> Excellent. I think this is what I, and
rcjsuen, and lemmy are looking for
<onnadi3> Thank you so much for patiently explaining
everything to me
<slewis2> great. Note that although the current impl
is based upon jmdns, that we would like other impls
done...that use other protocols
<slewis2> and if generalizations are needed/necessary
for other 'styles' of discovery then we can/will add
them
<onnadi3> Well, we're working on the discovery of
services that exist on the local machine, so I think
we'll be able to implement ecf.discovery without
using a protocol like SLP, jmDNS etc.
<slewis2> also note: there's a IDiscoveryService
interface that is intended to be an OSGi service
<slewis2> onnadi3: so you are discovering/searching
for OSGi services or other manner of service?
<onnadi3> Not really. More like, we're discovering
binaries in the filesystem or local ports running
daemons
<slewis2> I see
<onnadi3> So am I right in saying that we can
implement ecf.discovery without using other
protocols, or IDiscoveryService?
<slewis2> yeah, sure...you can create your own impl of
ecf.discovery that does whatever you want
<onnadi3> sweet
<slewis2> it may be appropriate to include such a
plugin in ECF (as another provider of discovery) if
desired/possible
* michaelr has joined #eclipse-soc
<slewis2> but just use jmdns as an example...and look
to implement IContainer and IDiscoveryContainerAdapte
r
<slewis2> then if you like you can reuse/use the
DiscoveryView in org.eclipse.ecf.discovery.ui...and
your discovered services should show up there
<onnadi3> IContainer? I don't see it in the
ecf.discovery source tree
<slewis2> It's in the org.eclipse.ecf plugin (core)
<slewis2> discovery depends upon it
<onnadi3> I see it
<slewis2> for ID interfaces, IContainer, ContainerFacto
ry and some util classes
<slewis2> IContainer.getAdapter(IDiscoveryContainerAdap
ter.class) is how you get an IDiscoveryContainerAdapt
er instance (or via OSGi service)
<onnadi3> We'll probably be using OSGi services, so I
guess we won't need to implement the IContainer
<slewis2> in jmdns/plugin.xml you will see that it
defines a namespace and a container factory...you
will probably need to do this too
<slewis2> ...or OSGi services...sure
<onnadi3> I can't find jmdns/plugin.xml in here:
http://jmdns.cvs.sourceforge.net/jmdns/jmdns/
<slewis2> see org.eclipse.ecf.tests.discovery.Activator
.start for the access to discovery as OSGi service
(note that IDiscoveryService is sub-interface of
IDiscoveryContainerAdapter)
<slewis2> yeah, it's not in jmdns project...its here...
<slewis2> http://dev.eclipse.org/viewcvs/index.cgi/org.
eclipse.ecf/plugins/org.eclipse.ecf.provider.jmdns/?r
oot=Technology_Project
<slewis2> we simply use jmdns as a library for jmdns
impl of ecf...it has no knowledge of ECF or Eclipse
concepts (ID, IContainer, adapters, etc)
<onnadi3> OK. I have one last question. I noticed in
the IDiscoveryContainerAdapter Javadoc, it says
that gets are synchronous and requests are
asynchronous. What is the difference between get and
request and what does it mean for them to be synch
vs. asynch?
<slewis2> this is a good thing, as it makes it quite
easy to take other discovery protocols and 'wrap
them' with an ECF-aware bundle
<slewis2> requests don't block (and don't have return
values)
<slewis2> gets do block (how long determined by
timeout), and return IServiceInfo (or others)
16 June 2007
Action items:
1. We should all complete the commiter registration process so we can begin moving our code to dev.eclipse.org
2. Look at org.eclipse.ecf.discovery to see if we can reuse their code
<onnadi3> Good morning all <lemmy> Lets time today's meeting for one hour? should be enough, shouldn't it? <lemmy> Hi onnadi3 <onnadi3> lemmy: sure thing <lemmy> btw. we could change our meeting time now that i'm back in cest. <lemmy> I'm fine with the current time though, but i'd not mind moving it to a later spot so you have time for a decent breakfast? <onnadi3> Eh, I'm now used to waking up freakishly early :-) <lemmy> ok, so meeting time will remain as is. <onnadi3> Howdy, rcjsuen <rcjsuen> ogeHi <lemmy> 1. soc.eclipse.org as SCM <lemmy> Remy, I guess the process has been started and the foundation will contact me and Ogechi. <rcjsuen> Yes <onnadi3> I've been contacted. I can start filling out the paperwork after the meeting <lemmy> They have contacted you already? that is fast. <onnadi3> Yeah, someone called emo-records@eclipse.org <rcjsuen> More like, that's scary. <rcjsuen> that might be an automated email <rcjsuen> lemmy: did you get anything in your dev.eclipse.or gemail? <rcjsuen> Or did i fill that in wrong <lemmy> remy, nothing so far <rcjsuen> nope, i used dev.eclipse.org at lemmster de <rcjsuen> should be okay <rcjsuen> oh wel <lemmy> lets wait a day for the email to come and take actions then. <rcjsuen> yeah <rcjsuen> weekends and all <rcjsuen> give them a business day or two i guess <onnadi3> Should we move to the next item? <rcjsuen> yes, let's <lemmy> I've changed my Bugzilla id and now I can't log into the wiki anymore. <rcjsuen> i guess we're all looking at http://wiki.eclipse. org/index.php/Auto-conf_meeting_agenda ? <rcjsuen> although SCM was last instead of #1 <onnadi3> yup, I'm looking at it <lemmy> 2. Status common-collections <onnadi3> Well, I eventually didn't need the MultiMap class so I did not use commons-collections <lemmy> perfect :) <rcjsuen> well then <lemmy> why isn't it necessary anymore? some design change? <onnadi3> Yeah, kinna. I originally thought that IFinder.find() would return a MultiMap of all the services it was capable of finding <onnadi3> Hence it would need a MultiMap <onnadi3> But then I realized that we wouldn't want *all* the services discovered if only 1 was needed <onnadi3> And so the MultiMap class went out the door <lemmy> 3. dynamic discovery and undiscovery of a service <lemmy> a) during runtime a service might appear and disappear again. Hence we need a way to handle this scenario. <lemmy> I believe this is a rather important scenario which should be covered by our design. <onnadi3> Could we perhaps have a field in ServiceID that denotes when a service is 'volatile'? <onnadi3> In that case, things like services at ports or sockets could be marked volatile and their discovery results wouldn't be cached <lemmy> do you have an example for a non volatile service ? <onnadi3> Well, binaries could be non-volatile <lemmy> caching and volatile are different things. <onnadi3> What I mean is that the results from discovering 'volatile' services won't be cached <onnadi3> But those from non-volatile will <lemmy> i might make sense to cache those results too. at least it should be possible with the cache implementation . <rcjsuen> some kinda switch to enable/disable i guess <lemmy> and binaries might be volatile as well. <lemmy> imagine a binary on a removable disk. <onnadi3> Ah <lemmy> i suggest to assume all services to be volatile. <rcjsuen> someome might suddenly uninstall gcc! <onnadi3> How does Eclipse handle the locations of JREs? <lemmy> that's an even better scenario. <rcjsuen> You mean when someone uninstalls a JRE? Hm, I never thought about that. <lemmy> onnadi3: i'm not sure if jdt checks for existence and handle this case gracefully. <rcjsuen> I guess you want to look at the implementations of org.eclipse.jdt.launching.IVIMInstall. <lemmy> but you will probably get some sort of error message. either low level or high level. <onnadi3> Alrighty. I was just thinking that whatever is good enough for JDT is good enough for us :-) <lemmy> we need to distinguish between two different undiscovery events. one that is actively triggered by some finder (running asynchronously in a Thread) and a simple rediscovery. <lemmy> we won't have asynchronous Threads for binaries I guess, but we might have them for network services. For example jSLP works exactly like this. <lemmy> This Thread would fire an undiscovery event. <rcjsuen> so simple rediscovery you mean as in just invoking find() again? <lemmy> which brings us to the question if consumers can register for undiscovery event.s <onnadi3> What do you mean by undiscovery? <lemmy> rcjsuen: excatly <lemmy> undiscovery == service is gone <onnadi3> Hmm, I don't think people will/should be able to register for undiscovery events since we're not guaranteeing that they even get discovery events. They have to call Discovery to find if a service is there <lemmy> For most of the stuff I'm talking about you will find code in org.eclipse.ecf.discovery. <lemmy> And I suggest that we all have a deeper look into it. It seems as we might be able to reuse/extend this codebase. <lemmy> Basically it is a framework for discovery of remote services. But I don't see a reason why it couldn't be used for local discovery too. <lemmy> Btw. Scott Lewis is the project lead for ECF and also a mentor. <onnadi3> what's his IRC handle? <rcjsuen> slewis2 <lemmy> Actually he is the one who brought me up to the idea. <lemmy> It even offers some basic UI to show discovery results. * rcjsuen coughs. <onnadi3> cool. So we all look at ecf.discovery and decide whether or not to rearchitect our own Discovery? <lemmy> ? <rcjsuen> I mean, that code ain't great <onnadi3> rcjsuen: :-) <lemmy> rcjsuen: the ui code? <rcjsuen> from what i've seen before <lemmy> rcjsuen: the ui code? <rcjsuen> yeah, that <lemmy> OK, I don't really mind if the UI code is scrap or not. As long as the framework behind has potential. .) <lemmy> :) <rcjsuen> true <rcjsuen> Well, I haven't looked at the discovery APIs much. <rcjsuen> Not my area in ECF <onnadi3> So we all look at ecf.discovery and decide whether or not to rearchitect our own Discovery? <lemmy> My vision is to hook into the ECF discovery framework and focus on implementing the finders. This might even answer the question of project housing for discovery. * zx|work has quit IRC (Read error: 110 (Connection timed out)�) <lemmy> onnadi3: Yep, we should definitely do that. Even if we later see, that we cannot use it. <onnadi3> Hope we can use it. Less work for all of us <rcjsuen> Quite so. <lemmy> Do we want to have another meeting in two/three days to discuss our findings? <onnadi3> Sure <rcjsuen> Lemme check my Lotus Notes calendar. >_> <lemmy> Monday 7pm CEST/1pm EDT <lemmy> ? <rcjsuen> I might have a team meeting then, dunno what our MBA student wants. <lemmy> we could do it an hour later or two. <lemmy> You're free at that time? <rcjsuen> These meetings take a while <lemmy> a while as in the whole day? <rcjsuen> what time frame are you two free in * zx|work has joined #eclipse-soc <onnadi3> All week except Tuesday 10 - 11 <lemmy> usually I work until 6pm. I could do it directly from work so we could start an hour earlier. <rcjsuen> I don't know when he's gnona schedule it <rcjsuen> is the issue <lemmy> lets discuss the meeting time Monday once you know the meeting time. <rcjsuen> lemmy: if you can do 6pm that'd be great cuz then i can just do the lunch thing <lemmy> should be possible. <rcjsuen> I won't be in Thursday's SOC meeting btw <rcjsuen> lemmy: but okay, i'll talk to him on Monday to see when we're having our stat meeting <lemmy> great, anything else to talk about? <onnadi3> Yup, I've got two more items <lemmy> go ahead :) <onnadi3> > 5. Decide on how to specify service versions. <onnadi3> and 6. Should we redesign the Discovery UI (not GUI)? <onnadi3> I guess No. 6 can wait until after we check out ecf.discovery <lemmy> service versions is an interesting issue. I'm not sure whether ECF provides with this or not. <rcjsuen> Doesn't look like ECF's Discovery APIs have a version concept in IServiceID or in IServiceInfo. <rcjsuen> I guess unless it's in its properties. <lemmy> Maybe we should extend the service version thingy to a broader view of service properties <onnadi3> lemmy: interesting <lemmy> SLP allows to define properties per service which can be queried by an ldap style query. * wizEpit has quit IRC (Read error: 104 (Connection reset by peer)�) <rcjsuen> Well, having properties certainly helps us scale in the event of unforseen...properties. <rcjsuen> Makes it more extensible too i naway <onnadi3> If we allowed arbitrary properties, then it would be up to the service consumer to know how to identify all those features in the binary/port they're looking for <onnadi3> And so a project like CDT would, in addition to defining a GCCFinder, would also define a GCCIdentifier that, given a GCC binary, could tell what properties it has <lemmy> i'd expect to have an interface like: discovery gimme service x with propertiy A and property B not property C <lemmy> GCCIdentifier sound like an GCCValidator. <lemmy> +s <onnadi3> Sure :-) I guess my point is that we'd need a way of extracting the properties from the binary/port/soc ket <lemmy> well, this would be the responsibility of the finder. <rcjsuen> yeah <onnadi3> that's right * nickboldt has joined #eclipse-soc <lemmy> morning nick <nickboldt> hey there <rcjsuen> hi nick <lemmy> rcjsuen/onnadi: If you look into the examples at http://jslp.sourceforge.net/, you'll see what I mean by a query. <lemmy> Also how they handle service properties. <onnadi3> I looked it up on Wikipedia :-) <rcjsuen> wow, very small <lemmy> Btw. I'll probably spent some official work hours getting ecf.discovery running with jSLP. <onnadi3> lemmy: you have or you will? <lemmy> will hopefully <lemmy> I mean it makes sense in the project i work in. <lemmy> and my boss has already in-officially agreed to contribute the impl afterwards. <lemmy> Anyway, I guess we are done? <lemmy> I gotta catch a train. <onnadi3> I guess so <onnadi3> Bottom line, learn ecf.discovery <rcjsuen> lemmy: okay, ttyl Markus <lemmy> bye, have a nice day. <rcjsuen> bye <onnadi3> bye, lemms :-)
9 June 2007
We decided to do the following:
- Use the Apache Commons Collection MultiMap implementation. We would need to get rid of javax.beans.* since it won't compile with CDC 1.0
- Make SimpleConsumer use the console, not a GUI
- Create an immutable class, DiscoveryResults that is the return type of IFinder.find()
- Maintain a list of high-level requirements of this project
<rcjsuen> onnadi3: Hi <rcjsuen> onnadi3: I realized why you SimpleFinder compiles for you but not for me. <onnadi3> lemmy: Good Morning. Why is that? <rcjsuen> onnadi3: You are using a compiler compliance level of 5.0 or 6.0 <rcjsuen> The code will not compile below <rcjsuen> My workspace default is 1.4 so it was using a 1.4 setting. <rcjsuen> I set the project to 5.0 and it compiled. <rcjsuen> See for yourself. <onnadi3> OK. I remember fixing the problem somehow but I'm not sure what I did. I'm pulling up Eclipse now <lemmy> Hi <onnadi3> lemmy: Wie geht es Ihnen? :-) <lemmy> Super <lemmy> Tomorrow I'll leave India and travel back to Germany. :) <onnadi3> Nice. You excited? <lemmy> The previous three months have been a nice experience, but I'm happy to go back. <onnadi3> Ah. So I gues this is also the end of your crunch time, eh <rcjsuen> onnadi3: Did you look at your blog's replies? <lemmy> Yep <onnadi3> just checking em now <onnadi3> Oops. Ouch <onnadi3> Sheesh! Why didn't I notice that?? <onnadi3> oh well :-) <rcjsuen> The ol' debugger would've done it. <lemmy> The third comment is the most interesting one. But I'm not sure about the JDK dependencies of common-collections. <onnadi3> Well, the commons collection is the Apache Jar that I mentioned in my earlier e-mail <onnadi3> You said we should avoid the licensing issues, right? <rcjsuen> That was me. <lemmy> Apache license is compatible. Orbit might even contain it already. <rcjsuen> I just don't want to pull in a jar if I'm just using one class. <onnadi3> lemmy: oops. Sorry :-) <lemmy> What's on the agenda for today? <lemmy> I'm a little bit in a hurry, cause I still need to pack my bags... <onnadi3> Well, the only problem I'm having now is figuring out how to query Discovery for the services published to it <lemmy> It appears as if commons-collection isn't in Orbit yet, but many other commons-* are. <lemmy> +1 for using commons-collections if foundation 1.0 works for it. <rcjsuen> yes, I don't see it in Orbit <rcjsuen> It might be something odd like J2SE-1.2. <onnadi3> So I'd just download the jar and import from there, right? I don't have to use org.orbit? <ijuma> i'd guess 1.2 minimum too <rcjsuen> I think httpclient is j2se-1.2 <ijuma> rcjsuen: why is 1.2 odd? <lemmy> Create a new plug-in for that JAR. There is even a wizard for such a task. <rcjsuen> ijuma: I didn't think people cared about j2se-1.2 ;) <rcjsuen> then again, until i hopped on the eRCP bandwagon, i didn't think anyone cared about anything below j2se-1.4 <onnadi3> lemmy: why do I have to create a new plugin for the Commons jar? ican just include har in my current plug-in project, can't I? <ijuma> rcjsuen: well, because it's where the collections framework was introduced, it's likely that commons-collection would require that much at least <ijuma> but possibly 1.4 too <ijuma> i know it's not 1.5 <ijuma> (yet) <rcjsuen> ah <lemmy> onnadi3: creating a separate plug-in for a jar has the advantage, that other plug-in can reference the very same jar too. <onnadi3> lemmy: Ah. That's clever. <lemmy> And in this specific case, commons-collection might get included in the Orbit project. Discovery would then reference it there. <onnadi3> So even though I'd include the jar in a plug-in, Discovery will still reference it as a package exported by a plugin, not as a plugin itself, right? <lemmy> It's a lessons learned thing. Many many plug-ins used to include log4j. In the end this caused some headaches. <ijuma> rcjsuen: but to answer your question, Spring 2.0 still works with 1.3. 2.1 has just moved to 1.4 in the last development milestone. So yeah, people in the enterprise are also _slow_ ;) <rcjsuen> yeah <rcjsuen> I realized a lot of ppl are still on 1.3 <onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via a call to a Consumer class? <lemmy> I don't see the difference in your question. Discovery depends on the collections plug-in. The collection plug-in exports a couple of packages which then can be used by Discovery. <rcjsuen> I imported commons collection's source to my workspace <rcjsuen> It won't work on CDC1.0 because of java.beans.* <1.5 <rcjsuen> lemmy: yeah i told him that <lemmy> OK <rcjsuen> it's To Be Addressed <lemmy> rcjsuen: Can you tell which part of collections requires java.beans*? <rcjsuen> BeanMap <rcjsuen> if I delete it it's okay <lemmy> If that is the only reason, we could modify the JAR and file an enhancement request at apache.org <rcjsuen> The binary apepars to be 571,259 bytes. <rcjsuen> This will likely not fly in an embedded context. <lemmy> Size doesn't matter. ;) <onnadi3> :-) <lemmy> rcjsuen: Should be easy to optimize size-wise for the embedded use case. <rcjsuen> well, just saying, Equinox won't like this <lemmy> In general I prefer to reuse existing code over implementing from scratch. <lemmy> Fight NIH. :) <rcjsuen> NIH? <lemmy> Not Invented Here <rcjsuen> o <rcjsuen> well, let's address onnadi3's question <onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via a call to a Consumer class? <lemmy> Yep <onnadi3> Yay! <lemmy> So you're asking how the interface might look like? <rcjsuen> I think he's asking about how consumer plug-in accesses discovery plug-in. <onnadi3> Well, no. The interface is simply a menu item that you click and it should display a popup that lists all the found srevices so far <onnadi3> rcjsuen: Yup! <lemmy> onnadi3: Why do you "waste" time implementing a UI? <onnadi3> It took 0 time. It was what was produced by the Eclipse Wizard <lemmy> Testing is much better done with JUnit. <onnadi3> lemmy: Well, I wanted to complete the example <lemmy> Btw. I'm missing JUnit test cases in general. <onnadi3> Since I've written a SimpleFinder, I also want a SimpleConsumer <lemmy> I'd suggest to design the consumer as a JUnit plug-in project. <onnadi3> The only thing I think I can test right now is the MultiMap class (which will going soon anyway). The rest of the code is boilerplate which I don't hinkw we agreed on how to test it <lemmy> Where is the implementation for MultiMap? <onnadi3> Does a JUnit plugin project mean simply a blank project with JUnit testcases in it? <onnadi3> Sorry, the MultiMap code is not in the repo yet because I couldn't get th test for it to work <onnadi3> I guess I should put all compiled code in the repo, huh... <rcjsuen> My boss was just telling us to commit our project's code yesterday ;) <rcjsuen> I sidestepped by saying he just told us the package name to use today (which was different from what I was using) so I had to refactor and test properly ;p <onnadi3> :-) <lemmy> Might be that I'm not used to CVS anymore, but I'm fine with compiling but untested code in the repo. <lemmy> Simply to make sure the code is in a safe place. <onnadi3> Alrighty. Sorry about that. I'll have it up today <rcjsuen> just commit whenever you make a little change <rcjsuen> will save you time when you screw things up <onnadi3> Gotcha. And then i can actually discuss it with people <rcjsuen> I can speak from experience. <rcjsuen> onnadi3: yes, just create a org.eclipse.discovery.tests plug-in project <rcjsuen> then put your test cases there <rcjsuen> maybe some "fake code" if necessary <lemmy> I'm just picky, but in IFinder it reads "find() heuristically locates...". Why include "heuristically" in the interface at all? Seems more like an implementation detail to me. :) <onnadi3> Alrighty! <onnadi3> lemmy: good point on that <onnadi3> I'd still like to have an examples package where I can show how a consumer would utilize discovery to get services from a Finder <rcjsuen> yes, working examples are critical <lemmy> Even though I agree on the necessity for examples, I still think UI is a waste. Somebody wanting to use discovery will not care about the UI part. It will even make the example harder to understand. <rcjsuen> well, the sample unit test should be exemplary enough in that context Jun 09 10:16:19 * kreismeister (n=Miranda@p57AB7ABB.dip.t-dialin.net) has joined #eclipse-soc <onnadi3> lemmy: Well, I kinna thought that a real world Consumer would have a UI <rcjsuen> yes, but anyone that's going to use your plug-in already knows how to write a UI <onnadi3> And also, I wasn't sure how to control a plug-in from the console <lemmy> onnadi3: They probably will, but they want to learn how to use Discovery and not how to wire it up to the UI layer. :) <lemmy> onnadi3: Run Eclipse/OSGi with "-console". "help" will then show you what you can do. <rcjsuen> lemmy: for the issue of accessing the services <onnadi3> Alrighty <rcjsuen> lemmy: you're more familiar with OSGi services <lemmy> Which issues? I must have missed them. :o <onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via a call to a Consumer class? <rcjsuen> that <lemmy> Does services in this context really mean OSGi services? <onnadi3> oh no no no <onnadi3> It means the services that Finders find <rcjsuen> well then, never mind <lemmy> Btw. I would find() let return something like a DiscoveryResult rather than a Map. Internally it could still use a Map though, but later you might want to add some methods to it. <lemmy> ...which would be possible with a Map, but would look funny. <onnadi3> okey-doke <onnadi3> (BTW, you can find the MultiMap code I wrote here http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/sevice-discovery/org.eclipse.discovery/src/org/eclipse/discovery/) <lemmy> Also it shouldn't be possible for a consumer to modify the DiscoveryResults (Map). <lemmy> Since you might return a reference to the internal discovery cache. <onnadi3> Ah. An immutable structure <rcjsuen> yes, immutable is good <lemmy> Maps.unmodifiableMap(aMap). <lemmy> IIRC <lemmy> But if you use a DiscoveryResult, you don't need to expose the Map at all. <onnadi3> Alright, I can do that <lemmy> onnadi3: May I remind you of this "must", "should" and "nice to have" list that we agreed upon in last weeks meeting? :) <lemmy> Requirements tracking is somewhat important to me. <lemmy> Later we might want to create enhancement requests (bugs.eclipse.org) out of it. :) <onnadi3> Yes, that's a good point. So the DiscoveryResults thing would go in the "must" box, right? <lemmy> Why not. :) <lemmy> Though we should also keep track of higher level requirements. <lemmy> Mostly all the ideas which came up last week. <onnadi3> OK <onnadi3> So, somethign like this "IFinder.find() must return a class (say, DiscoveryResult) that contains a Map or whatever data structure is used internally."? <lemmy> MutliMap does not compile for me and I'd move it to .internal. too. <lemmy> Exactly <rcjsuen> lemmy: for the requirements page? <lemmy> rcjsuen: ? <rcjsuen> onnadi3: is that for the requirements page? <onnadi3> Yeah, e.g. http://wiki.eclipse.org/index.php/An_auto-configuration_plugin_for_Eclipse#Requirements <rcjsuen> That'd be a bit too low level in my opinion. You should scratch out the "Map or whatever data structure" bits. <rcjsuen> Just say it contains the results and leave it at that. <lemmy> Might be the case that it doesn't need a Map later on anymore. <onnadi3> rcjsuen: Hmm, but then Map would fit the requirement... <lemmy> Leave the internal implementation to the code. Only document external interfaces. :) <rcjsuen> yes, don't get into the implementation details if possible <onnadi3> OK <rcjsuen> as long as I can get the results <rcjsuen> i don't care if you're using a List of Lists or not <onnadi3> :-) <lemmy> onnadi3: You can't add domain specific methods to a Map which you can do with a domain specific object. That's my whole point for DiscoveryResult. <onnadi3> lemmy: I understand <onnadi3> Now could we please go back to the issue of getting the results from Discovery. It seems tht without that final example, I won't have made any real progress <lemmy> Sure <lemmy> Offer an EP that returns the DiscoveryResult <lemmy> Or start with a OSGi Service. <onnadi3> The consumer offers an EP? <lemmy> Nope, Discovery does. <onnadi3> I thought EPs take classes of a certain type. Can they pblish, too? <lemmy> Let me sketch it out for an OSGi service: Discovery registers an IDiscoveryService which offers a method discover(ServiceIdentifier) <lemmy> A consumer would then obtain the service an call the IDiscoveryService.discover(aSpecificServiceId) method. <lemmy> Since we don't have ServiceIdentifiers atm, the identifier could simple be a String for the moment. <lemmy> Basically this String will be somehow mapped to the key in the Map I assume. <lemmy> Reasonable so far? <onnadi3> So, in the code I have, the FinderTracker would also register an IDiscoveryService ? <onnadi3> Why does it have to be an interface seeing as there's only 1 Discovery? <lemmy> An interface is useful because consumer plug-ins might want to include this very interface in their plug-in. If an OSGi service is optional and at runtime not present, the consumer code would break because it might access the interfaec. <lemmy> If the interface is included in the consumer plug-in, it will not break with a NoClassDefFound. <onnadi3> oh!! <onnadi3> How long have you been coding OSGi? <lemmy> Not that long. Just for a couple of month. <onnadi3> Oh man... <onnadi3> Alright. So Discovery has an extension pt. that accepts IDiscovyerServices <onnadi3> So when Discovery is given a new extension, it changes a field in the IDiscoveryService to the results of calling discover(serviceID) <lemmy> I'd suggest to skip the EP for the moment and solely use OSGi services. An EP can be designed later with the knowledge gained while working with OSGi services. <lemmy> I don't get this. <lemmy> Remy? <onnadi3> lemmy: what don't you understand? <rcjsuen> No idea. <lemmy> I gotta go now. :( Can we continue Monday afternoon? <onnadi3> Sure. But if you have time, please send me an email about how to get data from Discovery via a separate OSGi bundle <onnadi3> I still don't understand how to do it <rcjsuen> Maybe this will be helpful http://www.knopflerfish.org/osgi_service_tutorial.html <rcjsuen> Was good enough for me for the most part. <lemmy> Talk to you guys on Monday. :) <rcjsuen> bye <onnadi3> lemmy: have a safe trip <lemmy> Thanks
2 June 2007
At this weekly meeting we tried to decide on exactly what the term "service" means, but we decided to save the discussion for a later date. We also decided on a preliminary architecture for the Discovery plug-in: Discovery will be an OSGi bundle that connects with other service finders through the OSGi services API, but connects with service consumers through Eclipse Extension Points.
<onnadi3> thanks <lemmy> I'm not sure, did I send my proposed meeting agenda out? <onnadi3> I didn't get yours...I sent one out, though <lemmy> I thought that one was in response to mine. <lemmy> it's out <onnadi3> Could you please send it again? I can't find it in mly inbox <lemmy> I've sent it a minute ago <onnadi3> got it <lemmy> it overlaps with your email <onnadi3> No problem. Yours is bigger so let's go over the technical aspects of yours, get to p. number 2 in mine, and then move on to the organizational issues <onnadi3> So, first point: "What exactly is a "service" anyway? (Better term...)" <lemmy> a minute... I'm in voip call currently. <onnadi3> Oh...sorry <lemmy> no problem <lemmy> remy: you're with us? * soulreaper has quit (Read error: 104 (Connection reset by peer)) <rcjsuen> yes <lemmy> great <lemmy> onnadi3: first point is about deciding if a service needs an identifier. for that we should know what a "service" might be <lemmy> Suppose plug-in A wants to discover a JDK and calls discovery. plug-in B wants to discover a JDK too, but how would discovery know that it can return the results from the previous run. <onnadi3> lemmy: Services can be binaries, or ports where a daemon is listening <lemmy> that sounds pretty much like a technical description of a service. <lemmy> s/that/this <onnadi3> Hmmm, if we assume for the moment that plug-in A does not care about version, then the name of the binary can be its identifier <lemmy> Will this work for a daemon running on a remote host? <lemmy> You don't have a name and only a simple port number. <onnadi3> Hmm, that was why I tried using URIs in my sample implementation. That way, we're not restricted to only local binaries or ports <lemmy> What about URIs and versions? <onnadi3> That's a bit trickier <onnadi3> IIRC, GNU Autoconf somehow doesn't bother about version numbers <onnadi3> It only tests for features <onnadi3> And that's kind of what I would like to do also since it will simplify matters a lot <rcjsuen> No, autoconf can check versions <lemmy> Also if I create a JAVA5 project, I want Eclipse to suggest only >=JAVA5 JDKs <onnadi3> true true <lemmy> or foundation 1.0. ;) <onnadi3> :-) or that <lemmy> Btw. foundation 1.0 makes it even more complicated because it represents a group of possible jdks. <rcjsuen> Well, there are no URIs in F1.0 anyway. <onnadi3> Yeah. But we can still use logical URIs <onnadi3> But I guess the main problem is...how to detect version? <lemmy> detecting a version is really specific to a binary. <lemmy> I'd assume it is something specified by a consumer. <onnadi3> Do you know how Autoconf does it? I'm rebrowsing their docs right now <onnadi3> but...how would that help GNU Autoconf find the bin? I'd hope they didn't call <binary> --version <rcjsuen> Well, not everything has a binary, so that wouldn't make sense. <onnadi3> Yeah. And i think if you ant to add a test for sthg it doesn't know about, you have to write the test yourself <rcjsuen> Define "doesn't know about" <onnadi3> Well, let's say configure only knew how to detect JDKs, then if you wanted it to detect GCC, you'd have to write your own test for GCC <onnadi3> I think <rcjsuen> hm <lemmy> configure shouldn't know how to detect jdks. It should know how to discover a specific resource with given attributes. <lemmy> a consumer passes those attribute to configure to utilize the discover facilities. <lemmy> discovery facilities could be a registry finder, a fs finder, a port checker... <lemmy> the consumer would know how to use these finders to find what he needs. <lemmy> my point about a service identifier is to have a globally valid identifier for a given service/resource. <lemmy> however there is a problem. if a second consumer tries to discover a certain resource that has already been identified and discovery would just return already known results, it might miss resources which would have been discovered because of much better heuristics by the second consumer. <onnadi3> Will it be possible to assign a unique identifier to every program? <lemmy> Would be great if we would already have such identifiers. <lemmy> Or at least a schema by which we could generate reproducible identifiers. <rcjsuen> lemmy: Hm, that's an interesting scenario <lemmy> rcjsuen: a simple and stupid solution would be a "force" flag to always rediscover even with previous results. <lemmy> Having identifiers also allows for consumers to not provide discovery rules. They would reuse already exiting discovery rules without shipping them. <lemmy> shipping/including... <onnadi3> So I guess the main problem now is how to incorporate version information into the "service" name in a standard way <onnadi3> Most (though not all) program I know use an increasing numerical scheme for versioning so maybe all we have to do is concat the binary's name with its versio <onnadi3> Then we ca ntell if one version is greater or less than another <lemmy> Or have an identifier class with names and versions. ;) <lemmy> However, implementation doesn't really matter, does it? <lemmy> yet <onnadi3> Well...I was trying to make it general enough to also encompass ports (which do not have version information) <lemmy> The port doesn't, but the service behind it. :) <onnadi3> Wait. That's not true. There might be different versions of processes running at the same port <onnadi3> :-) <lemmy> For my web project I need Tomcat 5 and not 4. :) <onnadi3> Hmmm, so I guess it all boils down to finding binaries <onnadi3> Whether hidden behind an fs, or a port <lemmy> Though we are talking pretty much about semantics of discovery results. Might it be more reasonable to provide a broad collection of finders and the consumer provides the semantics instead? <rcjsuen> I don't think that's unreasonable. <onnadi3> OK. So as you said earlier, discovery provides libraries for searching the fs, ports, registry etc. for whatever it is a consumer is looking for <lemmy> Well, those are just my thoughts. :) <onnadi3> They're good thoughts. I like the idea <onnadi3> We just have to solve the little details now <lemmy> normally the details bite us in the a** <onnadi3> We got all summer to get used to it :-) <lemmy> so we will file having service identifiers as should but currently as too hard to implement and move on to the next thing? <lemmy> like we've done with validation. <onnadi3> Well, i was thinking of defining service as sthg like "any resource that can be identified by a URI" <onnadi3> (implementation of URI may vary) <lemmy> I'm a little bit short on time currently, but maybe we can open a list on the wiki with "must", "should" and "nice to have" to keep track of the features? <rcjsuen> Yes, probably better to move on. We don't want this meeting to on forever on this thing <onnadi3> Alrighty <onnadi3> Next point, "Extension Points vs. OSGi (declarative?) services" <onnadi3> Do y'all think it is worth it to write custom tools for dealing with OSGi services? <lemmy> first of all, we don't need to decide "either/or". We can use both. <onnadi3> Well, I thought the only place we need them is for connecting customer plugins with Discovery <onnadi3> And once we're using XPs, there won't be any need for OSGi services <lemmy> XPs? <rcjsuen> eXtension Points <lemmy> What's wrong with EPs? ;) <lemmy> XP is already used by extreme programming. :) <lemmy> ...in my head that is. <rcjsuen> lemmy: same <lemmy> onnadi3: writing service doesn't really require tooling (maybe for declarative service it does though). <onnadi3> Yeah. For declarative services...so you don't think we'll need dynamic discovery of system resources aka Services? <lemmy> My only point is, that EPs have more dependencies whereas OSGi services are pretty low level. <onnadi3> What kind of dependencies? <onnadi3> (I'm not attached to EPs. I jsut want whatever is simplest) <lemmy> Using services for low level API might therefore be useful. For high level EPs are a better fit. <rcjsuen> onnadi3: Well, a lot more people are familiar with extension points anyway. <lemmy> I'm just aiming at this provisioning angle... <lemmy> In provisioning you might not have access to org.eclipse.* <rcjsuen> looks like org.eclipse.equinox.common, runtime_registry_compatibility.jar, org.eclipse.equinox.registry <rcjsuen> org.eclipse.osgi.services, org.eclipse.osgi <lemmy> org.eclipse.osgi? That's new to me <lemmy> Is it the plug-in or package name? <rcjsuen> well, bundle symbolic name is org.eclipse.osgi <rcjsuen> but sure there are org.osgi.* stuff and also org.eclipse.osgi.* stuff <lemmy> I'd suggest to hook the finders to the base discovery via services and offer services and EPs to consumers. <lemmy> This would certainly require another plug-in on top of base discovery that encapsulates EPs. <lemmy> http://www.skrbl.com/44702430 <onnadi3> what do you mean encapsulate EPs? Wouldn't I just provide the Extension Points and then consumers can write extensions for them? <lemmy> bear with my terrible first grade painting skills. :) <lemmy> "EP connector" is necessary so that base can be used in a pure OSGi environment. <rcjsuen> I see your point. <lemmy> Maybe this is overengineering. <lemmy> however foundation 1.0 already leads the path in this direction. <onnadi3> lemmy: Could you please explain what provisioning does? I didn't really understand their Wiki page <lemmy> I don't think their use cases have been fixed yet. : <lemmy> Simplified it deals with bringing Eclipse to the customer. <lemmy> Eclipse in this context doesn't mean the SDK. <lemmy> But software components (== bundles == plug-ins) in general. <lemmy> One of the goals of provisioning is to redo the UpdateManager. <lemmy> And to get rid of "features". ;o <onnadi3> So its just a reimplementation of parts of Eclipse?? <rcjsuen> Except something-not-named-features-but-acts-just-like-features will probably remain. <lemmy> *g* <onnadi3> Well, if provisioning is important enough then we might as well use OSGi services and EPs <lemmy> It is up to us how important we rate them. I tend to rate fundamental facilities very high though. <lemmy> But this isn't carved in stone <lemmy> onnadi3: I feel like you dislike services? ;) <lemmy> s/I feel/It feels <onnadi3> No, I don't. They seem a bit more straightforward than EPs <onnadi3> You simply call a method to register your bundle. that's it <onnadi3> But in sum, I'm worried because I don't understand what Provisioning is good for but it sounds like it is worth the effort to use services and EPs * rcjsuen__ (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc <lemmy> We might want to bring Pascal into the discussion. <rcjsuen__> My connection problems are kicking in. <lemmy> :( * benny`work (n=benny@eclipse/developer/Technology/bennywork) has joined #eclipse-soc <onnadi3> rcjsuen, rcjsuen__:There're are two of you :-) <onnadi3> Anyway, I think we've kinna beaten this topic to death. We should probably go with OSGi and EPs for now, and then if necessary, revisit the issue <lemmy> I agree, and at first the effort for correcting our decision isn't to high. <lemmy> too <lemmy> Speaking about IRC connection problems, I could offer both of you an account for my IRC proxy. This should solve your firewall problems too, since it runs on 57000 <onnadi3> that would be nice <lemmy> It keeps a buffer of the last n lines so you don't miss anything while you're disconnected. <lemmy> onnadi3: OK, I'll set it up then. <lemmy> Lets stick to the organizational topics, they seem to be easy. :) <onnadi3> And on that note, we can move to " - Rules Engine <onnadi3> - DSL vs. Rule Engines vs. anonymous Classes <onnadi3> - JSR94 (http://jcp.org/en/jsr/detail?id=94)" <lemmy> onnadi3: what about syndicating your blog on the planet? <onnadi3> I already posted a bug report about it but I don't think anyone's looked at it yet :-( <rcjsuen__> onnadi3: Number? <lemmy> Great, so it should appear soon. <rcjsuen__> lemmy: did you talk to Gunnar/Chris directly or something? <lemmy> By meeting minutes I mean that we should try to summarize our meetings and post those to the mailing list/wiki. A simple chat log is way to verbose for outsides to read. <lemmy> Chris is currently on the road which might be the reason for the delay. <lemmy> If it isn't syndicated on Monday, we should ping them directly. <rcjsuen__> I was talking to Chris last night on Sametime <rcjsuen__> I think he was in the airport maybe or something <lemmy> rcjsuen: so you will take care of that issue? :) <rcjsuen__> lemmy: if onnadi3 gives me the bug # <lemmy> I don't have Sametime. ;) <lemmy> rcjsuen: I'm sure this can be arranged. <rcjsuen__> or i guess technically i don't need the bug # i can just give him the blog link <onnadi3> I'm searching for it.... <rcjsuen__> but better that way since he can then resolve that bug <rcjsuen__> lemmy: i will ST him next time i see him and asusming he's not busy <rcjsuen__> he's a busy guy after all o.O <lemmy> who isn't these days. <onnadi3> Uh...do y'all know how to search for only bugs posted to PlanetEclipse? <lemmy> I have a suggestion as a first milestone due next week: Implement a simple fs finder connected to org.eclipse.discovery via a service. An exemplary consumer utilizes this finder to discover JDKs. :) <lemmy> Next week meaning 06/09. <lemmy> Including the CVS cleanups. <onnadi3> I can do that. <lemmy> Might make sense to implement the consumer in form of some JUnit tests. <onnadi3> I'm not sure about the consumer part...since that will require extension points and I don't know when exactly my book will arrive next week <lemmy> So we get around the Drools discussion this time. ;) <lemmy> onnadi3: Use a service or just simple method calls for the moment. <onnadi3> okey-doke <onnadi3> Could you please give me an example of what the tests would look like? <benny`work> hi guys <onnadi3> the junit tests <lemmy> After all org.eclipse.discovery is supposed to provide EP _and_ services. <onnadi3> benny`work: hallo <benny`work> hi onnadi3 <lemmy> JUnit might be tricky since you don't know the fs content where the tests get executed. <lemmy> Hi Benny <benny`work> hi markus <lemmy> You don't really know how many JDKs to expect. <lemmy> Might be possible to mock the content of the fs somehow. <onnadi3> I think I can do it as org.eclipse.discovery.examples instead <lemmy> renaming/moving is never a problem. We have great tooling at our disposal. ;) <lemmy> for the meeting minutes I suggest to rotate the burden. who wants to take care of this meeting? :o <onnadi3> rcjsuen: I refiled the bug. Its #190652 <onnadi3> lemmy: I can do it all. Old meeting logs are here http://wiki.eclipse.org/index.php/Auto-conf_meeting_logs <onnadi3> So should we move on to the DSL vs. Drools or figure out TagSea first? <lemmy> dunno, maybe we can keep drools for next week. * _rcjsuen (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc <lemmy> Btw. by meeting notes I'm talking about a summary instead of just a chat log. <onnadi3> oh. ah. >_rcjsuen< don't you wanna use the proxy I've offered you? <_rcjsuen> Well, that was painful. <onnadi3> Three rcjsuens!!! * rcjsuen has quit (Read error: 110 (Connection timed out)) >_rcjsuen< don't you wanna use the proxy I've offered you? <onnadi3> Alright. We could rotate the responsibility but I don't mind doing the chat logs and the summaries <lemmy> Perfect :) <onnadi3> I'm getting paid big bucks to do it, anyway B-) <lemmy> TagSE is just an idea how to make the code easy to understand for Remy and me. Check out the website and decide for yourself if it makes sense after all. I haven't used it yet. <_rcjsuen> I've looked at TagSEA. <_rcjsuen> Never used it, but have seen a 5-10 minute demo. <onnadi3> It seems to me like we should start with Javadoc and move to TagSea if we find deficiencies. I'm not sure what TagSea will really accomplish for us * onnadi3 has quit (Read error: 104 (Connection reset by peer)) * rcjsuen__ has quit (Read error: 110 (Connection timed out)) * onnadi3 (n=chatzill@mississippi-lnx.cc.gatech.edu) has joined #eclipse-soc <onnadi3> lemmy: Could you please save your chat log? I think you're the only one with the complete thing now <lemmy> Sure, I'll send it to you <onnadi3> danke <lemmy> bitte >_rcjsuen< Are you going to use the bouncer? Otherwise I would reuse your account. * onnadi3_ (n=chatzill@luke.cc.gatech.edu) has joined #eclipse-soc <onnadi3_> rcjsuen, lemmy: Sorry guys <onnadi3_> Have you guys made a decision on TagSea? <lemmy> the decision is yours to make. :) <onnadi3_> cool. I vote that we use Javadoc and if you guys find my commenting illegible, then perhaps we can move on to TagSea... <lemmy> fine * rcjsuen__ (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc <onnadi3_> Next up, "- QA/Testing (Unit/FIT)" <onnadi3_> What does FIT mean? <lemmy> functional tests <onnadi3_> howzat different from unit tests? <lemmy> It is. You might wanna read up on that one. :) <lemmy> Lets reschedule this one for next week too. My head is empty atm. <onnadi3_> Alright <lemmy> I'll go for some R&R soon. Maybe have a nice cocktail too. ;) <onnadi3_> lemmy: Could you just explain what " - IRC presence (bouncer/proxy)" this is so we know whether to shelve it too? <lemmy> It's this IRC proxy thingy we've already talked about. <onnadi3_> (Ah...that's why you want to move everything to next week ;) ) <onnadi3_> oh OK <lemmy> One reason, also because my battery is nearly depleted. <lemmy> Good night everybody <onnadi3_> okey-dokey. Could you please send th eupdated logs