RSM is a good candidate indeed. I moved it.
I still didn’t make up my mind on the ‘rename packages’ thingy. Suggestions, anyone?
I had a quick chat with Matt yesterday. We’ll stick with org.xmpp as a package name.
Project Tinder is at a point where I feel comfortable to release it for the first time.
Does anyone want to comment on something before we release? Is there anything left to do?
Who can provide the usual project space in SBS and who can make some modifications to other IgniteRealtime.org pages (such as the download page, view source pages)?
Guus wrote:
Is there anything left to do?
Well, to make a party! Congrats about the good work and first release coming
Project Tinder is at a point where I feel comfortable to release it for the first time.
Cool, congratulations!
Does anyone want to comment on something before we release? Is there anything left to do?
Yes, I’ve tested the actual svn version 11068 and have some issues:
- In the MUC search I’ve got … test@conference.domain.lt… as an result and I think the field type should be jid-single. I think maybe in the DataForm#addItemFields(Map<String,Object> fields) method there should be a possibility to specify the field type.
- In my component I’ve to add a collection of FormFields to a DataForm (extended disco#info features) and don’t know howto do this now. Can you give me an advice or can you add a method like DataForm#addField(FormField)?
- At the DataForm and FormField class you use the String method isEmpty() which I think is not JDK15 compatible maybe we switch to JDK16?
Thanks for your work!
Good find! I had my workspace set up with the default Java 6 JRE. I adjusted my setup, and replaced the String#isEmpty() instances.
You wouldn’t be able to add FormFields the way you’re describing, as the FormField constructor is package protected. I’m not sure why this was done, but I left it as is for now. You can add FormFields to your DataForm using one of the two overloaded DataForm#addField() methods. Both methods return the FormField that was created. You can then modify that instance using the setters in FormField.
The DataForm and FormField implementations haven’t been modified a lot by me - we could do so in the future though. The problem that you identified with the addItemFields() method is a good example of something that could be improved.
Two things of notice, regarding your muc-search related comment: I’m not sure how the type=“text-single” attribute got added. It doesn’t appear to be added in the code. I’ll have to look a bit deeper into the code, but could you check your client (does this add that attribute itself, perhaps? After all, “text-single” is the default value for a type.
The second point: for results, the type of the result can (should?) be added to the “reported” field. That’ll prevent us from having to add this attribute to every item (which is quite redundant). The “reported” fields for those columns should be changed from “text-single” to “jid-single” (see OF-4).
You wouldn’t be able to add FormFields the way you’re describing, as the FormField constructor is package protected.
I used theorg.jivesoftware.openfire.formspackage before and then I switched toorg.xmpp.forms. Maybe this feature should be added toorg.xmpp.formssinceorg.jivesoftware.openfire.formsis now deprecated.
Could you check your client (does this add that attribute itself, perhaps? After all, “text-single” is the default value for a type.
Yes, it was curiously added by Psi in the XML console, in Pidgin I didn’t see it.
One other thing, I like the move from org.jivesoftware.openfire.resultsetmanager to org.xmpp.resultsetmanagement, but I think this could also breakbackwards compatiblity for Openfire plugins. Maybe add a copy to the origin place and mark it also as deprecated?
I can make all changes that don’t require me to create an icon or do graphics work.
Chris and I have just started working on the build server which will likely be where we build releases for the various projects. So, we could wait till that is building, or since this is a library and not big, per operating system, packages like Openfire, we could possibly move forward with a manually compiled build.
As you guys might have noticed, the first release of Tinder was done late last night (my time). A big thank you goes out to Benjamin - he put a lot of work in updating the website to include Tinder Tinder Dev!
Thanks for all the feedback on the initial project idea guys! Lets continue discussions on Tinder in the new Tinder Dev that was created for the project.