fornever / jabber-net Goto Github PK

(Extracted from #11.)

• Main project sources are stored in the project root directory — for example, check AssemblyInfo.cs file location. Probably that's a good idea to follow .NET Core scheme — root directories src, tests, docs and per-project directories inside of that structure.
• Scripts directory need to just be renamed to scripts to follow the new scheme.
• #39: Fix namespaces
• #42: Migrate to Paket

That's important for #1.

I think it's time to mark develop branch as a groundwork of 3.0.

(Extracted from #11.)

netlib.Dns project claims some strange copyright. Probably we'll need to do something about it — either remove it completely from our sources or just assume it was imported rightly and have the same license as the project.

Currently the GoogleTalk documentation page is outdated. It needs to be updated.

Currently the "How do I add my own packet types?" page is outdated. Need to update it.

See #68.

We're currently using zlib.net library that doesn't seem to be compatible with .NET Core. Need to find replacement for it.

Currently we aren't checking paket.bootstrapper.exe hash on Travis: https://github.com/ForNeVeR/Jabber-Net/blob/379dc30f0bbda8180a57d628b56b6a6cfd117f6f/.travis.yml#L5

It should be fixed for improved security of the build server.

After my research in #11 I've found some files that are probably completely useless and may be easily removed:

• JabberNetInstaller directory contains some sources and binaries used in the installer. Personally I don't think we need installer at all, so probably drop that.
• Setup and vsi are probably somehow linked with JabberNetInstaller, so drop that.
• UpgradeLog.XML and _UpgradeReport_Files are old artifacts of project conversion and should be deleted.
• .cvsignore files are spread around the project tree. Delete them.
• ChangeLog is terribly outdated, so just delete it.
• fixup.py is some script to replace headers in the files. We're not going to use it ever (see #19). Delete it.

It seems that the tests are failing on Mono 4.6 after Travis update.

Currently there're some issues with the project organization:

• #12: Remove unused files from the repository
• #25: Delete .user files
• #14: Remove binary files from the repository
• #18: netlib.Dns license issues
• #28: CRLF conversion
• #30: stringprep.xml
• #32: *.resx files
• #23: Clarify the licensing
• #15: Build system changes
• #29: stringprep/ResTool
• #34: "either JOSL or the GPL" licensed files
• #35: Standartize AssemblyInfo
• #13: Restore the project documentation
• #16: Enable VB.Example project
• #17: Project reorganization
• #19: Class versioning issues
• #50: Add info to licenses section
• #51: xpnet license notice
• #48: stringprep

After all of these tasks are done, reevaluate the project state and check if anything else should be cleaned up.

After finishing #15 it's good idea to change the namespaces accordingly.

• review the documentation to reflect namespace changes

It seems that XmlElement-based API thoroughly used in jabber-net code is unsupported on .NET Core. We need to replace this API. Probably with XDocument?

Some files in the project are using SVNAttribute headers like this. There's even the whole (a little buggy) framework to parse the file headers included in the project (and I'm not sure whether they're linked or not), but we need to remove that stuff and just use semver already.

I want an example that'll work in PowerShell (something like Send-XmppMessage in line with Send-EmailMessage).

Bonus points for making it work under PowerShell Core (whatever it's called today). Probably make a separate task for that.

There's a bunch of files with the (terribly) wrong license header (licensed under "either JOSL or the GPL"):

• CertUtil.cs
• ConsoleClient/Makefile (managed by #15)
• SynchElementStream.cs
• Makefile (managed by #15)
• stringprep/AssemblyInfo.cs
• stringprep/Makefile (managed by #15)
• stringprep/ResTool/AssemblyInfo.cs (managed by #29)
• Main.cs (managed by #29)
• steps/ResourceLoader.cs
• unicode/ResourceLoader.cs
• test/Makefile (managed by #15)
• TestDecompose.cs

All of these files should be removed and destroyed and killed with fire ASAP no matter what. This is the top priority task.

• don't forget to update Licensing.md
• validate that there're no additional GPL-licensed files

stringprep/stringprep.xml looks like an auto-generated documentation file that can be removed from the project.

Currently we're using a binary copy of Rhino.Mocks library. Need to review whether it's supporting .NET Core and migrate to something compatible if it isn't.

There's some strange project in stringprep/ResTool directory. It doesn't seem like it's used today. Need to clarify its purpose and maybe delete it.

It doesn't seem like it was documented or used in the recent developments.

There's something wrong with the Travis build icon. Probably it was broken when I reset the project. Need to investigate and fix.

I want the whole project (or the most of it) to be built using dotnet tool. Some important thoughts:

1. I want the project to be editable using Visual Studio, so probably the sln file still need to be used. It'll reference csproj and xproj files (or maybe project.json directly?).
2. There's a couple of .NET Core-incompatible projects (Windows Forms controls and samples), I'm not sure whether they need or can be converted (UPD: it seems they can).
3. At the current state project won't support .NET Core itself (see #1 for the current state) but I think that dotnet could actually build FullCLR projects; need to check that.

@gsomix and sleepyvenom have shown interest in the task, although I'll obviously have to take a leading role in the implementation.

I've started initial work in the feature/61-dotnet-core branch. This task have a couple of dependencies:

• #62: Test fails on Mono 4.6
• #46: Revive examples
• #72: Remove Muzzle reference from the main test library
• Convert every project to dotnet (see #74, currently impossible for VB.NET)
• Rebase #63
• Check if the ConsoleClient works
• (new from 2016-12-05) try preview 3 and MSBuild stuff
• Port GUI projects back to MSBuild
• Check if the GUI client works
• Check if the VB.NET example works
• Fix both CI services
• Update the documentation accordingly

(Extracted from #11.)

The project have VB.Example not included in the main solution. We have no urgent need to drop it, so probably just integrate into the project tree and include into the solution.

• Fix AssemblyInfo.vb (see #35)

IdleTime class uses System.ComponentModel for something useful: it seems to be dependent on something called ISynchronizeInvoke InvokeControl. Probably we'll need to find a replacement for it for .NET Core.

The same about XmppStream.

XmppStream.resx and some files in jabber/server seem to be leftover artifacts of #6.

Prerequisites

• #2: Drop Component-based stuff
• #4: Remove Form support from CertificatePrompt
• #5: Drop System.ComponentModel.ISynchronizeInvoke
• #14: Remove binary files from the repository
• #15: Build system changes
• #17: Project reorganization
• #61: .NET Core-based build system
• #7: Use alternative mock library in tests
• #3: Migrate to .NET Core-compatible XML API
• #60: .NET Core-compatible zlib.net replacement

There're notices like that in xpnet code. Should fix the file name there (it's now licenses/xpnet_MIT.txt).

All the AssemblyInfo files should follow the single template.

There's UnixDnsResolver.cs file copyrighted by Eric Butler. Need to make sure it's properly mentioned in the licensing documentation.

stringprep directory have some Perl scripts and bat files inside of its unicode and steps subdirectories. We need to review this and maybe even drop completely.

Need to add CI to build the docs and deploy them to GitHub Pages.

Probably write a Jenkinsfile for that and trigger the process manually from time to time? Its task will be to collect the latest commit from the develop branch (if another optional commit message is not defined), and then commit and push the regenerated documentation into gh-pages branch.

Current versions of Nuget doesn't allow to use solution-level packages, although Paket does.

For now, I've installed some tool packages (such as FSharp.Formatting) into the main project although they aren't used at the project level. But I think that will mess up our Nuget dependencies, so it'd be better to migrate to the most technological option.

https://github.com/ForNeVeR/Jabber-Net/pull/66/files#r81274487

After some thoughts I've decided to refactor the solution file:

• Move all the projects (tests, sources, examples) to the root level
• Move all other items (docs, scripts, etc.) to the standard "Solution items" folder and preserve the directory structure there

After all, it's all about editing the code, not working with docs etc.

Review all TODO-style comments, NotImplementedExceptions, ignored and platform-excluded tests. Either solve the issues or file a new task for every case (or a case group, because there're many of them).

The story so far:

Our initial XMPP implementation was written a long time ago, probably when RFC 3920 wasn't replaced by RFC 6122 yet.

Long story short, RFC 3920 and RFC 6122 define some actions on JIDs in terms of "stringprep profiles" — a customizable specification of internationalized string comparison and stuff. Recent RFC 7590 don't use stringprep anymore, but directly defines the algorithms instead.

That means we'll probably have to review and remove stringprep stuff from our code (we have a whole load of that) and implement a new algorithm instead.

JabberNet.Muzzle is a set of Windows Forms controls for XMPP interaction.

Today not so many users are interested in Windows Forms. I haven't even published this library to NuGet. So I think that we'll need to deprecate this library in 3.0 (although it will be fully supported in 3.0 release) and completely remove it from 4.0.

https://github.com/moq/moq4

Possibly solution for #7.

(Extracted from #11).

I've identified some issues with the project build system. Need to check that, drop redundant stuff and make it more standard.

• Projects inside of the solution are named in a strange manner — 2005-ConsoleClient, 2005-Example. Need to drop that 2005 from there.
• build directory, Makefile, stringprep/Makefile, and mono-jabber-net.csproj are some outdated stuff to build project on Mono? We don't need those because we're already building the project as-is.
• There's a bunch of currently unused and unsupported csproj files, namely */2003-*.*proj, */*.old.*proj. Delete them.
• There're strange *.build, *.targets and *.key files in the project tree. Maybe delete them? Check if we're not using them somehow during the build. Probably we are.
• version — probably remove that and check if the project is versioned properly after that.
• some projects are building into bin5 and obj5 directories instead of common bin / obj. Fix that, and review .gitignore afterwards.
• assembly names should be the same as the project names

Author defines CertificatePrompt as an "Intentionally-ugly form". Because there's no Form support in .NET Core and there're no plans on making jabber-net a GUI library, so it's better do delete the Form-related stuff completely. Maybe even remove the whole CertificatePrompt depending on the role it plays in invalid certificate handling.

This class already supports a preprocessor constant named UI_OK (intended to be disabled on Mono) — probably it'll be ok to ensure UI_OK is never true.

Currently the tests are failing on Mono 4.6.0: https://travis-ci.org/ForNeVeR/Jabber-Net/builds/162551254

Probably these're real bugs and should be fixed somehow.

(Extracted from #11).

• Rhino.Mocks contains binaries of the corresponding library. Check if we can install them from NuGet, see also #7.
• lib20 directory contains some binaries probably better servable from NuGet. Replace and delete them.

(Spin-off from #12.)

There're multiple *.user files commited into the repository. Need to remove them; probably not too much problems.

From #27:

Unfortunately, I've found that my local repository clone had core.autocrlf set to false (and most of the files were commited to SVN with CRLF anyways, so we'd need to take care of that sooner or later). I've enabled this option now, so for some time it'll be harder for me to review my own pull requests, because there will be many line endings conversions.

We need to convert all the text files ASAP (e.g. from the current point in develop) because it's already starting to create problems in #27.

Convert each top-level directory in a separate commit to make review and testing easier (yes, I'm waiting for tests fails in middle of this).

Currently the root is "." in case of a local deployment (i.e. when JABBER_NET_ROOT environment variable wasn't defined).

That's not right for /reference/ directory. We should therefor replace root in a parameters argument of MetadataFormat.Generate call with ".." in case of a local deployment.

Muzzle is a set of Windows Forms controls for controlling Jabber-Net.

• Set up Muzzle publish to NuGet
• Set up publishing Muzzle documentation

It seems that Components were trying to play nicely with Windows Forms etc. They aren't needed today and they're missing from .NET Core. Need to remove all the Components and resx files from the project.

Currently our Windows Forms examples (both C# and VB.NET) doesn't work (or at least are in some invalid state). Need to fix them (maybe add an ability to override the default credentials, server etc.).

• JabberNet.ConsoleClient
• JabberNet.Example
• JabberNet.VbExample

• Create new Licensing.md file and link it from Readme
• Remove (or clarify) my additions from LICENSE.txt
• Seek any additional licenses (e.g. one used in ResTool, alternate authors for netlib.Dns, some Unicode stuff in stringprep, notice in xpnet) and enlist them in Licensing.md
• Accurately describe the whole picture in Licensing.md
• Update copyright notices in the relevant files (AssemblyInfo and jabber-net.nuspec)
• Explain the source updating policy in Licensing.md (e.g. that we aren't changing source headers and not introducing them in the new files)
• Update license tags (for the last time I hope)

(Extracted from #11).

Help and docs directories store some HTML sources and compiled chm files. We need to decompile these files and store the docs in some more friendly manner. Also we'll need to import the current documentation from the preserved online copy.

• Download a copy of the latest official online documentation and store into a repository
• Decompile jabber-net.chm file, extract the information from it, and delete the file
• Extract the information from the docs directory and delete the directory
• Extract the information from jabber-net-helpfilebuilder.shfb file (if any; probably there're namespace comments) and delete it
• Merge all the documentation and store it in some modern format such as Markdown (in that case we'll want to use Jekyll or FSharp.Formatting to prepare the user-accessible documentation)
• Decide if we want to store the API reference somewhere on site (it seems that everyone does that, even if I don't like it), and if so then how to do it (I've seen some great documentation examples made with F# and FSharp.Formatting)
• Add a reference documentation
• Actualize the documentation (after conversion it's still slightly outdated)
• Publish the documentation online (probably using a GitHub Pages)