Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm building a calendar server in .Net. I want the first version of the system to be functional and interoperable for any calendar client. The system is for my college and is my thesis, that's why I don't have enough time to implement all the protocols that these system should implement.
What protocols are REQUIRED in a calendar system server in order to be functional for the clients? Till now it implements RFC 5545 (iCalendar), I'm finishing the RFC 4791 (CalDAV) and some of the extension of WebDAV, after this I'm going to implement the RFC 3744 (ACL).
Should I implement the RFC 6638 (Scheduling Extensions to CalDAV), RFC 3253 (Versioning Extensions to WebDAV) or any other?
In the future I want to implement all these protocols but I have no time now.
Despite the "close votes", I think this is a valid question. There's a lot of standards out there, and a lot of dependencies. And you certainly don't need everything.
The truth is that you need only a subset, and almost no one implements the entire spec.
What's required for you depends on which clients and which features you want to support. So lets say that you want to support iCal, and Thunderbird.
Then at the very least you need large chunks of CalDAV (RFC4791). You don't need every REPORT, but at least calendar-multiget and calendar-query. The freebusy stuff is not used. But for the calendar-query report, there's a small subset of actual queries that clients do.
You need big parts of RFC3744. You can skip most of the REPORTs, but you need a principals system and access-control related WebDAV properties. You also don't need the ACL method. WebDAV ACL is primarily used for principals and reporting access information (but not altering it).
Nobody uses RFC3253 (versioning).
You probably need current-user-principal-URL (rfc5397).
You don't need scheduling (RFC6638). Without scheduling, clients will sync just fine.
Lastly, it's really useful to have support for WebDAV Sync (rfc6578). Clients should be able to live without it, but in reality they tend to misbehave. Without support for that spec, you can fall back on the proprietary ctag, which is widely supported. It's simpler, does the job, but is non-standard.
I would consider this answer a non-exhaustive list though. It's an overview to help you get started. If you have more specific questions about the specs I mentioned, comment here, I'm happy to further expand on this answer.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I understand that "lines of code" may be not a fully accurate measurement standard because a lot of Salesforce configuration might be done through a gui. Nevertheless, for the sake of argument, let's say that either each config field manually filled out in the gui is like a line of code, or else let's imagine the configuration being done entirely in source code, if Force platforms allows it.
Well, so, how big would a typical "professional" or "enterprise" level Salesforce installation code base be? Is it like 1K lines? 10K lines? Are there many 100K and more cases out there?
You will hardly get a meaningful answer. Just as an example, one of my clients is an ISP, we've been at their enterprise instance for 5 years now and we have a code base of about 600KB (+testing code to satisfy 75% requirement) with more than 100 classes and even more pages, about 20 custom tabs, 30 custom objects and appx 150 custom fields on factory objects, all that complemented by a ton of work done on administrative customization. In contrast, their sister company operating the same business in another territory has its own instance without a single line of code, but they use it just for opportunity tracking and do their provisioning, operations, case mgmt and other stuff from different (legacy) systems.
The overall average statistics is something that salesforce only knows and they don't seem to be sharing that info. Either way you should get a trial of whatever instance you want and see what is missing in terms of your business requirements and plan accordingly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are the advantages and disadvantages of using libcurl and libsoup?
Which one is better to use for a HTTP operation where I have to send request to a server to get a response, and has a quick reaction time?
Libsoup is coming along, but libcurl has much better support and stability. Lib soup devs readily admit that you should probably be using libcurl.
The 4th item is especially important because even on Linux KDE and XCF users will install gnome-related libs, but it isn't nice to force them to use the gnome libraries when a platform independent option is available.
libcurl is (far) more portable
libsoup lacks support for: NTLM for proxies (Proxy-Authentication:), GSS, trailers in chunked responses, OpenSSL
libsoup offers server-side support
libsoup is using GNOME-related libs, making it a less convenient choice for non-GNOME environments.
"I found that libsoup is far slower than libcurl. It uses at least 4x the amount of CPU to transfer a high-bitrate datastream over HTTP. I attribute this to the over-reliance on heavy-weight glib/gobject constructs. Man, that stuff is slow and a pain to use!" - Matt Gruenke
I was looking at libsoup to implement the server side of an API on a hobby project (I was making my own router).
By the time I got through satisfying the GNOME dependencies, the simplicity of the callback based server side code didn't seem as attractive as it once did. The interface is nice enough, see soup_server_add_handler().
If you write GNOME applications (thus can already count on the GNOME dependencies being there), it's okay (it felt sluggish, to me).
If you are just writing client code, or anything that has to work in the absence of GNOME, stick to curl.
http://curl.haxx.se/libcurl/libsoup.html
Your probably better off sticking with libcurl if you want portability and stability.
Using libsoup caused an increase of almost 11MB in my rootfs, where libcurl only added around 1MB.
This is important in embedded systems with limited storage resources.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Are there any standard or "best practice" ways of limiting feature functionality for a particular application?
Example: We have a product with a variety of features, and our customers can pick and choose which features they would like to use, and the cost of the product varies based on which features they are actually using.
In the past, we have distributed along with our software installer an encrypted license file that contains information about the customer, as well as the collection of features that they have enabled. In code, we read from the license file and enable the functionality according to the license file.
This seems to work fine, except there a few disadvantages:
Upgrading users with new functionality can be sort of a pain
If a particular feature shows up in multiple places throughout the application, a developer might not realize that this feature should be licensed, and forget to check the license file before granting functionality to the user
If the license file becomes corrupted, deleted, moved, renamed, etc. the application will not run
We're getting ready to roll out a new set of features, and I was just curious what others in the community have done to tackle this problem?
Why not break down the product into modules like Matlab? Then charge for each module. The licensing can be kept online and the end user just needs to download the module to enable the feature.
There are usually 3 common approaches to this:
using fixed program versions (each version just adds features, you can't customize which features you want or not). You can use also "subversion", like basic and pro edition for Software x.0. Windows uses this approach.
Having modules of functionality, which are a product as themselves. Matlab uses this approach.
Having a software with basic functionality, and then having plugins, or extra apps for sale. Eclipse uses this approach (though it's free)
You can mix those approaches also for a better customizability.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm working with a developer who has placed his faith in a license scheme that makes little sense to me. He wants to tie a desktop application to a hardware component value, one of which is easily changed, the MAC address of the ethernet controller.
Now, I know no one likes licenses, he does want to protect his hard work and I can understand that. What can I tell him to help him out? In the very least I'd like to give him a path other than tying a license to a hardware component.
I am sure this will not convince anyone who doesn't already share my view, but I don't see any value in licensing schemes that are more complicated than a short serial number, perhaps "phoning home" so you can detect if it is being abused and disable it. If the software is moderately popular, it will be cracked, whether you invest $5 or $5 million into the licensing scheme. Put those millions toward building a product that honest people (the majority) are willing to pay for and upgrade. If more protection is needed, hopefully the application can be converted to a web service.
In one of the podcasts, Joel said something like this (I'm paraphrasing):
Just make your licensing scheme hard
enough to crack so that it's a little
easier to pick up the check from
accounting and just order another
license. That keeps those people
honest that are worth thinking about.
The rest of them are not going to give
a penny to you anyway.
Good point, I guess.
If he wants to be sure that only the licensed computer can use the software, a hardware key is one of the only options to be sure that the hardware(computer) is the same as the one the license was purchased for.
It can be easily cracked(so can anything), but it's not so easy to use two computers with the same mac address on the same network segment.
I don't see how a UUID will make a license more secure, or help to accomplish the goal of restricting one license per computer.
With licenses it depends on what the goal of the license is, having a unique license per computer may be a valid decision(although I personally don't like it), but it has to be remembered that licenses will only keep honest people honest in the end, and if someone decides to, they will crack your license scheme.
It all depends on how many users he expects and the price of his application, but in any case a mac address can be easily changed and will certainly only annoy valid users. In my opinion a standard serial will just do fine. If something shows up in P2P networks, just talk to the user to whom you issued the serial and ban it in the next release. To make a long story short, in the eye of a fraudulent user the only difference will be, if he downloads "CoolApp.v1.11.Incl.Keymaker-GroupName" or "CoolApp.v1.11.Incl.Keygen.and.Patch-GroupName".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
This is mostly a theoritical question, but I'm wondering what the proper way would be to accomplish the following.
Assume I have a few utilities, functions, and reference implementations that I use when building a web site for a client. Some of "my" reference code is re-used as-is, some is slightly modified. Also, as part of the agreement with the client, I agree to turn over all code and IP rights.
(I know the best answer is probably "talk to a lawyer" but really, how many lawyers are going to be versed in software licencing? I imagine I'd get better, more accurate here than picking a lawyer out of the phone book).
What sort of copyright notification and/or licencing should I include in the code I turn over to the client, if I want to be able to re-use "my" code on other projects?
Check out NOLO's "Legal Guide to Web & Software Development." It covers various contracts, license agreements, and IP ownership agreements related to software development. I have used the sample contracts as a template for a few of my agreements which are later reviewed by my attorney.
At the very least this book can help you understand what the terms, like transfer of IP ownership, really mean for you the developer.
If you turn over the "IP rights", doesn't that imply you are transferring ownership of the code? Which would mean that you can't re-use it without their permission or license, since you no longer own it?
You might want to look into revising your agreements with your clients, so that you can retain ownership and rights to your own work...