- The test programs have the license text of the LGPL in the header. I thought the license was GPL for the project?
- The code in the SVN should have the same format. Some sources have just the code and some also the line numbers and change dates.
- Why is the path in the SVN starting with beta? If at sometime the project evolves behind beta status will the SVN path change? That would be rather unfortunate because every access to the repository has to be changed, scripts, project svn properties …
- Why is the source code of the third party libraries added to the SVN? IMO only the source code of this project should be in the repository.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are correct, it does show LGPL - my mistake. I just copied it from the JSON source member. I am not real big on licensing as it concerns my own work that I am releasing into open source and am mostly just concerned about whether I am adhering to other's license. With that said I am wondering if you could describe why you went with LGPL instead of GPL? I have no problem moving to LGPL as long as more is gained by the community.
Concerning some code having seq numbers and others not, I am not seeing any without sequence numbers. Could you point me to what doesn't have sequence numbers? Note I am using RDi's "i Projects" to sync with SVN (fka iSeries Projects). Do you have a better approach? I would actually prefer to use RPGNextGen but haven't taken the time to see if that is easy to do from there.
Concerning the root of the repository being "/beta", I did that because I was expecting to have a bunch of "throw away" code based on trial and error, and didn't want to have a messy SVN history in the primary trunk. I am totally fine changing the approach on this front. If you would be willing I would love to have somebody with more SVN experience to better organize the approach for the RPGUI project. I can give you admin status if you want it.
Concerning the third party code being in the repository, I can see where this will be an issue on two fronts: 1) if we include it then it will miss out on updates from the holder of that project (i.e. your JSON utility for example) 2) If we don't include it here then it because one heck of a job to incorporate it (it took me a number of hours to just get the JSON stuff working - I had to figure out what all the dependencies were and download them separately from RPGNextGen.com if I remember correctly.) I don't mean to "cross a line" by including your code in this project. What is the best approach to take in your opinion that doesn't deter quick progress of RPGUI?
Aaron Bartell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was reading about your design for routing a users request to their job through a data queue and have a question. Will the user only have 1 job for all of their requests? We currently use ExtJS for our screens and we utilize a lot of combo boxes. Each combo has a store that loads the json data from rpg. So, if you have say 3 combo boxes on a form each one loads the data at approximately the same time. Will each one have to wait in the data queue line to be processed?
If so, maybe these types of requests could be routed through a job/jobs that doesn't have to be tied to the users job? This would allow for a faster response on those loads if each of the 3 requests could run in their own job.
Alan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for bringing this up. Yes the framework would do well to equally support both stateful and stateless requests because some requests don't require stateful (i.e. you could put a customer prompt screen on many pages that could be loaded from a non-stateful RPGUI pgm and return to the screen a modal pop-up form, and upon selecting a customer it would be returned to the parent UI component and populate the corresponding field).
Aaron Bartell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3rd party code: there should be a readme/install file in the archive file which should tell how to compile the package. but that is really a problem in the open source IBM i world: How to publish your application/program/serviceprogram. There is no easy way at the moment. I am currently investigating a method of packing the necessary things into an rpm package and using rpm under pase for installation, update, removal, … , but the rpm specs are giving me a really hard time. IMHO I would keep the 3rd party code out of the svn. If your are packaging the application later, then adding them to the application archive might not be such a bad idea.
SVN: There are many different approaches and I personally have no experience with working with a SVN repository in a team. Some are committing everything and use tags to mark a stable version. Some only committing only sources which are stable. Perhaps ask some Java guys. SVN is not so popular among us RPGers =)
Mihael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, I see what you mean by line numbers now and how JSON *does* have line numbers but they are all zero. It would be nice if there were no sequence numbers as that would make it much better for viewing code and copy/paste if browsing the repository in FireFox.
Yeah, a standard packager AND builder would be nice. We use a build mechanism at KrengelTech that is based on something Rory Hewitt wrote in SystemiNetwork awhile back and I like it. Basically you have comments in the top of your source member telling this custom precompiler how to compile a program.
Let's hope somebody else with much SVN experience pipes in.
aaronbartell.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Line numbers and changed dates on source: RPG Next Gen has an export wizard which just saves the source without any annoying line numbers or dates.
Package Management: Having the build command in the header works for a one-man shop or your inhouse development but really sucks for the public. You assume that you know the environment of the user when you actually know nothing about it. IMO putting it in the header is the worst case for something like this as the user would have to fiddle with the source code which he shouldn't have to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SVN: So do you export the source members to a local SVN directory and then do a sync? The reason I am getting into details is I want to document the various ways to submit code so others can understand the process.
Package Management: I was thinking we could come up with an agreed upon build tool so that it isn't so complicated to build something quickly from scratch. I don't think it is unreasonable to make assumptions about the environment (i.e. require them to have a library named RPGUIDEV and have it exist in their library list). Note this build tool wouldn't be used by 99% of all shops and instead would only be used for those working on the base framework code. I guess in the end I am open to anything, we just need some way of making it simple and well documented, and the nice thing about Rory's approach is that even if you don't have his pre-compiler you can still visually see how to compile the code based on the comments in the header of the program. Do you have other alternatives by chance that we could look into?
aaronbartell.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welcome to Open Discussion
Just some thoughts:
- The test programs have the license text of the LGPL in the header. I thought the license was GPL for the project?
- The code in the SVN should have the same format. Some sources have just the code and some also the line numbers and change dates.
- Why is the path in the SVN starting with beta? If at sometime the project evolves behind beta status will the SVN path change? That would be rather unfortunate because every access to the repository has to be changed, scripts, project svn properties …
- Why is the source code of the third party libraries added to the SVN? IMO only the source code of this project should be in the repository.
Hi Mihael,
You are correct, it does show LGPL - my mistake. I just copied it from the JSON source member. I am not real big on licensing as it concerns my own work that I am releasing into open source and am mostly just concerned about whether I am adhering to other's license. With that said I am wondering if you could describe why you went with LGPL instead of GPL? I have no problem moving to LGPL as long as more is gained by the community.
Concerning some code having seq numbers and others not, I am not seeing any without sequence numbers. Could you point me to what doesn't have sequence numbers? Note I am using RDi's "i Projects" to sync with SVN (fka iSeries Projects). Do you have a better approach? I would actually prefer to use RPGNextGen but haven't taken the time to see if that is easy to do from there.
Concerning the root of the repository being "/beta", I did that because I was expecting to have a bunch of "throw away" code based on trial and error, and didn't want to have a messy SVN history in the primary trunk. I am totally fine changing the approach on this front. If you would be willing I would love to have somebody with more SVN experience to better organize the approach for the RPGUI project. I can give you admin status if you want it.
Concerning the third party code being in the repository, I can see where this will be an issue on two fronts: 1) if we include it then it will miss out on updates from the holder of that project (i.e. your JSON utility for example) 2) If we don't include it here then it because one heck of a job to incorporate it (it took me a number of hours to just get the JSON stuff working - I had to figure out what all the dependencies were and download them separately from RPGNextGen.com if I remember correctly.) I don't mean to "cross a line" by including your code in this project. What is the best approach to take in your opinion that doesn't deter quick progress of RPGUI?
Aaron Bartell
Aaron,
I was reading about your design for routing a users request to their job through a data queue and have a question. Will the user only have 1 job for all of their requests? We currently use ExtJS for our screens and we utilize a lot of combo boxes. Each combo has a store that loads the json data from rpg. So, if you have say 3 combo boxes on a form each one loads the data at approximately the same time. Will each one have to wait in the data queue line to be processed?
If so, maybe these types of requests could be routed through a job/jobs that doesn't have to be tied to the users job? This would allow for a faster response on those loads if each of the 3 requests could run in their own job.
Alan
Hi Alan,
Thanks for bringing this up. Yes the framework would do well to equally support both stateful and stateless requests because some requests don't require stateful (i.e. you could put a customer prompt screen on many pages that could be loaded from a non-stateful RPGUI pgm and return to the screen a modal pop-up form, and upon selecting a customer it would be returned to the parent UI component and populate the corresponding field).
Aaron Bartell
@Aaron:
line numbers: the JSON code for example don't
3rd party code: there should be a readme/install file in the archive file which should tell how to compile the package. but that is really a problem in the open source IBM i world: How to publish your application/program/serviceprogram. There is no easy way at the moment. I am currently investigating a method of packing the necessary things into an rpm package and using rpm under pase for installation, update, removal, … , but the rpm specs are giving me a really hard time. IMHO I would keep the 3rd party code out of the svn. If your are packaging the application later, then adding them to the application archive might not be such a bad idea.
SVN: There are many different approaches and I personally have no experience with working with a SVN repository in a team. Some are committing everything and use tags to mark a stable version. Some only committing only sources which are stable. Perhaps ask some Java guys. SVN is not so popular among us RPGers =)
Mihael
Ah, I see what you mean by line numbers now and how JSON *does* have line numbers but they are all zero. It would be nice if there were no sequence numbers as that would make it much better for viewing code and copy/paste if browsing the repository in FireFox.
Yeah, a standard packager AND builder would be nice. We use a build mechanism at KrengelTech that is based on something Rory Hewitt wrote in SystemiNetwork awhile back and I like it. Basically you have comments in the top of your source member telling this custom precompiler how to compile a program.
Let's hope somebody else with much SVN experience pipes in.
aaronbartell.com
Line numbers and changed dates on source: RPG Next Gen has an export wizard which just saves the source without any annoying line numbers or dates.
Package Management: Having the build command in the header works for a one-man shop or your inhouse development but really sucks for the public. You assume that you know the environment of the user when you actually know nothing about it. IMO putting it in the header is the worst case for something like this as the user would have to fiddle with the source code which he shouldn't have to.
SVN: So do you export the source members to a local SVN directory and then do a sync? The reason I am getting into details is I want to document the various ways to submit code so others can understand the process.
Package Management: I was thinking we could come up with an agreed upon build tool so that it isn't so complicated to build something quickly from scratch. I don't think it is unreasonable to make assumptions about the environment (i.e. require them to have a library named RPGUIDEV and have it exist in their library list). Note this build tool wouldn't be used by 99% of all shops and instead would only be used for those working on the base framework code. I guess in the end I am open to anything, we just need some way of making it simple and well documented, and the nice thing about Rory's approach is that even if you don't have his pre-compiler you can still visually see how to compile the code based on the comments in the header of the program. Do you have other alternatives by chance that we could look into?
aaronbartell.com