jsdsi-devel

[Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

Guys,

I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
names:

Algorithms
DigestUtils
SignatureUtils


 - not implemented any of them yet as want input/comments first.

The idea being that in Algorithms there is a list of constants which
clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
There are then utility methods to calculate the SPKI or JDK versions of
such (This includes the problematic Signatures).

I would suggest the following coding ethos is JSDSI:

1. jsdsi object constructors that need algorythm names use SPKI format
names (this is what they should use now as that is the format dumped to
Sexpression, and consequently read from a stream)

Not so sure about Hash.. has anyone looked at an Sexpression for hash
and know that if you supply MD5 it comes out (incorrectly) in upper case
in the Sexpression? I guess the current implementation would cause a
problem with SHA-1? (as in SPKI that should be sha1).

Which then begs the question: should Hash.getAlgorithm() return the SPKI
or JDK version (I guess JDK to be consistent with Key and Signature)?



2. static create methods use the constants for easy client use.

The question I have for this is about jsdsi.Signature. Should the create
methods take a digest constant and from that calculate the JDK Signature
algorythm and corresponding SPKI algorythm using the provided constant
and by examining the given keypair?



Thoughts? (in particular problems this approach would lead to with
existing applications)


Sean

 

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

I guess we could change Algorithms from using straight Strings for the
constants to an Enum class style for type-safety.

Something akin to:

http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
 

Sean

On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> Guys,
> 
> I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> names:
> 
> Algorithms
> DigestUtils
> SignatureUtils
> 
> 
>  - not implemented any of them yet as want input/comments first.
> 
> The idea being that in Algorithms there is a list of constants which
> clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> There are then utility methods to calculate the SPKI or JDK versions of
> such (This includes the problematic Signatures).
> 
> I would suggest the following coding ethos is JSDSI:
> 
> 1. jsdsi object constructors that need algorythm names use SPKI format
> names (this is what they should use now as that is the format dumped to
> Sexpression, and consequently read from a stream)
> 
> Not so sure about Hash.. has anyone looked at an Sexpression for hash
> and know that if you supply MD5 it comes out (incorrectly) in upper case
> in the Sexpression? I guess the current implementation would cause a
> problem with SHA-1? (as in SPKI that should be sha1).
> 
> Which then begs the question: should Hash.getAlgorithm() return the SPKI
> or JDK version (I guess JDK to be consistent with Key and Signature)?
> 
> 
> 
> 2. static create methods use the constants for easy client use.
> 
> The question I have for this is about jsdsi.Signature. Should the create
> methods take a digest constant and from that calculate the JDK Signature
> algorythm and corresponding SPKI algorythm using the provided constant
> and by examining the given keypair?
> 
> 
> 
> Thoughts? (in particular problems this approach would lead to with
> existing applications)
> 
> 
> Sean
> 
>  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

Been thinking and I believe that the Enum way of going is a good idea
and so converted the util classes to them.

So in CVS there is my proposal of how to do things. Let me know what you
think.

Sean


On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> I guess we could change Algorithms from using straight Strings for the
> constants to an Enum class style for type-safety.
> 
> Something akin to:
> 
> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>  
> 
> Sean
> 
> On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> > Guys,
> > 
> > I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> > names:
> > 
> > Algorithms
> > DigestUtils
> > SignatureUtils
> > 
> > 
> >  - not implemented any of them yet as want input/comments first.
> > 
> > The idea being that in Algorithms there is a list of constants which
> > clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> > There are then utility methods to calculate the SPKI or JDK versions of
> > such (This includes the problematic Signatures).
> > 
> > I would suggest the following coding ethos is JSDSI:
> > 
> > 1. jsdsi object constructors that need algorythm names use SPKI format
> > names (this is what they should use now as that is the format dumped to
> > Sexpression, and consequently read from a stream)
> > 
> > Not so sure about Hash.. has anyone looked at an Sexpression for hash
> > and know that if you supply MD5 it comes out (incorrectly) in upper case
> > in the Sexpression? I guess the current implementation would cause a
> > problem with SHA-1? (as in SPKI that should be sha1).
> > 
> > Which then begs the question: should Hash.getAlgorithm() return the SPKI
> > or JDK version (I guess JDK to be consistent with Key and Signature)?
> > 
> > 
> > 
> > 2. static create methods use the constants for easy client use.
> > 
> > The question I have for this is about jsdsi.Signature. Should the create
> > methods take a digest constant and from that calculate the JDK Signature
> > algorythm and corresponding SPKI algorythm using the provided constant
> > and by examining the given keypair?
> > 
> > 
> > 
> > Thoughts? (in particular problems this approach would lead to with
> > existing applications)
> > 
> > 
> > Sean
> > 
> >  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

[Sameer A. <aj...@cs...>]

I don't have time to look at this right now, but I am interested in
checking out the design.  Please mark any additions as "experimental" or
somesuch, because we may want to revise it in the near future.

Thanks,
Sameer

> Been thinking and I believe that the Enum way of going is a good idea
> and so converted the util classes to them.
>
> So in CVS there is my proposal of how to do things. Let me know what you
> think.
>
> Sean
>
>
> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> I guess we could change Algorithms from using straight Strings for the
>> constants to an Enum class style for type-safety.
>>
>> Something akin to:
>>
>> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>>
>>
>> Sean
>>
>> On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> > Guys,
>> >
>> > I've committed to cvs 3 classes in jsdsi.util for handling of
>> algorythm names:
>> >
>> > Algorithms
>> > DigestUtils
>> > SignatureUtils
>> >
>> >
>> >  - not implemented any of them yet as want input/comments first.
>> >
>> > The idea being that in Algorithms there is a list of constants which
>> clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA,
>> etc. There are then utility methods to calculate the SPKI or JDK
>> versions of such (This includes the problematic Signatures).
>> >
>> > I would suggest the following coding ethos is JSDSI:
>> >
>> > 1. jsdsi object constructors that need algorythm names use SPKI
>> format names (this is what they should use now as that is the format
>> dumped to Sexpression, and consequently read from a stream)
>> >
>> > Not so sure about Hash.. has anyone looked at an Sexpression for
>> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be sha1).
>> >
>> > Which then begs the question: should Hash.getAlgorithm() return the
>> SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> >
>> >
>> >
>> > 2. static create methods use the constants for easy client use.
>> >
>> > The question I have for this is about jsdsi.Signature. Should the
>> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> >
>> >
>> >
>> > Thoughts? (in particular problems this approach would lead to with
>> existing applications)
>> >
>> >
>> > Sean
>> >
>> >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
>  Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

Hi,

Don't suppose any of you have had a chance to look my classes - I'm
going to need to cope with varying algos in the very very near future so
would like to take a crack at it.

(If no one has had a chance, how do you all feel about me making a cvs
branch?)

Sean

On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
> Been thinking and I believe that the Enum way of going is a good idea
> and so converted the util classes to them.
> 
> So in CVS there is my proposal of how to do things. Let me know what you
> think.
> 
> Sean
> 
> 
> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> > I guess we could change Algorithms from using straight Strings for the
> > constants to an Enum class style for type-safety.
> > 
> > Something akin to:
> > 
> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
> >  
> > 
> > Sean
> > 
> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> > > Guys,
> > > 
> > > I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> > > names:
> > > 
> > > Algorithms
> > > DigestUtils
> > > SignatureUtils
> > > 
> > > 
> > >  - not implemented any of them yet as want input/comments first.
> > > 
> > > The idea being that in Algorithms there is a list of constants which
> > > clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> > > There are then utility methods to calculate the SPKI or JDK versions of
> > > such (This includes the problematic Signatures).
> > > 
> > > I would suggest the following coding ethos is JSDSI:
> > > 
> > > 1. jsdsi object constructors that need algorythm names use SPKI format
> > > names (this is what they should use now as that is the format dumped to
> > > Sexpression, and consequently read from a stream)
> > > 
> > > Not so sure about Hash.. has anyone looked at an Sexpression for hash
> > > and know that if you supply MD5 it comes out (incorrectly) in upper case
> > > in the Sexpression? I guess the current implementation would cause a
> > > problem with SHA-1? (as in SPKI that should be sha1).
> > > 
> > > Which then begs the question: should Hash.getAlgorithm() return the SPKI
> > > or JDK version (I guess JDK to be consistent with Key and Signature)?
> > > 
> > > 
> > > 
> > > 2. static create methods use the constants for easy client use.
> > > 
> > > The question I have for this is about jsdsi.Signature. Should the create
> > > methods take a digest constant and from that calculate the JDK Signature
> > > algorythm and corresponding SPKI algorythm using the provided constant
> > > and by examining the given keypair?
> > > 
> > > 
> > > 
> > > Thoughts? (in particular problems this approach would lead to with
> > > existing applications)
> > > 
> > > 
> > > Sean
> > > 
> > >  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

[Sameer A. <aj...@cs...>]

I'm not familiar with cvs branches, but if this is a good solution for
you, go for it.  I won't have a chance to look at JSDSI for about two
months (dissertation crunch)!  However, if your algorithm change is
compatible with older versions (won't break existing code), then there's
probably no harm in checking it in.

Sameer

> Hi,
>
> Don't suppose any of you have had a chance to look my classes - I'm
> going to need to cope with varying algos in the very very near future so
> would like to take a crack at it.
>
> (If no one has had a chance, how do you all feel about me making a cvs
> branch?)
>
> Sean
>
> On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
>> Been thinking and I believe that the Enum way of going is a good idea
>> and so converted the util classes to them.
>>
>> So in CVS there is my proposal of how to do things. Let me know what
>> you think.
>>
>> Sean
>>
>>
>> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> > I guess we could change Algorithms from using straight Strings for
>> the constants to an Enum class style for type-safety.
>> >
>> > Something akin to:
>> >
>> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>> >
>> >
>> > Sean
>> >
>> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> > > Guys,
>> > >
>> > > I've committed to cvs 3 classes in jsdsi.util for handling of
>> algorythm names:
>> > >
>> > > Algorithms
>> > > DigestUtils
>> > > SignatureUtils
>> > >
>> > >
>> > >  - not implemented any of them yet as want input/comments first.
>> > >
>> > > The idea being that in Algorithms there is a list of constants
>> which clients use to indicate what they desire, e.g. DIGEST_MD5,
>> KEY_RSA, etc. There are then utility methods to calculate the SPKI
>> or JDK versions of such (This includes the problematic
>> Signatures).
>> > >
>> > > I would suggest the following coding ethos is JSDSI:
>> > >
>> > > 1. jsdsi object constructors that need algorythm names use SPKI
>> format names (this is what they should use now as that is the
>> format dumped to Sexpression, and consequently read from a stream)
>> > >
>> > > Not so sure about Hash.. has anyone looked at an Sexpression for
>> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be
>> sha1).
>> > >
>> > > Which then begs the question: should Hash.getAlgorithm() return
>> the SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> > >
>> > >
>> > >
>> > > 2. static create methods use the constants for easy client use.
>> > >
>> > > The question I have for this is about jsdsi.Signature. Should the
>> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> > >
>> > >
>> > >
>> > > Thoughts? (in particular problems this approach would lead to with
>> existing applications)
>> > >
>> > >
>> > > Sean
>> > >
>> > >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

On Wed, 2004-06-09 at 17:04, Sameer Ajmani wrote:
> I'm not familiar with cvs branches, but if this is a good solution for
> you, go for it.  I won't have a chance to look at JSDSI for about two
> months (dissertation crunch)!  However, if your algorithm change is
> compatible with older versions (won't break existing code), then there's
> probably no harm in checking it in.
> 
It better not break old code or existing stored objects as I have apps
running now with the current stuff.

Will probably create a branch to be on the safe-side though.


Good luck with the dissertation - I'll try not to bother you with
questions.

Sean

> Sameer
> 
> > Hi,
> >
> > Don't suppose any of you have had a chance to look my classes - I'm
> > going to need to cope with varying algos in the very very near future so
> > would like to take a crack at it.
> >
> > (If no one has had a chance, how do you all feel about me making a cvs
> > branch?)
> >
> > Sean
> >
> > On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
> >> Been thinking and I believe that the Enum way of going is a good idea
> >> and so converted the util classes to them.
> >>
> >> So in CVS there is my proposal of how to do things. Let me know what
> >> you think.
> >>
> >> Sean
> >>
> >>
> >> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> >> > I guess we could change Algorithms from using straight Strings for
> >> the constants to an Enum class style for type-safety.
> >> >
> >> > Something akin to:
> >> >
> >> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
> >> >
> >> >
> >> > Sean
> >> >
> >> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> >> > > Guys,
> >> > >
> >> > > I've committed to cvs 3 classes in jsdsi.util for handling of
> >> algorythm names:
> >> > >
> >> > > Algorithms
> >> > > DigestUtils
> >> > > SignatureUtils
> >> > >
> >> > >
> >> > >  - not implemented any of them yet as want input/comments first.
> >> > >
> >> > > The idea being that in Algorithms there is a list of constants
> >> which clients use to indicate what they desire, e.g. DIGEST_MD5,
> >> KEY_RSA, etc. There are then utility methods to calculate the SPKI
> >> or JDK versions of such (This includes the problematic
> >> Signatures).
> >> > >
> >> > > I would suggest the following coding ethos is JSDSI:
> >> > >
> >> > > 1. jsdsi object constructors that need algorythm names use SPKI
> >> format names (this is what they should use now as that is the
> >> format dumped to Sexpression, and consequently read from a stream)
> >> > >
> >> > > Not so sure about Hash.. has anyone looked at an Sexpression for
> >> hash and know that if you supply MD5 it comes out (incorrectly) in
> >> upper case in the Sexpression? I guess the current implementation
> >> would cause a problem with SHA-1? (as in SPKI that should be
> >> sha1).
> >> > >
> >> > > Which then begs the question: should Hash.getAlgorithm() return
> >> the SPKI or JDK version (I guess JDK to be consistent with Key and
> >> Signature)?
> >> > >
> >> > >
> >> > >
> >> > > 2. static create methods use the constants for easy client use.
> >> > >
> >> > > The question I have for this is about jsdsi.Signature. Should the
> >> create methods take a digest constant and from that calculate the
> >> JDK Signature algorythm and corresponding SPKI algorythm using the
> >> provided constant and by examining the given keypair?
> >> > >
> >> > >
> >> > >
> >> > > Thoughts? (in particular problems this approach would lead to with
> >> existing applications)
> >> > >
> >> > >
> >> > > Sean
> >> > >
> >> > >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

[Sameer A. <aj...@cs...>]

Feel free to send questions -- I like to at least read about what's going
on, even if I can't contribute right now :)

Sameer

> On Wed, 2004-06-09 at 17:04, Sameer Ajmani wrote:
>> I'm not familiar with cvs branches, but if this is a good solution for
>> you, go for it.  I won't have a chance to look at JSDSI for about two
>> months (dissertation crunch)!  However, if your algorithm change is
>> compatible with older versions (won't break existing code), then
>> there's probably no harm in checking it in.
>>
> It better not break old code or existing stored objects as I have apps
> running now with the current stuff.
>
> Will probably create a branch to be on the safe-side though.
>
>
> Good luck with the dissertation - I'll try not to bother you with
> questions.
>
> Sean
>
>> Sameer
>>
>> > Hi,
>> >
>> > Don't suppose any of you have had a chance to look my classes - I'm
>> going to need to cope with varying algos in the very very near
>> future so would like to take a crack at it.
>> >
>> > (If no one has had a chance, how do you all feel about me making a
>> cvs branch?)
>> >
>> > Sean
>> >
>> > On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
>> >> Been thinking and I believe that the Enum way of going is a good
>> idea and so converted the util classes to them.
>> >>
>> >> So in CVS there is my proposal of how to do things. Let me know
>> what you think.
>> >>
>> >> Sean
>> >>
>> >>
>> >> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> >> > I guess we could change Algorithms from using straight Strings
>> for
>> >> the constants to an Enum class style for type-safety.
>> >> >
>> >> > Something akin to:
>> >> >
>> >> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>> >> >
>> >> >
>> >> > Sean
>> >> >
>> >> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> >> > > Guys,
>> >> > >
>> >> > > I've committed to cvs 3 classes in jsdsi.util for handling of
>> >> algorythm names:
>> >> > >
>> >> > > Algorithms
>> >> > > DigestUtils
>> >> > > SignatureUtils
>> >> > >
>> >> > >
>> >> > >  - not implemented any of them yet as want input/comments
>> first.
>> >> > >
>> >> > > The idea being that in Algorithms there is a list of constants
>> >> which clients use to indicate what they desire, e.g. DIGEST_MD5,
>> KEY_RSA, etc. There are then utility methods to calculate the SPKI
>> or JDK versions of such (This includes the problematic
>> >> Signatures).
>> >> > >
>> >> > > I would suggest the following coding ethos is JSDSI:
>> >> > >
>> >> > > 1. jsdsi object constructors that need algorythm names use SPKI
>> >> format names (this is what they should use now as that is the
>> format dumped to Sexpression, and consequently read from a stream)
>> >> > >
>> >> > > Not so sure about Hash.. has anyone looked at an Sexpression
>> for
>> >> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be
>> >> sha1).
>> >> > >
>> >> > > Which then begs the question: should Hash.getAlgorithm() return
>> >> the SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> >> > >
>> >> > >
>> >> > >
>> >> > > 2. static create methods use the constants for easy client use.
>> >> > >
>> >> > > The question I have for this is about jsdsi.Signature. Should
>> the
>> >> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> >> > >
>> >> > >
>> >> > >
>> >> > > Thoughts? (in particular problems this approach would lead to
>> with
>> >> existing applications)
>> >> > >
>> >> > >
>> >> > > Sean
>> >> > >
>> >> > >
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>> > http://www.aegeus-technology.com
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > This SF.Net email is sponsored by: GNOME Foundation
>> > Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>> GNOME Users and Developers European Conference, 28-30th June in
>> Norway http://2004/guadec.org
>> > _______________________________________________
>> > Jsdsi-devel mailing list
>> > Jsd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>>
>>
>> http://ajmani.net
>>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net