Thanks for the feedback - you're right, the TOS prohibition was overly restrictive, we've removed the deep-linking clause.
As far as attribute comparison, we are constantly trying to add more attribute data into our system, but we're still lacking in that department. We do have some data on sample rates for adcs though:
http://octopart.com/partbrowser#search/requestData&start...
(this link is to our new partbrowser interface - we've been working on designing a new interface specifically with engineers in mind)
If you have any other suggestions or ideas, definitely let us know.
Sorry, I mean for matching, and I did try to imply it was a limitation of the standard and not the library. Though to avoid confusion, I do personally think keeping the user agent minimal is wise, since users might have difficulty guessing what value to use if it differs sufficiently from the real user agent that's sent.
Thank you for your feedback. How would you suggest that I should have responded to this issue instead? I agree that my response was authoritative, but I believe that is what was asked (the issue is seeking an authoritative “official” answer). And from the perspective of not wanting to break this person’s code (or anyone who stumbles upon similar advice), the authoritative “official” answer is an unequivocal no, “this is not supported”, as the name of the property states. Though, like I mentioned, we can’t really tell anyone what to do in their own code, so at best we can say what’s supported and what’s not.
The FPS spec as described looks entirely duplicable by others and openly reimplementable by just cloning the FPS repo and following the same spec (which is open). Someone could choose in their browser to use a different set or a different repo or some hierarchical structure.
Because domain owners use /.well-known/first-party-sets.json, others can also scan for that themselves and perhaps build an independent repo from spidering.
The original statement was about coverage of the breadth of the specification: if you're consuming data you need to accept everything the specification allow, but if you're generating data you should be producing as little of the specification's productions as you can.
This does not work when the format is mostly unspecified and the vast majority of what you'll find in the wild is a tire fire.
Interesting - I didn't knew that one. It seems very security related - I'm not sure if issues for not supporting a specific part in a spec or for improving documentation for a feature will fit in.
But the requirements were to allow filters to be configured on users and groups, which would require more info in your data structures. This doesn't meet the specified requirements.
Plus even with it not meeting the requirements, it
is confusingly presented, and is filled with terminology related to the implementation rather than the domain. Where's a group definition? How would you configure a filter for a group? Or a user for that matter. (Answer: you would require a much more complex data model, and functions to access and modify it).
I'll stick to OO for the top level paradigm I use until something better comes along.
OO being dead is fake news perpetuated by ignorant know-it-alls.
I think you're being unfair. There's nothing bug ridden or inconsistent here, just a simple categorization system that looks like it would be pretty decent for small to medium sized projects.
It's also not informally specified. The shared link is literally the specification document. It's written in a kinds of informal style, sure, but that's a different kind of informal - Greenspun's informal means "not written down at all".
Specifications can change over time. It sounds to me as though the developer who made the change to the system that invalidated the invariant of the original specification wasn't aware of the spec in the first place. Maybe they should have worked on the specification first before proceeding.
Well, I'm curious about your conceptual design for this, because to me, the whole No Formats post directly contradicts your seventh rule. We can make the network transparent, but we cannot ignore the authority boundary between our two nodes. If I am to control the code running on my node, then I can't be expected to pull in common library code from your service to view your published data.
For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!))
Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not.
This is what I interpret your post as saying:
MyEnv -3-> YourCode -4-> YourImageLib
In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced.
What's wrong with it is that every spec will always be open to interpretation. You will interpret it as the minimum amount of functionality; the client will interpret it as the maximum. The only spec that isn't open to interpretation is the code itself. :)
(this link is to our new partbrowser interface - we've been working on designing a new interface specifically with engineers in mind)
If you have any other suggestions or ideas, definitely let us know.
reply