You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(28) |
Feb
(35) |
Mar
(25) |
Apr
(2) |
May
(8) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(32) |
Dec
|
2003 |
Jan
(4) |
Feb
|
Mar
|
Apr
(6) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
(2) |
Oct
(10) |
Nov
(4) |
Dec
(6) |
2004 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(17) |
May
(89) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Richard S. H. <he...@un...> - 2001-10-18 19:05:12
|
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 |
From: Richard S. H. <he...@un...> - 2001-10-18 18:47:16
|
Yann SECQ wrote: > Anyway, there were really good idea around this notion of > abstracting the filesystem. Here is the link : > http://openide.netbeans.org/fs/Library.html > It would be interesting to look at this project, and as it is > OpenSource, we could retrieve some of their code (or even take the > whole thing !). Thanks for the pointer. I took a look at it, it seems nice but probably more ambitious that what I am shooting for (at least right now). I want to keep Oscar reasonably lean and the sole purpose of abstracting the storage mechanisms was to make it easy to put Oscar on top of something other than a file system; the interface abstractions I have created to do this are only sophisticated enough to perform the actions that Oscar needs to handle its persistent data, not to implement a full-blown file system abstraction. Of course, the desire to have something more sophisticated could change in the future as the need arises, and if it does, I would definitely process in this or a similar direction. > I don't know how they handled this problem within OpenFS, but > anyway I'm more concerned by design than performance. I think > we could work on this performance issue later, if it becomes a > real bottleneck. I agree...for now. :^) -> richard |
From: Yann S. <Yan...@li...> - 2001-10-18 14:09:28
|
Richard S. Hall wrote: >> What is the current state of the HTTP service ? > I haven't touched it since I first toyed with it. With my focus now > shifting back to the framework (and my lectures), it still may be a > while...although there are more people talking about putting in some > effort. 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) ... > Nice page. I assume that I have previously pointed you to: > http://fosgi.sourceforge.net Yes, but this project doesn't seem to really active. They haven't yet released anything (or have I missed something ?). > The biggest hurdle for running Oscar on JDK 1.1.x (off the top of my > head) is the ClassLoader changed substantially in JDK 1.2 and Oscar > leverages those changes; thus the class loading mechanisms would have to > be re-written. This is not the type of change that you can just support > both versions, so to get such support you would have to settle on the > common denominator which is 1.1.x class loading functionality. 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. 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 :) > Now, it is largely used for just a profile (notice the lack of a > password). The reason why this is still useful is because it allows me > to set up multiple profiles for different purposes (i.e., demos, > testing, etc.) rather than just assuming that there is only one > installation for the machine/user. This of course, also allows you to > have multiple Oscars going at the same time (either as programs or > instances). Further, it is only the OscarShell that asks for the > profile name and this could be handled differently for someone embedding > Oscar (such as I do in my Cibyl project which embeds Oscar and defines > its own profile directory). 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). Then we could add an authentification/authorization bundle that would manage users. I've updated a bit the webpage concerning this point : www.lifl.fr/~secq/thesis/gnosgi/osgi2.html. It would be more generic to provide an XML configuration file to populate the container on its creation. I already mentionned the OpenFS project and I really think we should look at it carefully. The only catch is that it doesn't seem to be really active, but as it is OpenSource we could take only what we need. Cheers, yann. -- / Yann SECQ Equipe SMAC se...@li... \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq / |
From: Yann S. <Yan...@li...> - 2001-10-18 09:57:32
|
Richard S. Hall wrote: > I have been working to get bundle update working for the next release of > Oscar. Along the way, I decided to abstract the way Oscar uses > persistent storage. That's a great move ! I watch a project some times ago called openFS. This project was initiated within the Netbeans project, sadly, it didn't go further. Anyway, there were really good idea around this notion of abstracting the filesystem. Here is the link : http://openide.netbeans.org/fs/Library.html It would be interesting to look at this project, and as it is OpenSource, we could retrieve some of their code (or even take the whole thing !). > Does anyone have any thoughts on improving performance or a better > approach for reading JAR file entries from an input stream? I do think > the re-design is nicer since it frees Oscar from requiring a file > system, but perhaps the performance loss isn't worth the price. I don't know how they handled this problem within OpenFS, but anyway I'm more concerned by design than performance. I think we could work on this performance issue later, if it becomes a real bottleneck. Cheers, yann. -- / Yann SECQ Equipe SMAC se...@li... \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq / |
From: Richard S. H. <he...@un...> - 2001-10-17 16:34:11
|
I have been working to get bundle update working for the next release of Oscar. Along the way, I decided to abstract the way Oscar uses persistent storage. It was my thinking that instead of tying Oscar to File objects, that I would create a simple set of interfaces that did not depend on File objects and instead used InputStream/OutputStream objects. The reasoning behind this is simple, the File object assumes there is a file system underneath Oscar and I thought that this might not always be the case. Therefore, by abstracting Oscar's storage mechanism, it would be easy to create different storage implementations, such as an "all-in-memory" one or one that used a database (perhaps for roaming profiles). So, I created these interfaces: * StorageSystem - provides access to the storage system; Oscar requires one for operation, a default file system implementation is provided. * StorageNode - abstract interface for a storage node. * StorageDirectory - a hierarchical grouping mechanism for the storage system. * StorageFile - used to get an InputStream/OutputStream for a storage system file. In all, these interfaces are very simple (i.e., they only have 2 to 4 methods each); the point is to keep them simple so they are easy to implement. Oscar has been modified to use this approach and everything is working as before, so I thought that this was a pretty good design improvement. Well, there is a catch. In the previous version of Oscar I was using the JarFile class to read from the bundle JAR files, but the JarFile class cannot be initialized using an InputStream only a File (most likely because it needs a random access file). As a result, I modified Oscar to load classes using a JarInputStream to read from the bundle JAR. This modification led to a noticable performance loss when loading classes because I must sequentially search the JAR file for each resource. In general, this is most noticable on start-up, but once classes are loaded everything operates normally. I tried to look at the JarFile code to see if I could figure out how to read the Jar/Zip index to speed up my searches, but those portions of JarFile are implemented in native methods. Obviously, I could look elsewhere for this information, but I am not sure if it is worth it. Does anyone have any thoughts on improving performance or a better approach for reading JAR file entries from an input stream? I do think the re-design is nicer since it frees Oscar from requiring a file system, but perhaps the performance loss isn't worth the price. Any thoughts? -> richard |
From: Richard S. H. <he...@un...> - 2001-10-16 18:33:06
|
Marcel Offermans wrote: >The exact same setup and bundles work in JES 2.0: my driver gets called >there. This is strange since bundles should not be dependent on a >specific server framework so JES's device.jar bundle should work. On a >related note, I found out something else. > Well, it does sound like it could be an issue with Oscar then. If you want you can send me (privately) the driver with instructions on how to repeat the situation and I can look into it on both JES and Oscar. >The specs state: "Exported packages from a bundle are available to other >bundles as soon as that bundle completes installation on the framework". >That state (as far as I understand) is the INSTALLED state. > Yeah, I wrestled with the meaning of this too...you obviously know how I interpretted it. :^) >Installing both bundles on Oscar and starting the device.jar works. If >you do the same on JES 2.0 it complains about the import. Starting and >stopping the log there leaves that bundle in the RESOLVED state. If you >then start device.jar, it works. > I like my way better. ;^) But seriously, though, this looks like it might have changed in OSGi 2.0, which states on page 26, "If the bundle's dependencies are resolved, all the packages declared in the bundle's Export-Package manifest header are exported to the OSGi environment." This appears to be a change, perhaps. I have gone through the framework portion of 2.0 and highlighted every place where it sounded like they refined the definition of some functionality. I expect to slowly incorporate these refinements in future releases of Oscar. >I'm not sure if this has anything to do with the device manager not >working in Oscar though... > I wouldn't think so, but you never know. -> richard |
From: Richard S. H. <he...@un...> - 2001-10-16 18:20:28
|
Yann SECQ wrote: > I'm happy with the Class and Collaboration Diagram, but I don't > understand why they didn't provide the sources for all org.osgi.* > interfaces .... From my understanding, you get them when you join OSGi (and a reference implementation)...that's not worth the $10k to me... > What is the current state of the HTTP service ? I haven't touched it since I first toyed with it. With my focus now shifting back to the framework (and my lectures), it still may be a while...although there are more people talking about putting in some effort. > I've also started to write some questions/remarks about the new > spec and Oscar. As it is growing with my readings, I've prefered > to write it on a webpage instead of posting a big mail on the > mailing-list (http://www.lifl.fr/~secq/thesis/gnosgi/osgi2.html). Nice page. I assume that I have previously pointed you to: http://fosgi.sourceforge.net Regarding some of your questions/comments on your Web page: The biggest hurdle for running Oscar on JDK 1.1.x (off the top of my head) is the ClassLoader changed substantially in JDK 1.2 and Oscar leverages those changes; thus the class loading mechanisms would have to be re-written. This is not the type of change that you can just support both versions, so to get such support you would have to settle on the common denominator which is 1.1.x class loading functionality. I am sure there are other more minor issues, like collection classes, etc. too. Regarding starting Oscar, you are actually giving Oscar a user profile name, not a user name...although I sometimes treat it as a user name (like in the Messenger bundle). The user concept is is a hold-over from the original project I was doing two years ago; the idea was that these components were going to provide services and would require some sort of "login" so it made more sense to unify it, rather than having each service have its own login procedure. Now, it is largely used for just a profile (notice the lack of a password). The reason why this is still useful is because it allows me to set up multiple profiles for different purposes (i.e., demos, testing, etc.) rather than just assuming that there is only one installation for the machine/user. This of course, also allows you to have multiple Oscars going at the same time (either as programs or instances). Further, it is only the OscarShell that asks for the profile name and this could be handled differently for someone embedding Oscar (such as I do in my Cibyl project which embeds Oscar and defines its own profile directory). That's my $0.02... :^) -> richard |
From: Marcel O. <mar...@es...> - 2001-10-16 14:00:32
|
The exact same setup and bundles work in JES 2.0: my driver gets called there. This is strange since bundles should not be dependent on a specific server framework so JES's device.jar bundle should work. On a related note, I found out something else. The device.jar needs log.jar; it imports a package that log.jar exports (I know there can be other "providers" of this package, but let's assume that these are the only two bundles we use). The specs state: "Exported packages from a bundle are available to other bundles as soon as that bundle completes installation on the framework". That state (as far as I understand) is the INSTALLED state. Installing both bundles on Oscar and starting the device.jar works. If you do the same on JES 2.0 it complains about the import. Starting and stopping the log there leaves that bundle in the RESOLVED state. If you then start device.jar, it works. I'm not sure if this has anything to do with the device manager not working in Oscar though... |
From: Richard S. H. <he...@un...> - 2001-10-16 10:04:59
|
Marcel, I personally don't have any experience with the DriverLocator, so I don't have any input on that matter. Since this may be more of a "usage" issue, you could try the "user" mailing list since (last time I looked), there were more people subscribed to that then this list for Oscar development. That being said, it is possible that this is a problem with Oscar. Is this something that works correctly under JES? If so, then perhaps I should have a look at your stuff to see if I can figure out where it is short-circuiting. -> richard Marcel Offermans wrote: >Can anybody on the list help me out with writing a DriverLocator. > >I have created a simple test case: > >1. I have registered my own DriverLocator as a service. >2. I have written a base driver that installs and uninstalls a device. > >I am using Oscar and the device.jar "Device Manager Service" from JES >2.0 and want my DriverLocator to be called whenever this new device is >registered so I can add a refining driver. > >The problem is: my DriverLocator does not get called at all! > >Obviously, I am forgetting something. I can post the source if >necessary. > > > >_______________________________________________ >oscar-osgi-devel mailing list >osc...@li... >https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > > |
From: Marcel O. <mar...@es...> - 2001-10-16 09:58:16
|
Can anybody on the list help me out with writing a DriverLocator. I have created a simple test case: 1. I have registered my own DriverLocator as a service. 2. I have written a base driver that installs and uninstalls a device. I am using Oscar and the device.jar "Device Manager Service" from JES 2.0 and want my DriverLocator to be called whenever this new device is registered so I can add a refining driver. The problem is: my DriverLocator does not get called at all! Obviously, I am forgetting something. I can post the source if necessary. |
From: Yann S. <Yan...@li...> - 2001-10-12 16:21:15
|
Richard S. Hall wrote: > From what I can see, the LogService is pretty much the same. Yes, it shouldn't require a lot of work. > I can't say that I like the format of the new specification, though, > because it makes it awful hard to see the class/interface definitions > (since they no longer include JavaDoc format). I'm happy with the Class and Collaboration Diagram, but I don't understand why they didn't provide the sources for all org.osgi.* interfaces .... > I think I will work on the PackageAdmin service for the next release of > Oscar; that way I can get bundle update working once and for all. That's a big piece. I've started the writing of the interfaces for the ServiceTracker utility. If I have some time I'll go on with the others non-Admin services (Metatype, Preference ...). What is the current state of the HTTP service ? I've also started to write some questions/remarks about the new spec and Oscar. As it is growing with my readings, I've prefered to write it on a webpage instead of posting a big mail on the mailing-list (http://www.lifl.fr/~secq/thesis/gnosgi/osgi2.html). Cheers, yann. -- / Yann SECQ Equipe SMAC se...@li... \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq / |
From: Richard S. H. <he...@un...> - 2001-10-10 13:05:20
|
Yann SECQ wrote: > Well, I'm currently printing the specification to know exactly > what's going on with this new version, but I could be interested > with some of them. I've started an implementation of the LogService, > but I'll check the newx version to see if something as changed. From what I can see, the LogService is pretty much the same. I can't say that I like the format of the new specification, though, because it makes it awful hard to see the class/interface definitions (since they no longer include JavaDoc format). I think I will work on the PackageAdmin service for the next release of Oscar; that way I can get bundle update working once and for all. -> richard |
From: Yann S. <Yan...@li...> - 2001-10-10 12:38:21
|
Richard S. Hall wrote: > OSGi released version 2.0 of the OSGi specification this last week, so I > thought I would make a few comments and let everyone know what's up. Hi Richard, the specification is out and the web site has been redesigned ! (Much better now even if available informations aren't really usefull ...) > The good news regarding the new 2.0 specification is that the changes to > the framework do not appear to be severe. Good design => easy upgrade ;) > Of course, that still leaves the other services to be implemented and I > doubt that I can create them all in a reasonable amount of time, so if > someone has a particular service they are interested in developing > perhaps you could contact me. Well, I'm currently printing the specification to know exactly what's going on with this new version, but I could be interested with some of them. I've started an implementation of the LogService, but I'll check the newx version to see if something as changed. Cheers, yann. -- / Yann SECQ Equipe SMAC se...@li... \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq / |
From: Richard S. H. <he...@un...> - 2001-10-08 13:14:06
|
[Sorry if you receive this multiple times because I am posting to the devel and user mailing list.] OSGi released version 2.0 of the OSGi specification this last week, so I thought I would make a few comments and let everyone know what's up. As most people know, the OSGi specification is broken into two parts, the OSGi framework and the OSGi services. With Oscar I have been focusing on the framework portion, but the goal is to eventually include service implementations as well. The good news regarding the new 2.0 specification is that the changes to the framework do not appear to be severe. Some of the more significant changes are: * A "system" bundle was introduced for framework services (Oscar already has the same thing, although I called it the "container" bundle). * The elimination of "eager bundle update", which means that updating a bundle should NOT make the updated classes/resources immediately available. * Bundles can now have optional contents (e.g., documentation or source code) in their jar file. * Event delivery is now asynchronous except in certain cases. * A few classes and methods were added. In addition to these framework changes, some new services that are intimately tied to the framework implementation were added as well; these include: * Package Admin Service - enables management of package sharing (i.e., refreshing after an update). * Permission Admin Service - enables management of bundle permissions. * Service Tracker - enables management of service dependencies. * Configuration Admin Service - enables management of bundle versioning. Clearly most of the effort in shifting Oscar towards OSGi 2.0 will go into creating these framework-oriented services. In most cases, these services are already implemented in Oscar in some fashion and in other cases they actually make sense to have, so the effort seems justified. Of course, that still leaves the other services to be implemented and I doubt that I can create them all in a reasonable amount of time, so if someone has a particular service they are interested in developing perhaps you could contact me. I am hoping to make progress on Oscar this Fall after a two hectic months of traveling and the various travails that have befallen the world. I plan on posting some issues to the developer mailing list shortly in order to get some feedback and get back to work. Cheers, -> richard |