|
Hello guys,
A bit of an out of topic e-mail for you to ponder on. Then again, maybe not that much out of topic.
I’ll start with two observations: - there are a lot of software which duplicate functionality - it is hard to reuse software or integrate with other software
The first observation is obvious, type a keyword on freshmeat or sourceforge and see how many programs already claim to do it. The second is also true, a lot of time, I would have like to use an editor that I liked but couldn’t use it for only an edit pane.
What I’ll describe next is (I think) already possible with Java. Although, that is more a theoretical point of view then a practical one.
As a developer, I’d like to be able to do the following: when I check-in code inside a repository, I’d like a little pop-up window to show up asking me which requirement I just coded for or which bug I just fixed. It would also asked how many hours I worked on it, etc. In the case of a requirement being coded for, the system would associate the files being checked-in as part of that requirement. In the case of a bug, it would mark the files (or the diff on the files) as part of the fix for the bug. The diff on the fix could be reviewed by a dev lead (I do commercial software and we need some structure when we develop). The hours worked on could be used to update the timesheet and the project plan.
Now, the above is wishful thinking (on a Windows platform at least) until something like the following exists. Instead of using CORBA, COM or other component based interfaces (works great for embedded tasks, but not for external tasks), I’d like my software to be able to do the following: - ask the system which software does “requirement tracking” for that user. - Send a basic “requirements assigned to user X request” to that software (or alternatively, just send the request and see if at least one software received it, this alternative removes the step above) - Get basic results. - Send a basic “get assigned bugs to user X” request - Get the result, - Etc…
The idea is that software only need to implement a set of basic functionality to interoperate with other software, anything more advanced would have to be done through another set of calls (direct calls like CORBA or COM or …) or directly using the software.
How is gnome (and mono) working to help me with this? Time tracking, is one of the most basic activities, yet it could potentially benefit from accessing the calendar of someone, the bug tracking system, the requirement tracking system, etc. I think JMS and JINI can sort of do that now.
Anyway, I’m sure I’m missing something basic (like reading the proper documentation) which would explain to me why it seems that GNOME or KDE do not have a set of basic program interfaces. The basic interface would define a set of basic functionality that has to be present on a program of type X to be part of KDE or GNOME as a X program. An image converter must implement functionality A,B and C before it can be registered as an image converter inside Gnome or KDE.
That would help in my programming, cause writing a program which reads/writes an image is always a bitch. Case in point, I had to do one recently. ImageMagick changed so much in the two years I stopped playing with my program that it required a re-write. The C++ interface for ImageMagick lacked the basic ability to create an image from memory… I reverted to the C implementation. Before I did that, I looked at libpng, the gnome image library, etc. They all seem so hard to use (lots of setup to do)
A program with the following lines would have been bliss
ImageConverter converter = new ImageConverter( (ImageConverter)System.Gnome.ImageConverter); converter.create(“image.png”,memory,ImageMapping.RGB8,rows,columns);
All this to ask, would mono help in the creation of those basic interfaces? I think Gnome knows what are the basic applications (the set can be changed over time) like calendar, bug tracking, word processing, calculator, etc. Mono could act as a pro-active leader in this and define a set of basic and minimal functionality that a program needs to implement to be called a calendar or an e-mail client or …
They could all have basic functionality pre-defined for each type of application. Just to start with inter-operability, no?
Phil
PS Sorry about the above, I’ll need to get some more coffee and the future of software will look all bright and shiny. |
