June 25, 2012
On Monday, June 25, 2012 12:24:44 Piotr Szturmaj wrote:
> Jonathan M Davis wrote:
> > On Monday, June 25, 2012 11:35:33 Johannes Pfau wrote:
> >> OK, so I understand std.util is probably not a good idea.
> >> 
> >> So the candidates for the namespace are:
> >> * std.crypto.hash
> >> * std.checksum
> >> * std.crypto.hash and std.checksum
> >> * std.hash
> >> 
> >> and the same with hash replaced by digest.
> >> So which one should we use?
> > 
> > The previous discussions on this resulted in us going with std.hash.md5, std.hash.sha1, and std.hash.crc32. I don't see any reason to change that, and crypto was specifically _not_ chosen, because crc32 isn't cryptographically sound. But std.hash encompasses things quite nicely, since they're all hashes.
> IMHO crypto should be chosen because beside of hashes there are other cryptographic primitives (ciphers, PKI, MACs, etc.) and it would be nice to have them in one place. std.hash is too narrow because when std gets crypto there will be too many namespaces like std.ciphers, std.ssl, std.mac. All of them will nicely fit in std.crypto or similar.
> 
> As you can see crypto isn't good candidate for checksums so another package std.checksum is proposed. Likewise mixing checksums and cryptographic hashes under one namespace (std.hash) isn't a right choice IMO.
> 
> Having cryptographic primitives splitted to std.hash and std.crypto.* isn't a good choice either.

Except that the same hashes could be used for either checksums or crypto stuff. It makes no sense to sense to split them between two packages. And you could probably get into arguments over whether any particular hash was cryptographically sound, particularly since that can change over time, can't it, given that at least part of what determines whether a hash is considered cryptographically sound is how easy it is to break. SHA-1 may or may not be considered cryptographically sound now, but it sure won't be forever, so putting it in std.crypto would become decreasingly accurate over time.

So, as far as the hashes go, it makes the most sense IMHO to just stuff them all in std.hash and be done with it. If we ever end up adding crypto-specific stuff to Phobos, then that stuff can go in std.crypto, but the hashes are _not_ crypto-specific. They just so happen to be used in cryptography. They aren't restricted to it.

- Jonathan M Davis
June 25, 2012
+1 for
hashes into std.hash
and cryptographic primitives into std.crypto

and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...),
std.io. for (Outbuffer, file, ....)
and probably std.database or something like that for (csv, json, xml, ...)

...


Am 25.06.2012, 17:31 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Monday, June 25, 2012 12:24:44 Piotr Szturmaj wrote:
>> Jonathan M Davis wrote:
>> > On Monday, June 25, 2012 11:35:33 Johannes Pfau wrote:
>> >> OK, so I understand std.util is probably not a good idea.
>> >>
>> >> So the candidates for the namespace are:
>> >> * std.crypto.hash
>> >> * std.checksum
>> >> * std.crypto.hash and std.checksum
>> >> * std.hash
>> >>
>> >> and the same with hash replaced by digest.
>> >> So which one should we use?
>> >
>> > The previous discussions on this resulted in us going with  
>> std.hash.md5,
>> > std.hash.sha1, and std.hash.crc32. I don't see any reason to change  
>> that,
>> > and crypto was specifically _not_ chosen, because crc32 isn't
>> > cryptographically sound. But std.hash encompasses things quite nicely,
>> > since they're all hashes.
>> IMHO crypto should be chosen because beside of hashes there are other
>> cryptographic primitives (ciphers, PKI, MACs, etc.) and it would be nice
>> to have them in one place. std.hash is too narrow because when std gets
>> crypto there will be too many namespaces like std.ciphers, std.ssl,
>> std.mac. All of them will nicely fit in std.crypto or similar.
>>
>> As you can see crypto isn't good candidate for checksums so another
>> package std.checksum is proposed. Likewise mixing checksums and
>> cryptographic hashes under one namespace (std.hash) isn't a right choice
>> IMO.
>>
>> Having cryptographic primitives splitted to std.hash and std.crypto.*
>> isn't a good choice either.
>
> Except that the same hashes could be used for either checksums or crypto stuff.
> It makes no sense to sense to split them between two packages. And you could
> probably get into arguments over whether any particular hash was
> cryptographically sound, particularly since that can change over time, can't
> it, given that at least part of what determines whether a hash is considered
> cryptographically sound is how easy it is to break. SHA-1 may or may not be
> considered cryptographically sound now, but it sure won't be forever, so
> putting it in std.crypto would become decreasingly accurate over time.
>
> So, as far as the hashes go, it makes the most sense IMHO to just stuff them
> all in std.hash and be done with it. If we ever end up adding crypto-specific
> stuff to Phobos, then that stuff can go in std.crypto, but the hashes are _not_
> crypto-specific. They just so happen to be used in cryptography. They aren't
> restricted to it.
>
> - Jonathan M Davis


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
June 25, 2012
On 25-Jun-12 20:09, Felix Hufnagel wrote:
> +1 for
> hashes into std.hash
> and cryptographic primitives into std.crypto
Another +1 here

> and we should have  std.net (std.uri, std.socket, std.socketstream ,
> std.net.curl, ...),
> std.io for proper I/O framework.
> and probably std.data or something like that for (csv, json, xml, ...)


Fixed :)


-- 
Dmitry Olshansky


June 25, 2012
On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote:
> +1 for
> hashes into std.hash
> and cryptographic primitives into std.crypto
>
> and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...),
> std.io. for (Outbuffer, file, ....)
> and probably std.database or something like that for (csv, json, xml, ...)
>
> ...


I couldn't agree more.
June 25, 2012
On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote:
> +1 for
> hashes into std.hash
> and cryptographic primitives into std.crypto
>
> and we should have a std.net (std.uri, std.socket, std.socketstream , std.net.curl, ...),
> std.io. for (Outbuffer, file, ....)
> and probably std.database or something like that for (csv, json, xml, ...)

I'd be for not being so flat.
June 29, 2012
On 25/06/12 20:04, Jesse Phillips wrote:
> On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote:
>> +1 for
>> hashes into std.hash
>> and cryptographic primitives into std.crypto
>>
>> and we should have a std.net (std.uri, std.socket, std.socketstream ,
>> std.net.curl, ...),
>> std.io. for (Outbuffer, file, ....)
>> and probably std.database or something like that for (csv, json, xml,
>> ...)
>
> I'd be for not being so flat.

I reckon, follow biology.
There's kingdom.phyllus.class.order.family.genus.species
But in practice, that's far too clumsy. Instead, everyone just uses genus.species. And this works even though there are more than a million species.

So I reckon two levels of modules is enough. More than that is clumsy.
And, if you're not sure where something should be, because there are two or more equally valid alternatives, it should probably be a level closer to the root of the tree.

June 29, 2012
Don Clugston wrote:
> On 25/06/12 20:04, Jesse Phillips wrote:
>> On Monday, 25 June 2012 at 16:09:43 UTC, Felix Hufnagel wrote:
>>> +1 for
>>> hashes into std.hash
>>> and cryptographic primitives into std.crypto
>>>
>>> and we should have a std.net (std.uri, std.socket, std.socketstream ,
>>> std.net.curl, ...),
>>> std.io. for (Outbuffer, file, ....)
>>> and probably std.database or something like that for (csv, json, xml,
>>> ...)
>>
>> I'd be for not being so flat.
>
> I reckon, follow biology.
> There's kingdom.phyllus.class.order.family.genus.species
> But in practice, that's far too clumsy. Instead, everyone just uses
> genus.species. And this works even though there are more than a million
> species.
>
> So I reckon two levels of modules is enough. More than that is clumsy.
> And, if you're not sure where something should be, because there are two
> or more equally valid alternatives, it should probably be a level closer
> to the root of the tree.

I'd not generalize that much. Sometimes two levels are enough, sometimes there are three or more. I'd say "It depends" :)

And yes, I think we should have std.net package. Hey, packages were created for that!
1 2 3
Next ›   Last »