First, I'm thrilled to see Anton's proposal. It really helps to have a
specific roadmap for the project. I would suggest that, out of this
discussion, we add some specific feature requests to the SourceForge
tracker, so that we capture action items that we intend to do.
On Fri, 2009-12-04 at 15:30 +0300, Anton Pak wrote:
> We prepared a document trying to outline possible OpenHPI roadmap.
> It is not an ultimate one but aims to start a discussion in community.
> Please review and provide your comments, thoughts and other proposals.
[...]
> HPI-B.03 Support
I'm not close enough to comment, but the list looks good.
> Improvements in HPI Clients
Ditto
> Native Windows HPI Client Library
[...]
> * Keep the same source code base or separate ones?
I'd hate to see us having to maintain two copies of the source. I
strongly suggest a single code base.
> * The source code is written using C99 standard. Microsoft
> compiler still does not provide C99 support. It looks
> reasonable to adapt the source code to C89 where it is
> possible.
I don't object to this, especially if it doesn't make too much of a mess
of the code. It might also be #ifdef'd where necessary.
> New HPI Clients
> * There are client utilities for DAT, DEL, Sensors,
> Inventories, Watchdog. It is reasonable to have more
> client utilities to cover Controls, Annunciators, DIMI,
> FUMI. May be more additional stuff needed.
Where people have interest, it's great to add new clients. My input,
though, is that these are only example applications, not necessarily
tools intended to replace the user's own applications. I would not
prioritize effort on these above functionality of the base library. I
would, though, suggest that if a client application is not doing things
correctly (from an HPI standpoint), it should be fixed. As an example
program, we hope people will take code from these for their own HPI
application, and we should be setting good examples.
> Reorganization of Source Tree
>
> It seems that over the ages the file structure of the
> source tree has become tangled.
>
> There is src directory that contains files for OpenHPI
> daemon and HPI client library. Also there is openhpid
> directory that also contains files for OpenHPI daemon
> and HPI client library. Even more, some files from
> openhpid are symlinks for the files in src!
>
> Idea: Untangle files into two directories openhpid and
> lib or hpilib or userlib.
Agreed. Probably should be done in a development trunk (e.g 2.15.x)
rather than a release stream (2.14.x).
> Long Term Topics
>
> Status of UDP Transport
[...]
> * Remove it
This would get my vote.
> pyOpenHPI
>
> There is still no user feedback on this OpenHPI part.
> Investigation has to be performed to assess its
> necessity and to plan its future. May be there is an
> interest in other client interfaces (i.e. Perl, Java
> or .NET).
My suggestion is to let it sit. If someone wants to use it, perhaps
they can volunteer the resources to maintain it. If nobody steps
forward, then it can be pruned from the tree in the future.
At the point we decide that it no longer works (because of changes to
the project), we could mark it as unmaintained and move it to another
part of the project tree.
> Simulator Plug-in
>
> Several proposals for simulator plug-in:
[...]
These are all good ideas. I would support inclusion of any of these
features (or even other features) as long as someone has enough interest
to code them up and submit them. The only thing I'd ask is that the
submitter make at least a short-term commitment to support the changes,
so that we don't break things.
> Sysfs Plug-in
>
> Seems that sysfs structure was changed and OpenHPI
> supports old fashion only.
Suggest that those who care submit patches/enhancements? If nobody uses
it or cares, then it could be removed (or moved to an unsupported
branch).
> Documentation
>
> OpenHPI documentation currently is sparse and incomplete.
> There is no Detailed User Guide, Architecture document
> and Guide for plug-in developers. Work in this area needed.
I have an interest in this area, but cannot fix it all myself.
We used to have an open feature request to move the documentation from
the source tree to the OpenHPI wiki. Once there, we believed it had a
better chance of being maintained. Somewhere along the line, I think
that feature request got closed or removed. Unless there is objection,
I'll add that request and try to work on this part of the documentation
issue.
I'm hoping that once the documentation is on the wiki, more people will
be motivated to update it. In Renier's (past project admin) words,
"[documentation] is...a vital ingredient for an active community. So I'd
make that a priority."
One other comment about the wiki: It was never the intention to have the
wiki be closed to contributions by the OpenHPI community. It was set up
as a self-registered device. However, spammers began to use it for
their own purposes, so write access was removed. Any member of the
OpenHPI community is welcome to write access. Please send me your wiki
ID, if you'd like this enabled.
> Native Windows OpenHPI
>
> This task is harder than previous one and not investigated
> yet. One need to collect user needs for it.
>
> HAL, UDEV, Device Kit…
>
> These layers provide abstracted view to the system hardware
> resources. Shall OpenHPI provide specialized plug-ins to use them?
I think the above are only limited by someone interested enough to
implement and submit a patch.
Bryan
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
