Re: [oscar-devel] OSGi 2.0 Spec Released

[Richard S. H. <he...@un...>]

Yann SECQ wrote:

> OK. I was thinking about rewritting the little GUI I had done to
> manage a container. The idea was to separate the model (and use the
> new ServiceTracker mecanism), and the GUI. Thus we could have some
> web-based GUI through the HTTPService, or a Swing GUI (or an AWT for
> 1.1.x) ... 


Make sense.  I was thinking about looking at the ServiceTracker service 
after the next release (which should include the PackageAdmin service).

> Yes, but this project doesn't seem to really active. They haven't
> yet released anything (or have I missed something ?). 


No, I just wanted to make sure you were aware of it.  :^)

> No, I don't agree. We could have both implementations 1.2 and 1.1.x for
> the classloading, and we could switch when starting the Framework. We
> can retrieve the VM version and create containers with the good class
> loader. 


Yes, you are correct, we could have both versions, but after thinking 
about it I probably wouldn't bother keeping both versions?  If I go 
through the hassle of creating a 1.1 class loader, I would most likely 
just throw away the 1.2 class loader, since the 1.1 version would work 
in both cases.  At this point, though, 1.1 compatibility is not as high 
of a priority as finishing the base functionality and starting the 
transition towards OSGi 2.0.

> I'm interrested in this feature as I've recently discovered a nice
> java powered enbedded platform called TINI (www.ibutton.com). It has
> some really nice features and I would like to make run Oscar on it.
> But, actually I don't have bought the card so we can see later :) 


Ahhh, IC.  Well, that puts the nail in that coffin.  ;^)

> I don't agree (again ;) : a container hasn't to be tied to a
> user profile. What a container need is an access to the filesystem
> (and the modifications you've done are great for this point).


This is actually where we disagree.  The container doesn't need access 
to the file system, it needs access to some sort of storage system that 
will give it access to its previously saved state.  I call this 
previously saved state a profile and a container must have a profile 
(i.e., saved state) otherwise it would not know what to load.

Clearly, there are other ways to implement this, but the current 
mechanism is quite simple and straightforward: the profile name is given 
to the storage system mechanism so that it can associate the saved state 
with the profile name for future reference.  Currently, the default 
implementation of the storage system mechanisms uses that profile name 
to create a directory, but a future storage system implementation could 
use that as a key in a database, for example.  The storage system is 
meant to be simple (for now).

This doesn't make the container "tied" to a profile, the profile is 
simply the persisted state of the container and it makes sense that 
there is a one-to-one mapping here.

> Then we could add an authentification/authorization bundle that
> would manage users.


I agree that we need some different mechanism for user management. 
 Don't get confused with the profile stuff, that really doesn't have 
anything to do with "users" per se.  One user could start a dozen Oscars 
each with its own profile...

> It would be
> more generic to provide an XML configuration file to populate the
> container on its creation.


More generic than what?  Oscar currently allows you to populate the 
container with a config file...I think that this is just as generic.  :^)

But this doesn't really have anything to do with the profile stuff, 
correct?  Profiles are persisted state and how container state is 
handled is pretty clearly defined by the spec.

Thanks for the input...for now it's just you and i...  ;^)

-> richard