felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dieter Wimberger <die...@wimpi.net>
Subject Re: telnetd discussion
Date Fri, 27 Jun 2008 05:58:07 GMT

> Let us know if we can help.

Sure, as soon as I can find time to proceed with it and run into  
something where I need help.

>> Richard:
>> Honestly, I actually put together the telnetconsole bundle because  
>> I didn't want to "cripple" telnetd-osgi into something that's no  
>> longer useful for a generic purpose. E.g. trying to figure a way  
>> around installing the configadmin bundle just doesn't make much  
>> sense to me when you need to configure it anyway.
> Dieter, I understand your concern, but perhaps I didn't explain the  
> proposal very well. We weren't discussing something that would  
> "cripple" telnetd-osgi, in fact the proposal was more about how it  
> should be packaged.
> The proposal was to package it with the needed commons classes and  
> probably the CM interfaces, thus it would be self-contained. By  
> doing this, we make it possible to use it without CM (i.e., CM would  
> be optional), but this will require no changes to telnetd-osgi  
> functionality, it will still register a ManagedFactoryService like  
> normal and everything will work exactly like it does now.
> The only difference is that by packaging it in a more self-contained  
> way, a CM impl is not necessary and clients can inject their own  
> configuration directly (i.e., with no CM impl available), thus  
> reducing the dependency for those that don't need it. This would  
> actually be possible even if a CM impl was present, unless you  
> turned on security and forbid bundles from accessing the  
> ManagedFactoryService.
> So, no crippling intended, just more "generic" flexibility. Hope  
> that alleviates some of your concerns. We certainly aren't trying to  
> run away with your project. :-)

Right. First of all, I wasn't really worried that you'd run away with  
anything :) I wouldn't do open source if I had such fears.

I think my concern was more a practical one; even it if it is  
packaging, somebody has to do it, and the sources have to be in some  
place. Somehow, I was thinking of a way to avoid the need to maintain  
too many versions of it at the same time (well not that there is much  
maintenance for the pre-OSGi ones anyway).

I am trying to help out, but I am also trying to keep my time and  
effort investment on a line where goals coincide. Honestly, I didn't  
understand well what your goal is and probably it was a little bit  
precipitated to assume I'd got to take responsibility for it already >)

So how would you suggest to proceed about this special packaging?

>> 1. get the telnetconsole bundle into Felix (project):
>> This should be straigthforward, but see the comments I made to  
>> Felix (M.).
> Agreed, we have to look into it.


>> 2. iron out the problems with the telnetd-osgi and figure a way to  
>> have some of the extensions (I am using the templates extensively  
>> to generate output on a shell).
> Ok.
>> There is still the possibility to have it inside or outside of  
>> Felix (project).
>> From my point of view, I would at least suggest not to try and  
>> "cripple" it (i.e. this translates into: I won't do it, but the  
>> code is open source, and available since more or less 2 years, so  
>> anybody is welcome ;).
> Since it is just a packaging issue, we could easily do this with the  
> maven bundle plugin.

I've got to understand better what you are trying to do. Maybe you or  
Felix find time to forward the analysis you have mentioned earlier?

>> 3. provide the glue bundle I wrote (essentially a shell that is  
>> hooked into telnetd-osgi).
>> This should rather be part of Felix (project). There is only my own  
>> source and all it needs is some Maven magic to build it "the Felix  
>> way".
> Yep.

Great. I get up the sources asap.


View raw message