Some question regarding portability
Locked
12
12
Some question regarding portability
 
|
Hi All,
I would like to improve the portability of Zinc HTTP Components ( http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary tested on Squeak (currently 4.2 #10977), and most of the code works unmodified. Recently, I had another look, and I would like to fix some issues, if possible. - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? - How does one do MD5 hashing in Squeak ? We used to fall back to either CMD5Hasher or TCryptoRandom, but none are in the standard image. What has to be loaded to make this work (again) ? - Has there ever been a MIMEType class ? This is not crucial at all, I am just wondering why it is not there. - I guess that ByteTextConverter class>>#encodeTable and ByteTextConverter class>>#decodeTable play the same role as ByteTextConverter class>>#unicodeToByteTable and ByteTextConverter class>>#byteToUnicodeTable ? Thanks, Sven |
Re: Some question regarding portability
|
|
On Tue, 10 May 2011, Sven Van Caekenberghe wrote:
> Hi All, > > I would like to improve the portability of Zinc HTTP Components ( http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary tested on Squeak (currently 4.2 #10977), and most of the code works unmodified. Recently, I had another look, and I would like to fix some issues, if possible. > > - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? > > - How does one do MD5 hashing in Squeak ? We used to fall back to either CMD5Hasher or TCryptoRandom, but none are in the standard image. What has to be loaded to make this work (again) ? The MD5 class is in the Cryptography package. > > - Has there ever been a MIMEType class ? This is not crucial at all, I am just wondering why it is not there. I don't think so. > > - I guess that ByteTextConverter class>>#encodeTable and ByteTextConverter class>>#decodeTable play the same role as ByteTextConverter class>>#unicodeToByteTable and ByteTextConverter class>>#byteToUnicodeTable ? It's hard to answer your question without knowing what ByteTextConverter class >> #unicodeToBytTable and ByteTextConverter class >> #byteToUnicodeTable are. Levente > > Thanks, > > Sven > > > > > |
Re: Some question regarding portability
|
|
On 10 May 2011, at 11:48, Levente Uzonyi wrote: > On Tue, 10 May 2011, Sven Van Caekenberghe wrote: > >> Hi All, >> >> I would like to improve the portability of Zinc HTTP Components ( http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary tested on Squeak (currently 4.2 #10977), and most of the code works unmodified. Recently, I had another look, and I would like to fix some issues, if possible. >> >> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? > > There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? I am not aware of that many versions. I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. Would Announcements from http://www.squeaksource.com/AXAnnouncements do ? What is the AX variant by the way ? This repository has not seen many recent updates, I assume it still works for Squeal 4.2. >> >> - How does one do MD5 hashing in Squeak ? We used to fall back to either CMD5Hasher or TCryptoRandom, but none are in the standard image. What has to be loaded to make this work (again) ? > > The MD5 class is in the Cryptography package. I guess you mean the main Cryptograhy package from http://www.squeaksource.com/Cryptography, I can't seem to find any loading instructions. I will try. >> >> - Has there ever been a MIMEType class ? This is not crucial at all, I am just wondering why it is not there. > > I don't think so. OK >> - I guess that ByteTextConverter class>>#encodeTable and ByteTextConverter class>>#decodeTable play the same role as ByteTextConverter class>>#unicodeToByteTable and ByteTextConverter class>>#byteToUnicodeTable ? > > It's hard to answer your question without knowing what ByteTextConverter class >> #unicodeToBytTable and ByteTextConverter class >> #byteToUnicodeTable are. I will just try then. > Levente Thanks for the reply, Sven |
Re: Some question regarding portability
|
|
On 5/10/2011 12:21, Sven Van Caekenberghe wrote:
> > On 10 May 2011, at 11:48, Levente Uzonyi wrote: > >> On Tue, 10 May 2011, Sven Van Caekenberghe wrote: >> >>> Hi All, >>> >>> I would like to improve the portability of Zinc HTTP Components ( http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary tested on Squeak (currently 4.2 #10977), and most of the code works unmodified. Recently, I had another look, and I would like to fix some issues, if possible. >>> >>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >> >> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? > > I am not aware of that many versions. > I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. Cheers, - Andreas > Would Announcements from http://www.squeaksource.com/AXAnnouncements do ? What is the AX variant by the way ? This repository has not seen many recent updates, I assume it still works for Squeal 4.2. > >>> >>> - How does one do MD5 hashing in Squeak ? We used to fall back to either CMD5Hasher or TCryptoRandom, but none are in the standard image. What has to be loaded to make this work (again) ? >> >> The MD5 class is in the Cryptography package. > > I guess you mean the main Cryptograhy package from http://www.squeaksource.com/Cryptography, I can't seem to find any loading instructions. I will try. > >>> >>> - Has there ever been a MIMEType class ? This is not crucial at all, I am just wondering why it is not there. >> >> I don't think so. > > OK > >>> - I guess that ByteTextConverter class>>#encodeTable and ByteTextConverter class>>#decodeTable play the same role as ByteTextConverter class>>#unicodeToByteTable and ByteTextConverter class>>#byteToUnicodeTable ? >> >> It's hard to answer your question without knowing what ByteTextConverter class>> #unicodeToBytTable and ByteTextConverter class>> #byteToUnicodeTable are. > > I will just try then. > >> Levente > > Thanks for the reply, > > Sven > > > |
Re: Some question regarding portability
|
|
They really are not, though on the surface they look deceptively simple. The amount of nuances and quirks in implementing subscribing/unsubscribing, weak versions, delivery guarantees etc. are large enough that you really only want to implement/document/learn them once. My 2c at least :) Cheers, Henry |
Re: Some question regarding portability
|
|
In reply to this post by Andreas.Raab
On 10 May 2011, at 14:45, Andreas Raab wrote: >>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>> >>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >> >> I am not aware of that many versions. >> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. > > Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. I agree that Announcements are pretty simple. Still, if it is available, then why not use it. Sharing and reusing general purpose classes seems pretty important and elementary to me. Of course, this sharing and reuse makes package management and dependencies more difficult. For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. I think reimplementing something should only be done when the original does not work (properly) and cannot easily be fixed. I do have ZnMimeType, ZnUrl and ZnCharacterEncoding objects, which I wrote after having struggled with the originals for too long. Sven |
Re: Some question regarding portability
|
|
In reply to this post by Andreas.Raab
On 10 May 2011 14:45, Andreas Raab <[hidden email]> wrote:
> On 5/10/2011 12:21, Sven Van Caekenberghe wrote: >> >> On 10 May 2011, at 11:48, Levente Uzonyi wrote: >> >>> On Tue, 10 May 2011, Sven Van Caekenberghe wrote: >>> >>>> Hi All, >>>> >>>> I would like to improve the portability of Zinc HTTP Components ( >>>> http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary >>>> tested on Squeak (currently 4.2 #10977), and most of the code works >>>> unmodified. Recently, I had another look, and I would like to fix some >>>> issues, if possible. >>>> >>>> - Are announcements available ? Can this framework be loaded ? What is >>>> the official way to do this ? >>> >>> There are at least four different implementations of the announcements >>> framework. They are not (fully) compatible with each other. The question is: >>> which one is required by Zinc? >> >> I am not aware of that many versions. >> I subclass Announcement, instanciate an Announcer, send #announce: and >> #on:send:do to it, that's all. > > Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three > methods that you actually need? Announcements always struck me as more of a > pattern than a framework. > Yes, this is a typical observer pattern. However, a framework is needed to nicely manage subscriptions. Because if everyone will start implementing this pattern by own, then you end up with multiple subsystems which basicly doing the same work (because pattern is same!). See Object>>addDependent: anObject and Object>>changed: Then see Object>>actionMap & Object>>triggerEvent: anEventSelector and then at some point, a developer get lost, which one he should actually use. That's why Pharo plans to unify all those subscription/event triggering mechanisms and replace them with single one - announcements. -- Best regards, Igor Stasenko AKA sig. |
Re: Some question regarding portability
|
|
In reply to this post by Sven Van Caekenberghe
On 5/10/2011 15:34, Sven Van Caekenberghe wrote:
> > On 10 May 2011, at 14:45, Andreas Raab wrote: > >>>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>>> >>>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >>> >>> I am not aware of that many versions. >>> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. >> >> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. > > I agree that Announcements are pretty simple. > Still, if it is available, then why not use it. > Sharing and reusing general purpose classes seems pretty important and elementary to me. > > Of course, this sharing and reuse makes package management and dependencies more difficult. > > For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. > > I think reimplementing something should only be done when the original does not work (properly) and cannot easily be fixed. I do have ZnMimeType, ZnUrl and ZnCharacterEncoding objects, which I wrote after having struggled with the originals for too long. Just a thought. If you prefer additional dependencies that's your choice to make. Cheers, - Andreas |
|
|
In reply to this post by Sven Van Caekenberghe
2011/5/10 Sven Van Caekenberghe <[hidden email]>:
> > On 10 May 2011, at 14:45, Andreas Raab wrote: > >>>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>>> >>>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >>> >>> I am not aware of that many versions. >>> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. >> >> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. > > I agree that Announcements are pretty simple. > Still, if it is available, then why not use it. > Sharing and reusing general purpose classes seems pretty important and elementary to me. > > Of course, this sharing and reuse makes package management and dependencies more difficult. > > For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. > Hi Sven: Yes, Cryptography is mostly a name to group different implementations of crypto related stuff. I agree that may not be the better idea thinking in reuse. I'm copying this mail to the crypto list (even when I think that most of the people is here also) to discuss about better ways to name/install the things. Regards. Germán. |
|
|
2011/5/10 Germán Arduino <[hidden email]>:
> 2011/5/10 Sven Van Caekenberghe <[hidden email]>: >> >> On 10 May 2011, at 14:45, Andreas Raab wrote: >> >>>>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>>>> >>>>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >>>> >>>> I am not aware of that many versions. >>>> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. >>> >>> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. >> >> I agree that Announcements are pretty simple. >> Still, if it is available, then why not use it. >> Sharing and reusing general purpose classes seems pretty important and elementary to me. >> >> Of course, this sharing and reuse makes package management and dependencies more difficult. >> >> For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. >> > > Hi Sven: > > Yes, Cryptography is mostly a name to group different implementations > of crypto related stuff. I agree that may not be the better idea > thinking in reuse. > > I'm copying this mail to the crypto list (even when I think that most > of the people is here also) to discuss about better ways to > name/install the things. > I forgot to say that this don't excludes to think in add some of the more used stuff (as hashing) on the image, "a la Pharo". Germán. |
RE: [Cryptography Team] Re: [squeak-dev] Re: Some question regarding portability
|
|
In reply to this post by garduino
Loading pieces of the code would be nice but most people load everything and
then take what they need to add just that. If there are tests that fail we should address those issues. Until there is a framework for loading parts of packages I think this would make things harder to use and understand then allowing people to get a working version and then remove what they don't want for their own deployment. Also consider the overlap. We have a number of hashes that use the same streaming framework. It would be easier to load cryptography and then delete SHA1 then it would be to package up all the components needed for MD5 and then package all the same components again for SHA256. The code base is not so large, that the benefit would be worth the time it would take and confusion it would cause. Ron Teitelbaum > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Germán Arduino > Sent: Tuesday, May 10, 2011 7:21 PM > To: The general-purpose Squeak developers list > Cc: Cryptography Team Development List > Subject: [Cryptography Team] Re: [squeak-dev] Re: Some question regarding > portability > > 2011/5/10 Sven Van Caekenberghe <[hidden email]>: > > > > On 10 May 2011, at 14:45, Andreas Raab wrote: > > > >>>>> - Are announcements available ? Can this framework be loaded ? > What is the official way to do this ? > >>>> > >>>> There are at least four different implementations of the > announcements framework. They are not (fully) compatible with each other. > The question is: which one is required by Zinc? > >>> > >>> I am not aware of that many versions. > >>> I subclass Announcement, instanciate an Announcer, send #announce: > and #on:send:do to it, that's all. > >> > >> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or > three methods that you actually need? Announcements always struck me as > more of a pattern than a framework. > > > > I agree that Announcements are pretty simple. > > Still, if it is available, then why not use it. > > Sharing and reusing general purpose classes seems pretty important and > elementary to me. > > > > Of course, this sharing and reuse makes package management and > dependencies more difficult. > > > > For example, I need MD5, for which it seems to be necessary to load > Cryptography in Squeak, a quite large framework that seems to be under > development (many unit tests failed, MD5 works OK). You have chosen a > shortcut in WebClient by implementing MD5 yourself. This runs against the > refactoring rule but makes it easier for users because they don't need to > a dependency. > > > > Hi Sven: > > Yes, Cryptography is mostly a name to group different implementations of > crypto related stuff. I agree that may not be the better idea thinking in reuse. > > I'm copying this mail to the crypto list (even when I think that most of the > people is here also) to discuss about better ways to name/install the things. > > Regards. > Germán. > _______________________________________________ > Cryptography mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Re: Some question regarding portability
|
|
In reply to this post by garduino
Am 2011-05-11 um 01:20 schrieb Germán Arduino: > 2011/5/10 Sven Van Caekenberghe <[hidden email]>: >> >> On 10 May 2011, at 14:45, Andreas Raab wrote: >> >>>>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>>>> >>>>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >>>> >>>> I am not aware of that many versions. >>>> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. >>> >>> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. >> >> I agree that Announcements are pretty simple. >> Still, if it is available, then why not use it. >> Sharing and reusing general purpose classes seems pretty important and elementary to me. >> >> Of course, this sharing and reuse makes package management and dependencies more difficult. >> >> For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. >> > > Hi Sven: > > Yes, Cryptography is mostly a name to group different implementations > of crypto related stuff. I agree that may not be the better idea > thinking in reuse. > > I'm copying this mail to the crypto list (even when I think that most > of the people is here also) to discuss about better ways to > name/install the things. FWIW, I just happen to have implemented a Gravatar package for Seaside. That needs MD5 for generating image urls and I did not want to depend on the Crypto package, either. Thus I took the MD5 from Cryptography and built it into a one-method call… not beautiful at all but works :/ Would there have been a better method? So Long, -Tobias |
Re: Some question regarding portability
|
|
In reply to this post by Henrik Sperre Johansen
On 2011-05-10 9:13 AM, Henrik Sperre Johansen wrote:
> The amount of nuances and quirks in implementing subscribing/unsubscribing, > weak versions, delivery guarantees etc. are large enough that you really > only want to implement/document/learn them once. FWIW, I agree heartily. Looking at Announcements-klub.1.mcz from the AXAnnouncements project, a *lot* of thought and careful implementation has gone into the subscription-management and delivery piece of the puzzle - and even then, there are areas in which it could be improved. One way of thinking about it, that I'm becoming more and more convinced by is this: If Objects are abstract representations of computers, then Announcers are abstract representations of networks. The communication channel between two objects is normally a regular message send. Regular message sends provide Plain Old RPC (with Exceptions). Sometimes, however, you want one or more of the following things to happen: - a message to be delivered to more than one recipient - a message to be delivered to an arbitrary or unknown number of recipients - a message to be delivered asynchronously, or without reply - a message to be delivered across a real network to some remote object Combinations of the above are useful and interesting too. It's in situations like these that having a first-class representation of the *medium of communication* between objects becomes important. And that's just what Announcers are. (I'm working at the moment a little on thinking about how to generalise Announcers to take into consideration more than just the first two of the four points listed above.) Regards, Tony |
|
|
In reply to this post by Tobias Pape
Well, are the two ways:
1. Reuse; or 2. Implement in your own code Each one with their advantages and drawbacks :) 2011/5/11 Tobias Pape <[hidden email]>: > > Am 2011-05-11 um 01:20 schrieb Germán Arduino: > >> 2011/5/10 Sven Van Caekenberghe <[hidden email]>: >>> >>> On 10 May 2011, at 14:45, Andreas Raab wrote: >>> >>>>>>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >>>>>> >>>>>> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? >>>>> >>>>> I am not aware of that many versions. >>>>> I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. >>>> >>>> Then how about adding ZnAnnouncement, ZnAnnouncer with the two or three methods that you actually need? Announcements always struck me as more of a pattern than a framework. >>> >>> I agree that Announcements are pretty simple. >>> Still, if it is available, then why not use it. >>> Sharing and reusing general purpose classes seems pretty important and elementary to me. >>> >>> Of course, this sharing and reuse makes package management and dependencies more difficult. >>> >>> For example, I need MD5, for which it seems to be necessary to load Cryptography in Squeak, a quite large framework that seems to be under development (many unit tests failed, MD5 works OK). You have chosen a shortcut in WebClient by implementing MD5 yourself. This runs against the refactoring rule but makes it easier for users because they don't need to load a dependency. >>> >> >> Hi Sven: >> >> Yes, Cryptography is mostly a name to group different implementations >> of crypto related stuff. I agree that may not be the better idea >> thinking in reuse. >> >> I'm copying this mail to the crypto list (even when I think that most >> of the people is here also) to discuss about better ways to >> name/install the things. > > > FWIW, I just happen to have implemented a Gravatar package for Seaside. > That needs MD5 for generating image urls and I did not want to depend > on the Crypto package, either. Thus I took the MD5 from Cryptography > and built it into a one-method call… not beautiful at all but works :/ > Would there have been a better method? > > So Long, > -Tobias > > > |
MD5 for Squeak (was: Re: [squeak-dev] Re: Some question regarding portability)
|
|
In reply to this post by garduino
There was a plan to add the whole Cryptography package (split to three
packages) to the Trunk. Some older versions are waiting in the Inbox (see CryptoCore, CryptoCerts and CryptoExtras). IIRC this process is stalled because the proper renaming of the packages didn't happen (Cryptography instead of Crypto). If the renaming is done, then Squeak will have a working MD5 implementation out of the box. Another solution is to grab the MD5 implementation from WebClient (which is probably the same as in Croquet, since it uses the CroquetPlugin if available). What do you think? Levente |
Re: Some question regarding portability
|
|
In reply to this post by Sven Van Caekenberghe
On Tue, 10 May 2011, Sven Van Caekenberghe wrote:
> > On 10 May 2011, at 11:48, Levente Uzonyi wrote: > >> On Tue, 10 May 2011, Sven Van Caekenberghe wrote: >> >>> Hi All, >>> >>> I would like to improve the portability of Zinc HTTP Components ( http://zn.stfx.eu ) to Squeak. During the development of Zn I have regulary tested on Squeak (currently 4.2 #10977), and most of the code works unmodified. Recently, I had another look, and I would like to fix some issues, if possible. >>> >>> - Are announcements available ? Can this framework be loaded ? What is the official way to do this ? >> >> There are at least four different implementations of the announcements framework. They are not (fully) compatible with each other. The question is: which one is required by Zinc? > > I am not aware of that many versions. contained only what OB needed. Then Lukas wrote his own based on the OB version. Soon after that Balázs Kósi and I extracted our implementation from our ajax based web framework (that's where the AX prefix is coming from). Recently Pharo developers started a new implementation based on Lukas' version which was already part of Pharo. > I subclass Announcement, instanciate an Announcer, send #announce: and #on:send:do to it, that's all. I guess those will work with the simplest announcements implementations. > Would Announcements from http://www.squeaksource.com/AXAnnouncements do ? What is the AX variant by the way ? This repository has not seen many recent updates, I assume it still works for Squeal 4.2. The AXAnnouncements repo is not frequently updated, because the framework reached a stable state, the same will happen to Zinc soon ;). If you've found a bug or need new features, let us know. The repository used to be writeable, but it's read only now, probably because of incomplete restoration of SqueakSource after crashes. Of course a world writable repo doesn't mean that we don't review code and remove broken versions from it. > >>> >>> - How does one do MD5 hashing in Squeak ? We used to fall back to either CMD5Hasher or TCryptoRandom, but none are in the standard image. What has to be loaded to make this work (again) ? >> >> The MD5 class is in the Cryptography package. > > I guess you mean the main Cryptograhy package from http://www.squeaksource.com/Cryptography, I can't seem to find any loading instructions. I will try. It's a simple all-in-one mcz from the old days. Levente snip |
|
|
In reply to this post by Levente Uzonyi-2
I don't know deeply the WebClient implementation, but is not the same
than in Crypto package? Apart of this I prefer pure image code (not relying in plugins). Finally, if some work ordering/renaming/etc the Crypto packages is needed, let me know, I can help because I'm also doing somethings to myself with these code. Cheers. Germán. 2011/5/11 Levente Uzonyi <[hidden email]>: > There was a plan to add the whole Cryptography package (split to three > packages) to the Trunk. Some older versions are waiting in the Inbox (see > CryptoCore, CryptoCerts and CryptoExtras). IIRC this process is stalled > because the proper renaming of the packages didn't happen (Cryptography > instead of Crypto). If the renaming is done, then Squeak will have a working > MD5 implementation out of the box. > > Another solution is to grab the MD5 implementation from WebClient (which is > probably the same as in Croquet, since it uses the CroquetPlugin if > available). > > What do you think? > > > Levente > > |
Re: MD5 for Squeak (was: Re: [squeak-dev] Re: Some question regarding portability)
|
|
On Wed, 11 May 2011, Germán Arduino wrote:
> I don't know deeply the WebClient implementation, but is not the same > than in Crypto package? No, it's not. > > Apart of this I prefer pure image code (not relying in plugins). Both the WebClient version and the one in the Cryptography package work with or without plugin support. > > Finally, if some work ordering/renaming/etc the Crypto packages is > needed, let me know, I can help because I'm also doing somethings to > myself with these code. It depends on the community's decision. Levente > > Cheers. > Germán. > > > 2011/5/11 Levente Uzonyi <[hidden email]>: >> There was a plan to add the whole Cryptography package (split to three >> packages) to the Trunk. Some older versions are waiting in the Inbox (see >> CryptoCore, CryptoCerts and CryptoExtras). IIRC this process is stalled >> because the proper renaming of the packages didn't happen (Cryptography >> instead of Crypto). If the renaming is done, then Squeak will have a working >> MD5 implementation out of the box. >> >> Another solution is to grab the MD5 implementation from WebClient (which is >> probably the same as in Croquet, since it uses the CroquetPlugin if >> available). >> >> What do you think? >> >> >> Levente >> >> > > |
|
|
2011/5/11 Levente Uzonyi <[hidden email]>:
> On Wed, 11 May 2011, Germán Arduino wrote: > >> I don't know deeply the WebClient implementation, but is not the same >> than in Crypto package? > > No, it's not. > >> >> Apart of this I prefer pure image code (not relying in plugins). > > Both the WebClient version and the one in the Cryptography package work > with or without plugin support. > >> >> Finally, if some work ordering/renaming/etc the Crypto packages is >> needed, let me know, I can help because I'm also doing somethings to >> myself with these code. > > It depends on the community's decision. > > ok, I checked the inbox and how are built the packages. If the community decide something I can help updating the packages and making them availables. I personally am not sure about the better way of separate and package all these stuff, but is a matter of discussion also. As far as I saw exist different opinions, from maintain all together until split in lot of different packages. Cheers. |
RE: MD5 for Squeak (was: Re: [squeak-dev] Re: Some question regarding portability)
|
|
In reply to this post by Levente Uzonyi-2
Hi All,
I think that works. The basic separation from core and extra functionality is a good move. 3 packages is better than dozens. I know that Andreas also made a SqueakSSL repository which is specifically for TLS/SSL. That certainly works since it will get used there and fixed but it is also likely that SSL will bit rot here if everyone is focused there. It might make sense to move our SSL and cert stuff to Andreas' repository (if there is anything still here that is needed by developers that doesn't exist there and Andreas wants it, or include his package here with the rest) and focus on Core functions here? In general cleaning things up so that what we have posted works is a good idea. If we can get things loaded by default, and have other things loadable in small understandable packages, then that works for me too. Other thoughts? Ron Teitelbaum > -----Original Message----- > From: [hidden email] [mailto:squeak- > [hidden email]] On Behalf Of Levente Uzonyi > Sent: Wednesday, May 11, 2011 5:49 PM > To: The general-purpose Squeak developers list > Subject: MD5 for Squeak (was: Re: [squeak-dev] Re: Some question > regarding portability) > > There was a plan to add the whole Cryptography package (split to three > packages) to the Trunk. Some older versions are waiting in the Inbox (see > CryptoCore, CryptoCerts and CryptoExtras). IIRC this process is stalled > because the proper renaming of the packages didn't happen (Cryptography > instead of Crypto). If the renaming is done, then Squeak will have a > MD5 implementation out of the box. > > Another solution is to grab the MD5 implementation from WebClient (which > is probably the same as in Croquet, since it uses the CroquetPlugin if > available). > > What do you think? > > > Levente |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |