Dashboard/konfabulator for Linux and firefox: "The 'killer feature' in Dashboard and konfabulator is (IMO) the ability to integrate a web-like interface with the OS. This opens the way for a lot of ideas in making Linux easier to use - for 'regular users' but also for advanced users who feel more comfortable using the browser than typing ( and remembering ) complex command lines.
The implementation for firefox of a 'system/exec' feature similar with dashboard and konfabulator is not trivial, but not that complex. As I mentioned in a previous post, the async execution is the tricky part, but it has a reasonably straight solution. I'll try to find a server and post the sources - I'm sure there are better implementations using the event queue, but it works well enough for me.
Now the remaining part is dealing with installing and running 'widgets' in firefox - and exactly emulating the interface. I'm not expecting Dashboard widgets to work unmodified, but with small changes. Konfabulator has an simpler interface, but it's not HTML-like, I'll only see if I can implement a similar API for simpler transition.
This has been a very interesting mini-project for me - I found a lot about how firefox works, and I hope it'll serve it's purpose and I'll be able to reduce my use of CLI and have a nicer interface for the linux commands I use. Even if some already have"
Friday, October 07, 2005
A different implementation for commons-logging
Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging. It is also one of the not-so-good APIs or implementations.
The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.
An alternative - that will work better in most cases - is to write a specific commons-logging implementation for each backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.
The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic">A different implementation for commons-logging: "Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging. It is also one of the not-so-good APIs or implementations.
The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.
An alternative - that will work better in most cases - is to write a specific commons-logging implementation for each backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.
The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic"
The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.
An alternative - that will work better in most cases - is to write a specific commons-logging implementation for each backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.
The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic">A different implementation for commons-logging: "Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging. It is also one of the not-so-good APIs or implementations.
The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.
An alternative - that will work better in most cases - is to write a specific commons-logging implementation for each backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.
The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic"
Subscribe to:
Posts (Atom)