Jnode Information FileSystem

Submitted by Trickkiste on Tue, 09/14/2004 - 19:28.

Hi,
within my student thesis I had to implement a virtual filesystem for JNode.
This jifs (thats the name of it) provides information about the state of JNode in a structure similar to the /proc filesystem (folders / files).
The initial version provides information about plugins (dependecies, auther), threads (pririority, name, state), the state of the memory and the current uptime of the system.

What information do you want the jifs to provide?
Should it provide en extension-point for others to publish information through the jifs?

Andreas

‹ In ISO9660Directory, are names really not-case-sensitives ? Thoughts on more powerful filesystem sematics ›

thesis online

Submitted by Trickkiste on Fri, 10/08/2004 - 06:06.

Hi,


you can download the thesis from http://jifs.org/.

There are some screeshots too.

Trickkiste

thesis download

Submitted by mattzerah on Fri, 10/08/2004 - 07:00.

I would be interested in reading your thesis if you are going to make it available. Only thing is it looks like its not going to be in english, is this correct? Will there be an english translation? (im not expecting you to translate it, the last thing I wanted to do after i finished my thesis was to read it again, let alone do the work to translate it Smiling

I hope your thesis is going/has gone well.

Matt.

maybe I'll translate parts of it

Submitted by Trickkiste on Fri, 10/08/2004 - 10:29.

Hi,
if I have time, I will translate at least the part dealing with the jifs of the thesis.I don't have much time for it these days, but I'm looking forward to work more on it.

Andreas
P.S.: I have written the thesis in German language.

Why a FS

Submitted by admin on Wed, 09/15/2004 - 06:50.

Hi

Why should this be a filesystem.

Shouldn't it be an URL handler, something like

"get jifs://cpu_times" to show the CPU usage?

PS. Congratulations on your thesis.

Ewout

maybe it could be done like this

Submitted by Trickkiste on Wed, 09/15/2004 - 07:31.

Hi,
like many other things this task (to provide information) has several solutions.

But in my case I had different people, outside the JNode project, which superwised my work. I asked them to do something with JNode as student thesis and they decided to implement a filesystem for JNode (as one part of the thesis).
The decision for a non writeable virtual filesystem followed the fact that it is a student thesis, not a diploma thesis. So basicly the task was defined as filesystem.

I am sure that it is possible to write a URL handler that is somehow connected with the fs.

Trickkiste
P.S.: (I will provide the initial version for download later this week.)

Why Either

Submitted by objectiveP on Wed, 09/15/2004 - 14:25.

I understand that you have put in effort for your thesis, but I don't think either of these plans are right for jnode.

Both an fs and a URL handler will yeild an InputStream, which is to say, a byte[]. This byte[] will have to be interpreted as a specific type (formate) of data.

Would it not be (much) more oo to expose this data as a singlton class,
something like:

JnodeInfo.getCPUTimes();
JnodeInfo.getInstalledPlugins();

This design would allow for the return value to be of a known type.

Again, I understand that you have already put in a lot of effort for this, but wouldn't an oop aproach be better?

Selah

Sounds like a job for JMX

Submitted by enriquer9 on Wed, 09/15/2004 - 16:48.

This is what JMX is intended for. I would love to manage JNodes (plural) using standard JMX tools such as MC4J in the exact same way I currently manage Tomcat and JBoss servers. This means exposing management functions as methods. Then you can wrap what is exposed by JMX with your proc-view, as commands for a command line, or eventually get at them via JMX Remoting.

lets think more about it

Submitted by Trickkiste on Wed, 09/15/2004 - 16:21.

Hi,
in the first case I think a fs is better than an URL (protocol) handler, because there is already the file:// handler (so every file is reachable via an URL).

The other side is an oo aproach.
I agree that an oo aproach would be state of the art for an os like JNode.

I collected the information (which are in a well known format) from objects within JNode.
The goal was to show / provide this information in a way humans can understand them (There is no kind of object oriented machine human interface isn't it?).
The aproach of files/folders to solve this is well known from linux like operating systems (/proc).

Everytime someone decides to provide some additional information, there has to be changes in the system providing them.

If the jifs provides an extension point, which requests a FSEntry from the connected plugins, every connected plugin will be able to provide everthing in a well known format.
Maybe both (fs and a singleton aproach) are useful, but in different ways.
So I will think about a way to extend the jifs with an JIS (Jnode Information System).

Andreas