V7 .net interface
29 views
Skip to first unread message
MtM
Mar 31, 2011, 7:19:34 AM3/31/11
to hfm-net
Harlam I read you plan on supporting V7, I was wondering if you're
going to make a socket interface which can be used universally ( eg as
seperate interface component not directly tied into hfm.net ).
Now hfm.net is open source so it wouldn't be hard to fork the code
into a separate component if needed, but other then hfm.net there are
other .net applications which are 'waiting' on a proper interface
( and yes, that includes me as of right now as I haven't done more
then looking at the general socket interface and commands ). Maybe the
development of a .net binding component would benefit if it was done
as separate open source project, so anyone can both help development
and benefit from the expertise of the others? If you would support
this I would be happy to hear and will try and participate with
development where I can.
going to make a socket interface which can be used universally ( eg as
seperate interface component not directly tied into hfm.net ).
Now hfm.net is open source so it wouldn't be hard to fork the code
into a separate component if needed, but other then hfm.net there are
other .net applications which are 'waiting' on a proper interface
( and yes, that includes me as of right now as I haven't done more
then looking at the general socket interface and commands ). Maybe the
development of a .net binding component would benefit if it was done
as separate open source project, so anyone can both help development
and benefit from the expertise of the others? If you would support
this I would be happy to hear and will try and participate with
development where I can.
harlam357
Mar 31, 2011, 10:47:42 AM3/31/11
to hfm...@googlegroups.com
Hi Marvin,
The plan is to make the interface DLL a public API. Whether that interface is branded as an HFM component or not or whether it is developed in a separate source repo is up in the air right now. I've just started on the interface and am really just prototyping right now, so it will be a few weeks before I have something more concrete.
Once I do have something concrete and in a source repo I welcome ideas and patches but I will remain in control of what gets committed to the repo.
Besides yourself, what other developers/projects do you know of that are in need of a .net interface? If you can point me in the direction of said people maybe we can get a thread going on FF.org.
Regards,
-H
On Mar 31, 2011 6:19 AM, "MtM" <webm...@cftunity.nl> wrote:
MtM
Mar 31, 2011, 12:53:54 PM3/31/11
to hfm-net
Jedi95, author of GPU Tracker V2 for one. I think fahspy would also
benefit from a common interface. Besides those I admit I don't know
any .net project geared to folding at the moment but that might change
with a common open source component allowing people to focus on
developing something that suits their particular needs. I think a .net
component could also be used for a web application it's not just
limited at desktop use.
I would welcome someone like you being the administrative force behind
such an undertaking, as you've shown you're more then able to.
For a basic idea, a thread would be a good idea, if you start one I'll
make sure Jedi95 will read it. He did say he already had someone who
was willing to write him an interface for the tracker, another reason
why I think a common approach would be the best.
To be as clear as I can be, I think the initiative now started by
Pande Group depends on an open source collective, it's said as much on
the v7 track pages describing the client interface. I think you would
qualify for being the lead force for a .net interface component.
There are other considerations which we might consider, like expanding
the interface component to a shared back end for all applications.
Make the interface independent of the application using it so you
facilitate silent updates, gather centralized statistics who could be
beneficial to development and the icing on the cake would be a
centralized database which can store information about projects and
environment ( OS and hardware ). That way a site much like fahinfo.org
would be possible.
A .net component which is also mono compatible would cover allot of
ground for any folding monitor.
Maybe Stanford will cover offering a fahinfo like site since V7 I
think is capable of providing it with all the data it needs, so maybe
I'm taking it to far but as you say maybe a thread would be a good
idea. Though, allot of what I would ask to be done are things which
are already known I'm interested in the responses.
Of they do not, the community has a good chance here to do these
things which everyone always wanted ( speaking generally, but how many
times have you not heard people asking for a searchable database with
hw and ppd which is actually up to date the instant the hw is out in
circulation? ).
I am using openhardwaremonitorLIB as a source for the detection
modules I am working on ( ohmlib for hw detection and monitoring and
opencl/cuda/cal information from which cal seems to be broken atm ).
Since that runs on mono it allows hw detection and monitoring for all
major platforms. C# is not my thing, but to make the dll usefull for
my needs I had to expose allot of the functions and that's all the
changes I've done ( changing private declarations to public ). I'm
running a few revisions behind since I didn't need the patches ( cpu
support for new amd models for one ). I also haven't finished the gui,
seeing as I didn't have a finished interface to attach it to. Needs
some work before it's done but the functionality is already there.
It's in the repository here -> http://code.google.com/p/cftunity/source/browse/#svn%2FcftUnity.nl%2FcftUnity.nl
I'm not saying my code should be used, even if I hope you agree some
parts aren't as sloppy as things used to be, but it should show you
that if it's not me then someone else could help if there is a person
who steps up to the plate and takes on the task of administering the
project. I have no objection at all if I'm told my code is bad, but
when that goes alongside with 'let me show you how it's done' then you
would actually make me quite happy ;)
You on the other hand, have shown you're up to it. So, maybe I'm the
wrong person to make this request to you, since I don't see a public
discussion about this anywhere I got to ask you if you're willing to
do this?
benefit from a common interface. Besides those I admit I don't know
any .net project geared to folding at the moment but that might change
with a common open source component allowing people to focus on
developing something that suits their particular needs. I think a .net
component could also be used for a web application it's not just
limited at desktop use.
I would welcome someone like you being the administrative force behind
such an undertaking, as you've shown you're more then able to.
For a basic idea, a thread would be a good idea, if you start one I'll
make sure Jedi95 will read it. He did say he already had someone who
was willing to write him an interface for the tracker, another reason
why I think a common approach would be the best.
To be as clear as I can be, I think the initiative now started by
Pande Group depends on an open source collective, it's said as much on
the v7 track pages describing the client interface. I think you would
qualify for being the lead force for a .net interface component.
There are other considerations which we might consider, like expanding
the interface component to a shared back end for all applications.
Make the interface independent of the application using it so you
facilitate silent updates, gather centralized statistics who could be
beneficial to development and the icing on the cake would be a
centralized database which can store information about projects and
environment ( OS and hardware ). That way a site much like fahinfo.org
would be possible.
A .net component which is also mono compatible would cover allot of
ground for any folding monitor.
Maybe Stanford will cover offering a fahinfo like site since V7 I
think is capable of providing it with all the data it needs, so maybe
I'm taking it to far but as you say maybe a thread would be a good
idea. Though, allot of what I would ask to be done are things which
are already known I'm interested in the responses.
Of they do not, the community has a good chance here to do these
things which everyone always wanted ( speaking generally, but how many
times have you not heard people asking for a searchable database with
hw and ppd which is actually up to date the instant the hw is out in
circulation? ).
I am using openhardwaremonitorLIB as a source for the detection
modules I am working on ( ohmlib for hw detection and monitoring and
opencl/cuda/cal information from which cal seems to be broken atm ).
Since that runs on mono it allows hw detection and monitoring for all
major platforms. C# is not my thing, but to make the dll usefull for
my needs I had to expose allot of the functions and that's all the
changes I've done ( changing private declarations to public ). I'm
running a few revisions behind since I didn't need the patches ( cpu
support for new amd models for one ). I also haven't finished the gui,
seeing as I didn't have a finished interface to attach it to. Needs
some work before it's done but the functionality is already there.
It's in the repository here -> http://code.google.com/p/cftunity/source/browse/#svn%2FcftUnity.nl%2FcftUnity.nl
I'm not saying my code should be used, even if I hope you agree some
parts aren't as sloppy as things used to be, but it should show you
that if it's not me then someone else could help if there is a person
who steps up to the plate and takes on the task of administering the
project. I have no objection at all if I'm told my code is bad, but
when that goes alongside with 'let me show you how it's done' then you
would actually make me quite happy ;)
You on the other hand, have shown you're up to it. So, maybe I'm the
wrong person to make this request to you, since I don't see a public
discussion about this anywhere I got to ask you if you're willing to
do this?
MtM
Mar 31, 2011, 1:54:51 PM3/31/11
to hfm-net
Afraid of being unclear, comes with autism sorry, what I'm asking is
for you to take the lead in the discussion first, and hopefully later
on with being the project lead depending on the outcome of the
discussion and the resulting parameters for the component. If the
discussion takes a turn towards a more limited interface, things might
turn out that I'll fork your code when published and try to add some
of the functionality. That also depends on if Stanford will be
providing fahinfo.org like information in the future.
for you to take the lead in the discussion first, and hopefully later
on with being the project lead depending on the outcome of the
discussion and the resulting parameters for the component. If the
discussion takes a turn towards a more limited interface, things might
turn out that I'll fork your code when published and try to add some
of the functionality. That also depends on if Stanford will be
providing fahinfo.org like information in the future.
MtM
Apr 7, 2011, 8:59:09 AM4/7/11
to hfm-net
Harlam I started a thread here -> http://foldingforum.org/viewtopic.php?f=14&t=18275&start=0
I'll send a link to Jedi and the author of fahSpy.
I would like your input at the very least, I'm not asking you to
commit to something yet, just be part of the discussion.
I'll send a link to Jedi and the author of fahSpy.
I would like your input at the very least, I'm not asking you to
commit to something yet, just be part of the discussion.
MtM
May 5, 2011, 4:29:08 PM5/5/11
to hfm-net
Hi Harlam, treid to get your attention on ff.org as well as through pm
but you're mighty bussy it seems. I want to know what license I should
put on my vb conversion of you V7 interface class? I did do quite abit
more then just converting it ( not done yet, but will strong type the
interface completely ) but I'm feeling uncomfortable since you haven't
posted nor replied after I showed you the first vb.net conversion, I
don't want to break any license you want to put on it but then atleast
tell me you're either ok with my work or you want me to stop using the
converted code ;)
but you're mighty bussy it seems. I want to know what license I should
put on my vb conversion of you V7 interface class? I did do quite abit
more then just converting it ( not done yet, but will strong type the
interface completely ) but I'm feeling uncomfortable since you haven't
posted nor replied after I showed you the first vb.net conversion, I
don't want to break any license you want to put on it but then atleast
tell me you're either ok with my work or you want me to stop using the
converted code ;)
harlam357
May 5, 2011, 11:17:40 PM5/5/11
to hfm...@googlegroups.com
Hi Marvin,
My code will be released under the GPLv2. I'd prefer you use my implementation directly, but of course you're free to do as you like. I've already made some pretty large changes to what I had that you downloaded. I'm moving forward with a three layer approach. Basically it will go like this: Client>Messages>Connection. Basically taking a similar approach to what uncle fungus posted.
Connection - raw tcp connection, command sending and message receiving.
Messages - raw json messages received from the Connection.
Client - strongly typed objects parsed from the raw json from Messages.
The initial Connection and Messages implementions have been checked into the HFM repo if you want to check it out.
Kind Regards,
-H
> --
> You received this message because you are subscribed to the Google Groups "hfm-net" group.
> To unsubscribe from this group, send email to hfm-net+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hfm-net?hl=en
> You received this message because you are subscribed to the Google Groups "hfm-net" group.
> To unsubscribe from this group, send email to hfm-net+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hfm-net?hl=en
MtM
May 6, 2011, 2:40:48 AM5/6/11
to hfm-net
http://code.google.com/p/fahgetaboutit/source/browse/#svn%2Fbranches%2FfInfo
is where I was keeping my 'progress', I'm going to remove all string
constants you don't need them afaik. To evaluate the string dictionary
one can use keys and values,
If you have read what I posted on ff.org, the tcpclient class only
works in blocking mode, eg synchronous operation so in order to comply
with the requirements another implementation is needed. Though, there
is lil difference to executing an update through command and parse the
response every x interval towards scheduling the commands to be given
every x interval but the clients internal script engine.
The repository I linked above holds your initial classes with my
changes, it links to your own repository and has no license header
yet. I'm not sure how strictly my conversion + changes would fall
under gpl2, I wanted or had hoped the interface class would be
WTFPL'd ;) But since my benefit from your initial code is so that I
could just extend what I understood and implement what I thought would
work I will add any header you want.
I would like and will use your complete implementation down the road
I'm sure, but I can't use a WIP to test a WIP so I'll keep this side
development going until you finalized the interface ( hoping that the
final implementation will be strong typed in the same manner as I'm
doing as that's the way I'll access the data instead of the
stringdictionary.
One thing I would like to know though is why for this library you're
not going to use a LGPL license? For the folding@home cause, the least
restrictive license should be used I feel, Apart from http://sam.zoy.org/wtfpl/
that would be the lgpl license which would allow it to used in an
closed source assembly ( GPL I think requires the calling application
to be open source as well? ).
Would you like for me to add your repository link as wip to the faq
thread? Both Smoking2000 and UF have posted their work as wip, so I
can't see why I shouldn't unless you don't want to?
This is my post before my morning coffee, excuse me if I make to many
grammatical errors or just bad sentences.
is where I was keeping my 'progress', I'm going to remove all string
constants you don't need them afaik. To evaluate the string dictionary
one can use keys and values,
If you have read what I posted on ff.org, the tcpclient class only
works in blocking mode, eg synchronous operation so in order to comply
with the requirements another implementation is needed. Though, there
is lil difference to executing an update through command and parse the
response every x interval towards scheduling the commands to be given
every x interval but the clients internal script engine.
The repository I linked above holds your initial classes with my
changes, it links to your own repository and has no license header
yet. I'm not sure how strictly my conversion + changes would fall
under gpl2, I wanted or had hoped the interface class would be
WTFPL'd ;) But since my benefit from your initial code is so that I
could just extend what I understood and implement what I thought would
work I will add any header you want.
I would like and will use your complete implementation down the road
I'm sure, but I can't use a WIP to test a WIP so I'll keep this side
development going until you finalized the interface ( hoping that the
final implementation will be strong typed in the same manner as I'm
doing as that's the way I'll access the data instead of the
stringdictionary.
One thing I would like to know though is why for this library you're
not going to use a LGPL license? For the folding@home cause, the least
restrictive license should be used I feel, Apart from http://sam.zoy.org/wtfpl/
that would be the lgpl license which would allow it to used in an
closed source assembly ( GPL I think requires the calling application
to be open source as well? ).
Would you like for me to add your repository link as wip to the faq
thread? Both Smoking2000 and UF have posted their work as wip, so I
can't see why I shouldn't unless you don't want to?
This is my post before my morning coffee, excuse me if I make to many
grammatical errors or just bad sentences.
MtM
May 6, 2011, 8:36:30 AM5/6/11
to hfm-net
Checked your progress on the client, compare with rev49 which is what
I have now made from your submitted code.
Let me ask this right away now, I really don't feel that compelled to
release the code under gpl since the base might be the converted
structure from your code but that structure is the same for all
interface implementations and my added code for now is more feature
complete as your's.
However, you're a professional doing this also for a living so your
code will ultimately be of better quality then mine, so I don't want
to compete for a language interface, I will list your contribution as
official entry when you say so. But I would like official recognition
that my current code does not fall under your license considerations
( though I will keep the comment about the initial structure being
converted from your code ). If you're not ok with this, will it be
enough if I replace the json handling with my own functions or would
you like me to create a project from scratch ( which will still
resemble your code since such are the requirements of the interface )?
All I would like from the interface right now I have, strong typed
objects. If you would implement the same properties as I done in the
queue slot info and options classes and consider moving from tcpclient
to sockets so update's can be scheduled I will drop my work now and
use your's no questions asked. Maybe not drop tcpclient but add
another class using a socket implementation for scheduled updates as I
was planning to do. But I'm to impatient to wait, so it would be
really nice if as long as my implementation is ahead of your's you'll
allow me to use the code in my own projects.
I have now made from your submitted code.
Let me ask this right away now, I really don't feel that compelled to
release the code under gpl since the base might be the converted
structure from your code but that structure is the same for all
interface implementations and my added code for now is more feature
complete as your's.
However, you're a professional doing this also for a living so your
code will ultimately be of better quality then mine, so I don't want
to compete for a language interface, I will list your contribution as
official entry when you say so. But I would like official recognition
that my current code does not fall under your license considerations
( though I will keep the comment about the initial structure being
converted from your code ). If you're not ok with this, will it be
enough if I replace the json handling with my own functions or would
you like me to create a project from scratch ( which will still
resemble your code since such are the requirements of the interface )?
All I would like from the interface right now I have, strong typed
objects. If you would implement the same properties as I done in the
queue slot info and options classes and consider moving from tcpclient
to sockets so update's can be scheduled I will drop my work now and
use your's no questions asked. Maybe not drop tcpclient but add
another class using a socket implementation for scheduled updates as I
was planning to do. But I'm to impatient to wait, so it would be
really nice if as long as my implementation is ahead of your's you'll
allow me to use the code in my own projects.
harlam357
May 6, 2011, 11:01:12 AM5/6/11
to hfm...@googlegroups.com
Yeah, ignore the data class implementations I already have in there. I was just putting something together as a data holder. The final implementation of these types will be strongly typed objects with normal properties.
The NetworkStream class (which TcpClient returns) has BeginRead() and BeginWrite() methods that are asynchronous, non-blocking, read and write calls.
I'm pretty sure I'll end up with GPLv2 to comply with the rest of HFM. I want my implementation free and only used by other free software.
Sure, you can use the following link to post my implementation as a WIP: http://code.google.com/p/hfm-net/source/browse/#svn%2Ftrunk%2Fsrc%2FHFM.Client
Sorry I've got to be short Marvin... at work and gotta get to some of it. I'll try to catch back up on ff.org later this weekend... got a big weekend planned so it'll probably be Sunday before I'm able to catch up.
Regards,
-H
The NetworkStream class (which TcpClient returns) has BeginRead() and BeginWrite() methods that are asynchronous, non-blocking, read and write calls.
I'm pretty sure I'll end up with GPLv2 to comply with the rest of HFM. I want my implementation free and only used by other free software.
Sure, you can use the following link to post my implementation as a WIP: http://code.google.com/p/hfm-net/source/browse/#svn%2Ftrunk%2Fsrc%2FHFM.Client
Sorry I've got to be short Marvin... at work and gotta get to some of it. I'll try to catch back up on ff.org later this weekend... got a big weekend planned so it'll probably be Sunday before I'm able to catch up.
Regards,
-H
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages