Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Implementing the State Pattern in Actor Framework

Steve,

To avoid better packaged version that niACS and AQ maintain, I put my LV2012 port here: https://decibel.ni.com/content/docs/DOC-35631.  It is a group that I maintain, so if you need permission to join, ask and I will grant.  I do not know how to do that in advance.  Here is the link to the group if you need: https://decibel.ni.com/content/groups/actor-framework?view=documents

Kurt

0 Kudos
Message 21 of 61
(5,012 Views)

Kurt,

Thanks for that.

As an aside, I have often wondered if the AF could be developed a little more publicy, say with a repo on bitbucket or github. Realeses could be more frequent, users could participate more actively etc.

Steve.

0 Kudos
Message 22 of 61
(5,012 Views)

St3ve wrote:

As an aside, I have often wondered if the AF could be developed a little more publicy, say with a repo on bitbucket or github. Realeses could be more frequent, users could participate more actively etc.

St3ve: You find me a github or bitbucket depot whose license allows the hosting of commercial, proprietary code and I'll use it. I've searched and searched -- there's no such thing. And NI has zero interest in maintaining a whole new server system with its attendent security requirements, maintenance costs, etc, for my couple projects. Sure, it might over time expand to more projects, maybe even the bulk of vi.lib and NI's toolkits, but that's a hard hard thing to justify in the current economy since there would be negative return on investment.

I tried to set up a github server on my own. It is non-trivial to do. There's the personal cost of maintaining a server -- applying security patches and other general maintenance. Next, my ISP terms of service don't allow running a server unless I upgrade to a business line (three times the cost for the same [poor] quality of service... no thanks). Also, without it being hosted on NI's servers, I wouldn't have the legal protections against one of you uploading files that you didn't actually have the copyright to share -- the EULA that you sign when you join ni.com protects me if I use your work from an upload there. Building my own home server would require me to develop a login and EULA system and make it stay up to date with NI's EULA changes.

As far as I have been able to find, building a system like that just isn't feasible for proprietary software without substantial corporate investment.

0 Kudos
Message 23 of 61
(5,012 Views)

As far as I am aware there is no restriction on the free Bitbucket plan regarding whether the hosted code is for commercial or private use.

There is a restriction on how many users may be on the account (5 I think, expandable up to 8 by inviting others to use Bitbucket). Where a user is "Someone with read or write access to one of your private repositories". So depending on how large the dev team at NI is for AF it doesn't seem to be immediately out as an option.

I could well be entirely wrong ! But if a popular framework were developed publicly using a DVCS it may help wider adoption of better LabVIEW development practices.

Regards,

Steve.

0 Kudos
Message 24 of 61
(5,013 Views)

> But if a popular framework were developed publicly using

> a DVCS it may help wider adoption of better LabVIEW development practices.

It almost certainly would. And what you posted about Bitbucket is definitely better than when I last looked into it, but still not an effective solution.

Bitbucket assumes everyone involved in the project has already signed an employement agreement... it isn't an open-community tool. It would be hard for us to use it as one. There are five of us internal to NI who have been known to tweak with the AF, four devs and a tech writer. Yes, we could maintain our own internal source code control and only one of us push/pull changes with the community github, but then I'd be facing worse than a baseless merge between branches -- I'd be doing a bidirectional baseless merge between branches without a common source code control system. Ug. And that still wouldn't solve the EULA problem for code commits from the community. We could hand out logins only to those who signed a separate EULA with NI... turning me into both a licensing manager and an account manager. Again, ug.

As far as I can tell, for us to be able to use it, a system would need to:

1) Allow users to create their own accounts after clicking through an NI-supplied EULA with someone who owns the system handling things like password recovery

2) Allow unlimited users

3) Be cheap to the point that I could pay for it out of my own pocket until such time as I could show that it has enough value to get NI generally to buy into it

-- note that if every individual user paid his/her own subscription fee, that would suffice, since my subscription cost would then be down around $1 per month.

4) Have controlled branch integration for the main trunk (so only admins can approve changes up)

5) Allow for subbranches for users who want them

0 Kudos
Message 25 of 61
(5,013 Views)

I don't quite understand the need for any NI managed accounts/passwords etc. although AF would need some sort of licence, maybe BSD 2 clause or similar. The way I saw it working was:

you guys start a repo on Bitbucket for AF, there are 5 of you, so there goes all the users you're allowed for free. It is a public repo so anyone can pull and fork it but only team members (you five) can push to it or accept pull requests.

It is true that everyone, all interested users, need their own account, but this is just a standard free Bitbucket account: It is in no way associated with the one you guys are using, they are not members of the dev-team, they have no ability to push to the repo, you have no responsibilities for them.

Bitbucket provides some nice features such as a wiki and an issue tracker with auto-linking between commit messages and issue IDs. This provides a nice central place for users to find documentation, as well as an easy way to see if someone has requested a feature (maybe it's been rejected or maybe it's under development -- all in the issue tracker) or seen a similar bug.

Occasionally one of us many pesky "Users" will have a good idea, fork the repo and try it out, send you a pull request and you will merge in our patch. Mostly, ill-advised users will fork the framework, mess around for a while and then return to the last stable release when they realise it was all a big mistake!

I may be missing the point/got it wrong but I believe this does fit your 5 criteria:

1) User accounts are entirely independant, standard Bitbucket accounts,

2) The number of people able to clone/fork/pull from the AF repo is unlimited (the number able to push, with a free account, is limited to 5),

3) It is free so long as you have less than 5 team members on the account,

4) The default is only team members can push, if a user want's the changes in their branch pulled then they create a pull request which you approve,

5) sub-branches are accomplished by cloning/forking the repo. The main repo is blissfully unaware of them untill you wish to pull something from them.

0 Kudos
Message 26 of 61
(5,011 Views)

St3ve wrote:

Occasionally one of us many pesky "Users" will have a good idea,

Happens frequently.  AF would be a pale shadow of its current form without the community.

St3ve wrote:

send you a pull request and you will merge in our patch.

And there's the rub. At what point did you license your IP to National Instruments so that we can own it and ship it as part of LabVIEW without any encumbering licenses? That's what the site EULA does for things you upload to ni.com. NI Legal has told me to steer clear of including back into LabVIEW any VIs that don't go through posting on ni.com or a similar click-through license.

0 Kudos
Message 27 of 61
(5,011 Views)

AristosQueue wrote:

NI Legal has told me to steer clear of including back into LabVIEW any VIs that don't go through posting on ni.com or a similar click-through license.

If that is the stumbling block it would be a great shame. I would have hoped that putting it under a BSD 2-Clause would have been sufficient. LabVIEW must already include BSD licensed code, such as LAPACK libraries. I do not claim to have any expertise regarding licensing etc. but this is something that must be common to all open-source projects when pulling in community submissions.

I really would like to see something like this to encourage better LabVIEW dev practices and allow faster/more visible/more collaborative development of such a useful library. I think it would go some way to help "the funny pictures on the screen is not Real code" attitude as well.

0 Kudos
Message 28 of 61
(5,011 Views)

St3ve wrote:

but this is something that must be common to all open-source projects when pulling in community submissions.

And it is why very few open-source projects are directly part of licensed for-profit software. It would be fine to open it all up as long as I didn't want to actually ship the Actor Framework on the LabVIEW DVD. But I want the option to ship it as part of LabVIEW, and that changes the legal landscape.

I am not a lawyer. My understanding is as follows:  LabVIEW does use some BSD code, but our VIs are not BSD VIs. Us wrapping a BSD DLL and our users using the wrappers is legally different from users using a BSD-licensed VI. The former we can vet and we serve as the legal shield for our users downstream. The latter opens our users up to lawsuits directly if we're wrong. So there are companies and regulatory environments that demand that NI stand as that corporate shield for them or they won't touch our product.

The LabVIEW EULA is an open-source license insofar as it opens the VIs up to everyone who legally owns LabVIEW itself, which is a closed-source platform. It gets all the licensing nicely cleaned up so that NI clearly owns the code and leaves no ambiguity on the table about our users responsibilities for providing source code to their users or providing attribution, etc. That makes some people unhappy because it means that NI gets to make a profit selling their work. That's true. If you don't want that, don't share your work. Part of us allowing stuff to be shared means we want to be included in the sharing of those changes, and we want to be able to open it up to all users. Believe it or not, BSD is NOT usable by all users. Most of the open-source code comes with a disclaimer embedded in the source code that says "we do not provide any warranty; this code is provided as is, user beware." NI provides a much higher level of support than that. We want to be able to rip those disclaimers off of the code when we pass it along downstream. To remove those disclaimers, we have to own the code.

0 Kudos
Message 29 of 61
(5,011 Views)

I see it is not a straight forward thing from that respect!

Is there anything in the current licensing preventing any user forking the AF and developing it openly on say Bitbucket?

0 Kudos
Message 30 of 61
(5,011 Views)