As I see several dart packages published at dart package website, I am curious to know what packages does flutter endorse?
The question would be vague, so I would like to focus on a specific package dio. I have contacted few flutter developers, and have been told that the package is not yet a industry standard, also I was introduced to some packages that were published just hours back, for example jaguar_retrofit. I also see dart https package used frequently in flutter documentation.
This weighs me to look at what would be the most promising in the future.
Can someone solve the package mystery for me, any flutter insights available?
This is a valid question, but not one that you'll probably find a final answer to on stackoverflow (and it may be closed as off-topic although I won't cast that vote). You might find better luck at https://softwarerecs.stackexchange.com/ although there may not be too many dart/flutter specific people there; I don't know for sure.
But realistically, no-one knows what might happen to the packages in the future other than the people maintaining them. That would probably be a good first step - make contact with the developers as they will be able to give you a better indication of how committed to maintaining their code they are.
Other than that, what I'd look for is who the publisher of the package is (see below, under the "Author").
If it is the 'Dart Team' or 'Flutter Team', there's a fairly good chance it will be maintained. If it isn't, but the uploader has a '#google.com' email address, there's a chance it's just one of their 20% projects, but there's still a better chance of it being maintained than a random dev.
And finally, if the package's licence allows for it (which pretty much everything on pub should) you may be able to help the developer with it in the future, in which case everyone wins =).
It helps to look at the official documentation:
Fetch data from the internet
JSON and serialization
More in the cookbook.
Some time ago, I took a look at the dio source code and I'm not really convinced that it is a good option. Basically it is just a thin wrapper around the standard http library.
The retrofit clone seems to rely on a custom JSON serializer code generator, instead of using one of the standard solutions.
Related
Since homebrew is community-driven, what will happen if someone submits a malicious formula. Will this get merged into the main repository and end up being installed by everyone else? How can homebrew prevent this?
These things could conceivably happen. The general consensus out there seems to be that the likelihood is small enough to ignore. IT companies like Google, Amazon, and so on are perfectly OK with employees using it, so it is probably fine if you do too.
Google: 90% of our engineers use the software you wrote (Homebrew) [...]
--- Max Howell, initiator of Homebrew (https://twitter.com/mxcl/status/608682016205344768)
Review works
Getting a malicious formula merged is actually not that easy. The fact that you need a GitHub account and that building up a GitHub profile (to give yourself credibility) is a hard work (you have to program) can be a first line of defense.
There are actual humans looking at the formula during the Pull Request process. Nothing obvious should pass through, moreover, it is possible that just the fact of people being there and doing the checking dissuades many from even trying to propose something malicious.
Possible attacks
Has any repository hacking actually happened? Hard to say, because the following example could easily be just a honest mistake.
CVE-2008-0166
In 2008, an overactive Debian maintainer introduced a bug to OpenSSL, apparently in an effort to "clean up the code." (https://www.schneier.com/blog/archives/2008/05/random_number_b.html)
Lets now turn to other possible attack mechanisms
Typo-squatting
Attacker uploads a package that is similarly named to a popular one. People make typos and download the spoofed one.
This was successfully demonstrated for Pypi in N. P. Tschacher's bachelor thesis, see incolumitas.com/2016/06/08/typosquatting-package-managers/.
Any kind of manual review should catch it, so Homebrew is likely safe from it.
Reflections on Trusting Trust
(https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)
Famous essay by Ken Thompson which walks you through a procedure to insert a Trojan horse into a software stack (both the compiler and the application), so that it is present in both, but not easily detectable in either.
Dependency confusion
(https://www.schneier.com/blog/archives/2021/02/dependency-confusion-another-supply-chain-vulnerability.html)
Pick a company that is running an internal package repository. Publish a public package which has the same name as an internal company package. Then, the package installer may mistakenly prioritize the public name, and therefore employees of the company suddenly start installing your package.
I'm attempting to send a file to the eBays LMS.
I have downloaded heaps of examples but they all have something missing. Either they don't have all the references, or they don't tell me what packages to include.
Most often though they require something called a JobID, that I of course don't have because that's step one of the process.
So I'm wondering if anyone has seen or knows where to find a C# sample that contains all the bits.
It took quite a bit of digging but I came to this.
https://ebay.custhelp.com/app/answers/detail/a_id/1338/related/1
It has an app that appears to do everything. Though I've got a problem with it now, it is one of my making.
I am most happy.
I had a question with regards to software built on Ruby on Rails. I'm on the business end of an incubation team that has a few projects in the works, all built on Ruby on Rails. The goal from the investor was to sell the software out to third parties and have them use the platforms to their liking. From what I can tell though, there is no way to compile Ruby code and send it off to a third party, hiding the actual code from them.
We do not want our clients being able to copy our code and take it from us. Is there any actual solution to this problem, or are we screwed because they already decided to develop on Ruby? We wanted to be able to sell software as a service, but that's not going to work out if a client can sign up for a month, copy our code, and then build their own solution.
Thanks for any help in advance.
Ruby code obfuscators do exist, but that's of little real help IMO. But even if Ruby was compiled, chances are good it would get compiled into a format that is easily decompiled. Languages like C# and Java are both easily decompiled and thus source code is easy to get at these days.
Your real protection should probably come from a license. You may need to work with a lawyer or someone versed in software licenses. But if they violate your license, you have legal ground to take action.
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
The majority of components available for Delphi do not have HTML Help files for Delphi 2009. Many components including some very popular commercial components only have HLP and CHM help files.
Many of the third-party components are no longer being actively developed but are used by many developers. As a result there is no IDE help for these components.
There were very few complaints about the old CHM help files but today there are a large number of complaints about the help file system. Maybe it is time for Codegear to rethink the type of help file system used.
One of the complaints that I have about it is even when you install components that provide HTML help files the Contents Tab becomes corrupted where by previously installed component contents are removed.
Are there possible alternatives for Codegear to consider?
I have the same feeling. The old help system helps me more quickly to find an answer.
One idea is to maybe to model it after the Delphi Wiki at: http://delphi.wikia.com/wiki/Delphi_Wiki
The wiki actually isn't set up that bad, especially with the VCL link in the left frame.
It's fairly pleasant to look at, has a decent search, includes issues, examples, cross references, and what I like the most: user comments and tips.
Actually regarding the user comments and tips, the thing I like most about the PHP documentation at www.php.net/docs.php (which I think is the best programming documentation I've seen) is the user comments and tips.
If they can integrate the great layout that you'll find at Delphi Basics into it, and allow 3rd party components to add their help files into it, then they'll have a complete reference. (But the 3rd parties will obviously have to restructure their help files to the new format - whatever it ends up as).
The wiki also has sections for Tutorials, Tips and Tricks, References and Popular Articles. And I think it could also become the all-encompassing code-repository we all would like.
An option to download the help wiki should be allowed so it can be accessed offline.
And they'll have to figure out how to get the F1 key to work to properly search the wiki/help file, whether online or offline, and give the most relevant results.
The trouble with the Wiki now is that it is not complete, and the full set of Delphi help files need to be incorporated into it.
This might be a pipedream, but something like this would be my ideal.
This is a pet hate of mine. The Delphi Help has just got worse, although with a recent slight improvement. I honestly believe that this is one of the things holding back its adoption.
Micosoft introduced Help3 for VS2010, so maybe we will see it in Delphi too:
here is a blog post which answers the question "Why A New Help System?"
http://thirdblogfromthesun.com/2010/10/the-story-of-help-in-visual-studio-2010/
It quotes an internal paper, which led to the new "Help3" project in
early 2008:
"The paper described the following
issues with the help experience in
Visual Studio:
Not being able to find the information you need is a common
problem. F1 Help and Search do not
work as well as they should.
The performance of the help system – primarily start-up, topic-load,
local search results – is one of the
biggest problems.
The offline MSDN library install is fragile due to the complexities of
the help system.
The proprietary nature of our help format offers little incentive for
partners to develop authoring tools
and cannot be easily adopted by
developers in their own products.
On the content production side, the help platform saddles us with
outdated tools and processes.
Finally, and most importantly, no single team at Microsoft owns solving
these problems."