Is it ready to use?

[gabrielcipriano]

What are the next steps for us to have a release?

[lukechen116]

The current version has been optimized and thoroughly tested. And I have already implemented the current version in the project I am working on. I will not update immediately unless there are significant errors or security issues.

Now, we are awaiting its release to the Maven repository to make it conveniently available for public use.

In the future, I will consider the possibility of supporting data types larger than Long and balancing performance.

Feel free to share any ideas or contributions you may have. Your input is welcome.

[4kimov]

Now, we are awaiting its release to the Maven repository to make it conveniently available for public use.

@lukechen116 Is there someone/something specific we are waiting on?

[lukechen116]

Now, we are awaiting its release to the Maven repository to make it conveniently available for public use.

@lukechen116 Is there someone/something specific we are waiting on?

The current version is waiting for @0x3333 to help me publish the Maven repository.

[4kimov]

@lukechen116 Ah, I see.

@0x3333 I sent you an invite to the repo, let me know if you need a re-send. Otherwise, if anybody else has expertise + time to spare, please ping here how we can move this forward.

[0x3333]

Hey everyone, I'm on it... ASAP will get back to you guys. Accepted the invitation.

[0x3333]

I pushed a commit regarding the maven publish infrastructure. Currently I'm waiting @jesperoman allow me to publish under org.sqids group on Sonatype repo.

I believe we should use version 0.1.0 instead of 1.0.0, what do you guys think? Also, I'll add some javadoc to the code.

[jesperoman]

Cool! I'll fix it as soon as I get the chance, probably tomorrow - CET😉

[lukechen116]

I believe we should use version 0.1.0 instead of 1.0.0, what do you guys think? Also, I'll add some javadoc to the code.

Thank you for your help in revising and adding Javadoc. Starting with version 0.1.0 is a great idea.

[lukechen116]

What are the next steps for us to have a release?

@4kimov Are there any plans in the future to make it larger than long or infinitely large?

@0x3333 @fanweixiao @gabrielcipriano When it comes to decoding, using List<Long> for faster insertion of values is a valid approach. Therefore, designing the methods asString encode(final List<Long> numbers) and List<Long> decode(final String id) is a reasonable choice.

Are the following options better than the original design? or keep it original design?

1. String encode(final Long[] numbers) and Long[] decode(final String id)
2. String encode(final long[] numbers) and long[] decode(final String id)

[gabrielcipriano]

Are the following options better than the original design? or keep it original design?

1. String encode(final Long[] numbers) and Long[] decode(final String id)
2. String encode(final long[] numbers) and long[] decode(final String id)

I didn't quite understand, I suppose lines 1 and 2 should be different?

[0x3333]

I didn't quite understand, I suppose lines 1 and 2 should be different?

One is a primitive, other is boxed.

[0x3333]

What are the next steps for us to have a release?

@4kimov Are there any plans in the future to make it larger than long or infinitely large?

@0x3333 @fanweixiao @gabrielcipriano When it comes to decoding, using List<Long> for faster insertion of values is a valid approach. Therefore, designing the methods asString encode(final List<Long> numbers) and List<Long> decode(final String id) is a reasonable choice.

Are the following options better than the original design? or keep it original design?

1. `String encode(final Long[] numbers)` and `Long[] decode(final String id)`

2. `String encode(final long[] numbers)` and `long[] decode(final String id)`

We had this problem before in hashids, some users wanted to use with longer numbers, but it did not got implemented.

Accepting lists and arrays is a good point, but I think we should accept iterable instead of lists, because the user can pass a set or other structure that implements iterable.

[4kimov]

Are there any plans in the future to make it larger than long or infinitely large?

@0x3333 The spec does not specify the integer type to use. The recommendation is to use the biggest available. Alternatively, if language is capable, support multiple integer types at once.

https://github.com/sqids/sqids-spec/blob/main/src/index.ts#L300

[lukechen116]

I didn't quite understand, I suppose lines 1 and 2 should be different?

1. Long (note the capital "L") is a class that belongs to the java.lang package and is used to represent 64-bit signed long integers. It is an object-oriented representation of the long data type. You can perform various operations on Long objects, such as converting strings to Long objects and comparing Long objects.

2. long (all lowercase) is a primitive data type in Java. It is used to store 64-bit signed integers directly, without the overhead of objects.

[0x3333]

Guys, after what @4kimov said, we should accept all number types, this helps users call Sqids directly, without type conversion.

I'll think about how the API should be implemented.

[lukechen116]

Guys, after what @4kimov said, we should accept all number types, this helps users call Sqids directly, without type conversion.

I'll think about how the API should be implemented.

@0x3333 I was originally considering whether to support other types when implementing BigInteger. I was planning to create a branch feat/more_type using generics as a reference. However, due to type checking and conversion, a lot of code was added, which would decrease the readability of the original algorithm. Is this in line with your thoughts?

[lukechen116]

Accepting lists and arrays is a good point, but I think we should accept iterable instead of lists, because the user can pass a set or other structure that implements iterable.

@0x3333 Using Iterable or Collection instead of List can indeed enhance compatibility with Collections, such as Set or Queue, reducing the need for conversions. However, if there are no duplicate elements in the Set, does it cause distortion in decoding?

[jesperoman]

I'd be happy to help adding a user to the org.sqids group on sonatype, but I have a hard time navigating that ui, does anyone know how to do this? 😅

[0x3333]

I'd be happy to help adding a user to the org.sqids group on sonatype, but I have a hard time navigating that ui, does anyone know how to do this? 😅

I believe that the easiest way is to do is to add a message in the original issue in the JYRA.

[0x3333]

Accepting lists and arrays is a good point, but I think we should accept iterable instead of lists, because the user can pass a set or other structure that implements iterable.

@0x3333 Using Iterable or Collection instead of List can indeed enhance compatibility with Collections, such as Set or Queue, reducing the need for conversions. However, if there are no duplicate elements in the Set, does it cause distortion in decoding?

Yep, that would be an issue. I need to think more about it...

[namero999]

What version are we expected to see on Maven?

https://mvnrepository.com/artifact/org.sqids/sqids

here there is an artifact, however it still seems the Scala-based version (which doesn't match with the documentation published here).

[0x3333]

What version are we expected to see on Maven?

https://mvnrepository.com/artifact/org.sqids/sqids

here there is an artifact, however it still seems the Scala-based version (which doesn't match with the documentation published here).

We will issue a Java version to maven, as soon as it is finalized.

[0x3333]

@0x3333 Using Iterable or Collection instead of List can indeed enhance compatibility with Collections, such as Set or Queue, reducing the need for conversions. However, if there are no duplicate elements in the Set, does it cause distortion in decoding?

We need to check, but the input/output must be canonical, if it's so, we need to keep using lists, not iterable or collection.

I'm in such a small amount of time to handle these issues, so I'll try my best to go forward with all this. IKYP.

[lukechen116]

We need to check, but the input/output must be canonical, if it's so, we need to keep using lists, not iterable or collection.

I'm in such a small amount of time to handle these issues, so I'll try my best to go forward with all this. IKYP.

@0x3333 Yes, the specifications for output and input, we may reach a consensus as soon as possible. I initially opted for using List for quick implementation.

If we not to use iterable or collection, we might consider using the Array methodm it might be closer to the input/output style of other languages, such as JavaScript.

String encode(final Long[] numbers)
Long[] decode(final String id)

[nathanheffington]

What version are we expected to see on Maven? https://mvnrepository.com/artifact/org.sqids/sqids here there is an artifact, however it still seems the Scala-based version (which doesn't match with the documentation published here).

We will issue a Java version to maven, as soon as it is finalized.

Do we have an estimated time frame on when it will be deployed to maven?

[nathanheffington]

Following up on this ^. Do we have a roadmap?

[pfeileon]

Now, we are awaiting its release to the Maven repository to make it conveniently available for public use.

@lukechen116 Is there someone/something specific we are waiting on?

The current version is waiting for @0x3333 to help me publish the Maven repository.

What version are we expected to see on Maven? https://mvnrepository.com/artifact/org.sqids/sqids here there is an artifact, however it still seems the Scala-based version (which doesn't match with the documentation published here).

We will issue a Java version to maven, as soon as it is finalized.

As soon as what is finalized, and are we talking about days, weeks or months?

[0x3333]

I'm waiting @jesperoman add me to Sonata repo to upload the artifact. As soon as I have access I can push a version.

I want to remark that I'd consider this version beta, because the API, in my view, is not ideal. But I have no time now to think about it, so we can push this version as pre-1.0 to not slow people down.

[4kimov]

we can push this version as pre-1.0

@0x3333 Just a heads up: almost all sqids implementations are pre-production right now; if it's the first push, I'd recommend going with 0.1.0 (we're testing not just the libraries, but the algorithm as well - which will take some time).

[0x3333]

@0x3333 Just a heads up: almost all sqids implementations are pre-production right now; if it's the first push, I'd recommend going with 0.1.0 (we're testing not just the libraries, but the algorithm as well - which will take some time).

yep, that's what is planned to do.

[pfeileon]

we can push this version as pre-1.0

@0x3333 Just a heads up: almost all sqids implementations are pre-production right now; if it's the first push, I'd recommend going with 0.1.0 (we're testing not just the libraries, but the algorithm as well - which will take some time).

Just to be sure, does that mean that the output might change between beta and stable release?

[0x3333]

Just to be sure, does that mean that the output might change between beta and stable release?

I don't believe, what probably will change is the API, to be honest, will be augmented, not reduced. Unless a bug is found.

[jesperoman]

I'm waiting @jesperoman add me to Sonata repo to upload the artifact. As soon as I have access I can push a version.

I want to remark that I'd consider this version beta, because the API, in my view, is not ideal. But I have no time now to think about it, so we can push this version as pre-1.0 to not slow people down.

This should be done now, terciofilho now should have write access to the repo!

[0x3333]

Thanks @jesperoman!

I just uploaded the snapshot version to the repo. After some time, it will show up in central.

https://s01.oss.sonatype.org/content/repositories/snapshots/org/sqids/sqids/0.1.0-SNAPSHOT/

[0x3333]

When you think it is OK, I'll upload a non-snapshot version, so it shows up in Maven Central, and is generally available.

[d3bt3ch]

When can we expect a production release on maven?

[0x3333]

When can we expect a production release on maven?

This week.

[pfeileon]

Thanks @jesperoman!

I just uploaded the snapshot version to the repo. After some time, it will show up in central.

https://s01.oss.sonatype.org/content/repositories/snapshots/org/sqids/sqids/0.1.0-SNAPSHOT/

There is still only the sqids-scala stuff on Maven Central.

[0x3333]

Looks like people are busy, I'll upload version 0.1.0 in the current state.

[0x3333]

Version 0.1.0 released. Up to 4 hours it should be in maven central.