You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/04/06 13:21:46 UTC
select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
We have pairs of implementations for the following functionality
(modules luni and security):
ASN1 De/Encoding
Base64 De/Encoding
DefaultPolicy
I'm going to compare and choose one them but I'd appreciate if someone
else would compare them too.
Thanks,
Mikhail
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mark Hindess wrote:
> On 4/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>
>> My real fear is that we'd collectively forget. Maybe I'm just projecting :)
>
> No comment. ;-)
Pthbbb.
>
>> So how about this - why don't we put a text file somewhere (in SVN!) in
>> which we "log" major things that we delete, and put the svn rev # of
>> where it was live.
>
> Or we could just move archive out of the classlib/trunk?
That works. classlib/../archive
Done.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Mark Hindess wrote:
> > Mikhail, Thanks for the pointers.
> >
> > I dug back in the mail archives. Geir wrote:
> >
> >> I think of it still as "live material" in our tree, but I don't
> >> feel too strongly about this. If we keep it there, we should set a
> >> policy to expire it out of there at some point.
> >
> > I'd suggest that the two files that you mention which are "never used"
> > probably don't qualify as "live material". ;-)
>
> Agreed.
>
> >
> > So, now my question is when is it going to be expired? i'd suggest
> > that anything moved to archive should have an expiry date set in a
> > file or svn property when it is moved so it is clear when it will be
> > removed.
> >
> > Personally, I still think having paths archive/modules and
> > modules/archive is confusing. 99% of our users will never use the
> > extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1%
> > who might want it can easily find it in svn.
>
> The only reason we stuck security in an archive/modules was because we
> wanted an easy way to be copying things that we found useful to the live
> version - mainly javadoc and such. We were afraid that if we deleted
> it, it would be a pain to do that.
That's a good point.
I'd forgotten that it was a little easier to create HARMONY-277 with
archive where it was. Still, it'd be just as easy with archive out of
the main tree too.
> My real fear is that we'd collectively forget. Maybe I'm just projecting :)
No comment. ;-)
> So how about this - why don't we put a text file somewhere (in SVN!) in
> which we "log" major things that we delete, and put the svn rev # of
> where it was live.
Or we could just move archive out of the classlib/trunk?
> That way we don't forget what we've tossed, and also make it easy to get
> something back, w/o having to play "wack-a-mole" with the version numbers...
>
> Also, if it's small stuff, I assume that there's no reason to log unless
> someone squawks...?
If we moved the files out of classlib/trunk then we'd have a log of
all the moves for free with "svn log
https://svn.apache.org/.../archive".
I should point out that would help to make what is being moved
explicit in the log message... the log message from the security move
says:
moving to archive so we can harvest the javadoc easily at
some point in near future
which might be a rather common for an archive tree.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mark Hindess wrote:
> Mikhail, Thanks for the pointers.
>
> I dug back in the mail archives. Geir wrote:
>
>> I think of it still as "live material" in our tree, but I don't
>> feel too strongly about this. If we keep it there, we should set a
>> policy to expire it out of there at some point.
>
> I'd suggest that the two files that you mention which are "never used"
> probably don't qualify as "live material". ;-)
Agreed.
>
> So, now my question is when is it going to be expired? i'd suggest
> that anything moved to archive should have an expiry date set in a
> file or svn property when it is moved so it is clear when it will be
> removed.
>
> Personally, I still think having paths archive/modules and
> modules/archive is confusing. 99% of our users will never use the
> extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1%
> who might want it can easily find it in svn.
The only reason we stuck security in an archive/modules was because we
wanted an easy way to be copying things that we found useful to the live
version - mainly javadoc and such. We were afraid that if we deleted
it, it would be a pain to do that.
My real fear is that we'd collectively forget. Maybe I'm just projecting :)
So how about this - why don't we put a text file somewhere (in SVN!) in
which we "log" major things that we delete, and put the svn rev # of
where it was live.
That way we don't forget what we've tossed, and also make it easy to get
something back, w/o having to play "wack-a-mole" with the version numbers...
Also, if it's small stuff, I assume that there's no reason to log unless
someone squawks...?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Mark Hindess <ma...@googlemail.com>.
Mikhail, Thanks for the pointers.
I dug back in the mail archives. Geir wrote:
> I think of it still as "live material" in our tree, but I don't
> feel too strongly about this. If we keep it there, we should set a
> policy to expire it out of there at some point.
I'd suggest that the two files that you mention which are "never used"
probably don't qualify as "live material". ;-)
So, now my question is when is it going to be expired? i'd suggest
that anything moved to archive should have an expiry date set in a
file or svn property when it is moved so it is clear when it will be
removed.
Personally, I still think having paths archive/modules and
modules/archive is confusing. 99% of our users will never use the
extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1%
who might want it can easily find it in svn.
Regards,
Mark.
On 4/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
> We have a precedent of archiving a duplicating functionality - IBM
> security module
> was moved to archive/modules/security
>
> It was discussed in threads
> [classlib] security2 -> security
> and
> [classlib] security moved
>
> Thanks,
> Mikhail
>
> 2006/4/10, Mark Hindess <ma...@googlemail.com>:
> > What is the archive tree for? Why not just remove them and let svn
> > take care of "archiving" them? (This also means users don't have to
> > check out unnecessary files.)
> >
> > -Mark.
> >
> > On 4/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > luni ASN1 De/Encoder is never used.
> > >
> > > luni Base64 decoder is faster vs. corresponding security class, but it has
> > > a bug for which I do not see a quick fix: it does not support /n and
> > > /r characters
> > > in encoded form. Adding of that support would slow down luni implementation.
> > >
> > > luni DefaultPolicy is currently never used.
> > >
> > > So I suggest moving luni classes to archive/modules.
> > >
> > > Comments?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > >
> > > 2006/4/6, Mikhail Loenko <ml...@gmail.com>:
> > > > We have pairs of implementations for the following functionality
> > > > (modules luni and security):
> > > >
> > > > ASN1 De/Encoding
> > > > Base64 De/Encoding
> > > > DefaultPolicy
> > > >
> > > > I'm going to compare and choose one them but I'd appreciate if someone
> > > > else would compare them too.
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Mark Hindess <ma...@googlemail.com>
> > IBM Java Technology Centre, UK.
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Mikhail Loenko <ml...@gmail.com>.
We have a precedent of archiving a duplicating functionality - IBM
security module
was moved to archive/modules/security
It was discussed in threads
[classlib] security2 -> security
and
[classlib] security moved
Thanks,
Mikhail
2006/4/10, Mark Hindess <ma...@googlemail.com>:
> What is the archive tree for? Why not just remove them and let svn
> take care of "archiving" them? (This also means users don't have to
> check out unnecessary files.)
>
> -Mark.
>
> On 4/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > luni ASN1 De/Encoder is never used.
> >
> > luni Base64 decoder is faster vs. corresponding security class, but it has
> > a bug for which I do not see a quick fix: it does not support /n and
> > /r characters
> > in encoded form. Adding of that support would slow down luni implementation.
> >
> > luni DefaultPolicy is currently never used.
> >
> > So I suggest moving luni classes to archive/modules.
> >
> > Comments?
> >
> > Thanks,
> > Mikhail
> >
> >
> > 2006/4/6, Mikhail Loenko <ml...@gmail.com>:
> > > We have pairs of implementations for the following functionality
> > > (modules luni and security):
> > >
> > > ASN1 De/Encoding
> > > Base64 De/Encoding
> > > DefaultPolicy
> > >
> > > I'm going to compare and choose one them but I'd appreciate if someone
> > > else would compare them too.
> > >
> > > Thanks,
> > > Mikhail
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Mark Hindess <ma...@googlemail.com>.
What is the archive tree for? Why not just remove them and let svn
take care of "archiving" them? (This also means users don't have to
check out unnecessary files.)
-Mark.
On 4/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
> luni ASN1 De/Encoder is never used.
>
> luni Base64 decoder is faster vs. corresponding security class, but it has
> a bug for which I do not see a quick fix: it does not support /n and
> /r characters
> in encoded form. Adding of that support would slow down luni implementation.
>
> luni DefaultPolicy is currently never used.
>
> So I suggest moving luni classes to archive/modules.
>
> Comments?
>
> Thanks,
> Mikhail
>
>
> 2006/4/6, Mikhail Loenko <ml...@gmail.com>:
> > We have pairs of implementations for the following functionality
> > (modules luni and security):
> >
> > ASN1 De/Encoding
> > Base64 De/Encoding
> > DefaultPolicy
> >
> > I'm going to compare and choose one them but I'd appreciate if someone
> > else would compare them too.
> >
> > Thanks,
> > Mikhail
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Posted by Mikhail Loenko <ml...@gmail.com>.
luni ASN1 De/Encoder is never used.
luni Base64 decoder is faster vs. corresponding security class, but it has
a bug for which I do not see a quick fix: it does not support /n and
/r characters
in encoded form. Adding of that support would slow down luni implementation.
luni DefaultPolicy is currently never used.
So I suggest moving luni classes to archive/modules.
Comments?
Thanks,
Mikhail
2006/4/6, Mikhail Loenko <ml...@gmail.com>:
> We have pairs of implementations for the following functionality
> (modules luni and security):
>
> ASN1 De/Encoding
> Base64 De/Encoding
> DefaultPolicy
>
> I'm going to compare and choose one them but I'd appreciate if someone
> else would compare them too.
>
> Thanks,
> Mikhail
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org