I'm absolutely with Bryan. Thanks to Anton.
Below are only some small remarks to the simulator, clients, code tree and
documentation.
Regards
Lars
On Monday, 7. December 2009 21:50, Bryan Sutula wrote:
> 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.
>
But we should also think about it, that the clients are the first address to
work with hpi-b. What I mean is, if somebody verify HPI-B to use it in an own
product, the first thing will be to start some clients and look how it works.
- It's something like a visiting card.
Furthermore they are needed to get information if a failure / unexpected
result happens in an openhpid installation. Not each customer will write an
own application for this purpose but using openhpid as it is.
My question is if the hpishell as the all-in-one client is enough? I have the
feeling that the hpishell is much more maintained than the other clients?
> > 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).
>
Only an additional remark: There is also a cpp directory. Could it be that
this is "dead" code, which isn't used and isn't compiled?
> > 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.
>
I start to write a new Simulator plug-in. Please see also a new thread.
> > 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.
Oh, this would be really great. As newbie I can tell you it is hard (or better
- sometime frustrating) to understand the split plugin/openhpid and how to
integrate new plugins.
>
> 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
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
