DSAPlugin
Locked
 
|
Hello Cryptography team, DSAPlugin has had a home in the VMMaker-Plugins package (both VMMaker trunk and oscog) for quite some time, and an essentially identical copy of the same plugin appears in package CryptographyPlugins in the www.squeaksource.com/Cryptography repository. I would like to include the other plugins in package CryptographyPlugins in the configuration map for VMMaker in order to encourage them to be included in future VM distributions. In order to make this possible, it would help if the copy of DSAPlugin in CryptographyPlugins can be moved back out of that package category so the remaining three plugins (DESPlugin, MD5Plugin and SHA256Plugin) can be easily loaded into an image with VMMaker. This can be done by changing the class category for DSAPlugin from 'CryptographyPlugins' to 'VMMaker-Plugins' and saving the updated CryptographyPlugins package in SqS/Cryptography. Can someone make this happen? (Note that the alternative would be to remove DSAPlugin from VMMaker and reference the copy in Cryptography, but the plugin does not seem to have changed in over a decade, so it's probably best to leave it where it is in VMMaker) Thanks! Dave |
|
|
On Tue, Nov 22, 2011 at 7:00 PM, David T. Lewis <[hidden email]> wrote: > (Note that the alternative would be to remove DSAPlugin from VMMaker > and reference the copy in Cryptography, but the plugin does not seem > to have changed in over a decade, so it's probably best to leave it > where it is in VMMaker) Why is it best to leave it in VMMaker? Do other parts of VMMaker have hidden dependencies on DSAPlugin? It's going to be inconvenient for the cryptography team to delete their copy of the DSAPlugin and then maintain 3 plugins in their own package, and 1 more in VMMaker. In fact, I'd like to see more plugins being maintained and distributed independently of the VM. What's the point of having a plugin architecture if plugins are tightly bound into the VM anyway? If there are issues with moving plugins out of VMMaker, let's figure out what they are and fix them! Colin |
|
|
+1 for modular thinking. What is fun is to see the Klatt plugin still there. I'm sure that there are pluggin that could be removed too. Stef On Nov 23, 2011, at 7:06 AM, Colin Putney wrote: > > On Tue, Nov 22, 2011 at 7:00 PM, David T. Lewis <[hidden email]> wrote: > >> (Note that the alternative would be to remove DSAPlugin from VMMaker >> and reference the copy in Cryptography, but the plugin does not seem >> to have changed in over a decade, so it's probably best to leave it >> where it is in VMMaker) > > Why is it best to leave it in VMMaker? Do other parts of VMMaker have > hidden dependencies on DSAPlugin? > > It's going to be inconvenient for the cryptography team to delete > their copy of the DSAPlugin and then maintain 3 plugins in their own > package, and 1 more in VMMaker. In fact, I'd like to see more plugins > being maintained and distributed independently of the VM. What's the > point of having a plugin architecture if plugins are tightly bound > into the VM anyway? > > If there are issues with moving plugins out of VMMaker, let's figure > out what they are and fix them! > > Colin |
|
|
I think we need to start deconstruct the "huge beast" it is VMMaker right now, and that means at first instance split the package in smaller parts. No reason to have all plugins (newer, older, living, obsolete) in just one package. But also, it would be good (IMHO) to have all plugin packages grouped in just one repository (same VMMaker repository) and easily installable with a ConfigurationOf... (now we have metacello, no reason to use hand made scripts) If all agree in this, I can work a little on the split process (not right now, but in this weeks :) ). Cheers, Esteban El 23/11/2011, a las 6:00a.m., stephane ducasse escribió: > > +1 > for modular thinking. > > What is fun is to see the Klatt plugin still there. > I'm sure that there are pluggin that could be removed too. > > Stef > > On Nov 23, 2011, at 7:06 AM, Colin Putney wrote: > >> >> On Tue, Nov 22, 2011 at 7:00 PM, David T. Lewis <[hidden email]> wrote: >> >>> (Note that the alternative would be to remove DSAPlugin from VMMaker >>> and reference the copy in Cryptography, but the plugin does not seem >>> to have changed in over a decade, so it's probably best to leave it >>> where it is in VMMaker) >> >> Why is it best to leave it in VMMaker? Do other parts of VMMaker have >> hidden dependencies on DSAPlugin? >> >> It's going to be inconvenient for the cryptography team to delete >> their copy of the DSAPlugin and then maintain 3 plugins in their own >> package, and 1 more in VMMaker. In fact, I'd like to see more plugins >> being maintained and distributed independently of the VM. What's the >> point of having a plugin architecture if plugins are tightly bound >> into the VM anyway? >> >> If there are issues with moving plugins out of VMMaker, let's figure >> out what they are and fix them! >> >> Colin > |
|
|
In reply to this post by Colin Putney-3
On Tue, Nov 22, 2011 at 10:06:57PM -0800, Colin Putney wrote: > > On Tue, Nov 22, 2011 at 7:00 PM, David T. Lewis <[hidden email]> wrote: > > > (Note that the alternative would be to remove DSAPlugin from VMMaker > > and reference the copy in Cryptography, but the plugin does not seem > > to have changed in over a decade, so it's probably best to leave it > > where it is in VMMaker) > > Why is it best to leave it in VMMaker? Do other parts of VMMaker have > hidden dependencies on DSAPlugin? I did not say that it is better to leave it in VMMaker. I said that it should be in one package or the other, but not both. > > It's going to be inconvenient for the cryptography team to delete > their copy of the DSAPlugin and then maintain 3 plugins in their own > package, and 1 more in VMMaker. In fact, I'd like to see more plugins > being maintained and distributed independently of the VM. What's the > point of having a plugin architecture if plugins are tightly bound > into the VM anyway? I would like to hear from the Cryptography team as to what *they* want. That is why I asked them, with a CC to vm-dev to keep people informed. > > If there are issues with moving plugins out of VMMaker, let's figure > out what they are and fix them! There are no problems with maintaining plugins out of VMMaker, as long as there is an actual maintainer. That is the reason that I maintain all of my own plugin projects (OSPP etc) outside of VMMaker. But for a plugin is actively used but has no active developer or maintainer (as may be the case with DSAPlugin?), it is not helpful to put it into someone else's repository. But again, let's please hear with the Cryptography team has to say about it. That is why I asked the question. Thanks, Dave |
|
|
In reply to this post by EstebanLM
On Wed, Nov 23, 2011 at 08:42:43AM -0300, Esteban Lorenzano wrote: > > I think we need to start deconstruct the "huge beast" it is VMMaker right now, and that means at first instance split the package in smaller parts. > No reason to have all plugins (newer, older, living, obsolete) in just one package. > But also, it would be good (IMHO) to have all plugin packages grouped in just one repository (same VMMaker repository) and easily installable with a ConfigurationOf... (now we have metacello, no reason to use hand made scripts) > > If all agree in this, I can work a little on the split process (not right now, but in this weeks :) ). Hi Esteban, I agree in principle, but please do not do it now. I think it is very important to continue merging the two main VMMaker branches (traditional and oscog). I have been trying to make progress with this, and Eliot is certainly supportive, but I have to say that it is a lot of work and we rely heavily on the Monticello tools and matching package structures when comparing and merging code between oscog and trunk. If we were to break the packages into smaller pieces with different versions for trunk and oscog, the result would be difficult to keep track of in the VMMaker repository. If we want to achieve a more modular VMMaker, the most important thing to work on is reconciling the code bases, both in VMMaker and in the platforms support. There is a lot of work to be done here, and I don't know if anyone is even looking at the problem on the platforms code side (aside from Andreas, who did some significant updates to the win32 and Cross files in trunk). Once that work is done, we can reorganize package structures to improve the overall maintainability. But in the near term, changing the package structure in VMMaker would make the job more difficult for me. Thanks! Dave p.s. I know from personal experience that breaking packages into smaller pieces is not always a good idea, even if it sounds like the right thing to do. I split both the CommandShell and OSProcess packages into smaller packages, which seemed like a good idea because it would make them more modular. For CommandShell, this was very helpful, and I'm glad I did it. But for OSProcess is was a big mistake, because it makes it harder for me to manage version releases, and it has provided no practical benefit to the users of OSProcess. So sometimes it is a good idea to do this, and sometimes it is not ;) |
|
|
david Did you use metacello to manage your packages? Because small packages can be really a problem if we do not have a way to manage them as a group. I wrote the metacello chapter just for that: to help people managing their packages. Stef On Nov 23, 2011, at 3:22 PM, David T. Lewis wrote: > > On Wed, Nov 23, 2011 at 08:42:43AM -0300, Esteban Lorenzano wrote: >> >> I think we need to start deconstruct the "huge beast" it is VMMaker right now, and that means at first instance split the package in smaller parts. >> No reason to have all plugins (newer, older, living, obsolete) in just one package. >> But also, it would be good (IMHO) to have all plugin packages grouped in just one repository (same VMMaker repository) and easily installable with a ConfigurationOf... (now we have metacello, no reason to use hand made scripts) >> >> If all agree in this, I can work a little on the split process (not right now, but in this weeks :) ). > > Hi Esteban, > > I agree in principle, but please do not do it now. I think it is > very important to continue merging the two main VMMaker branches > (traditional and oscog). I have been trying to make progress with > this, and Eliot is certainly supportive, but I have to say that it > is a lot of work and we rely heavily on the Monticello tools and > matching package structures when comparing and merging code between > oscog and trunk. If we were to break the packages into smaller > pieces with different versions for trunk and oscog, the result > would be difficult to keep track of in the VMMaker repository. > > If we want to achieve a more modular VMMaker, the most important > thing to work on is reconciling the code bases, both in VMMaker > and in the platforms support. There is a lot of work to be done > here, and I don't know if anyone is even looking at the problem > on the platforms code side (aside from Andreas, who did some > significant updates to the win32 and Cross files in trunk). Once > that work is done, we can reorganize package structures to improve > the overall maintainability. But in the near term, changing the > package structure in VMMaker would make the job more difficult > for me. > > Thanks! > > Dave > > p.s. I know from personal experience that breaking packages into > smaller pieces is not always a good idea, even if it sounds like > the right thing to do. I split both the CommandShell and OSProcess > packages into smaller packages, which seemed like a good idea because > it would make them more modular. For CommandShell, this was very > helpful, and I'm glad I did it. But for OSProcess is was a big > mistake, because it makes it harder for me to manage version releases, > and it has provided no practical benefit to the users of OSProcess. > So sometimes it is a good idea to do this, and sometimes it is not ;) > |
|
|
On Wed, Nov 23, 2011 at 03:25:52PM +0100, stephane ducasse wrote: > > david > > Did you use metacello to manage your packages? > Because small packages can be really a problem if we do not have a way to manage them as a group. > I wrote the metacello chapter just for that: to help people managing their packages. > > Stef Hi Stef, Yes, and Metacello solves the problem very well from the point of view of distributing correct configurations and managing the necessary variations in packaging. For example, it is perfect for specifying a configuration of CommandShell that is appropriate for Pharo (no MVC required) versus a configuration that is appropriate for Squeak, and it provides a nice way to specify a configuration that is known to work with some specific version of an image. I mentioned my experience with OSProcess from the point of view of the developer and maintainer of the package. I broke the package into more pieces than necessary, and as a result I find myself needing to update several packages when releasing a change that would be better managed as a single update to one package. This makes it harder for me to keep track of changes why trying to troubleshoot a problem, and the repository itself now contains far too many files. So in general I prefer to see separate repositories and smaller, more modular packaging. But in practice sometimes there are tradeoffs ;) Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |