This is related to a previous query. Section 1.5 of RFC 5536 mentions that submitted proto-articles may lack some of the mandatory headers that full articles have. Servers will always pass full articles to clients or peers, so they’ll fill in missing headers. But what are the optional headers?
Both RFC 5536 and 3977 mention filling in the Message-ID if needed, but not anything else. The examples in 3977 (section 6.3.1.3) imply only From, Newsgroups, and Subject are needed; servers can fill in Message-ID, Date, and Path. That makes sense; is that the actual list? Is there some official list somewhere, maybe in an obsolete RFC?
The precursors to RFC 5536 are:
https://www.rfc-editor.org/rfc/rfc1036
https://www.rfc-editor.org/rfc/rfc850
RFC 1036 is listed in RFC 5536 (RFC 5536 obsoletes RFC 1036).
RFC 1036 says:
The required header lines are "From", "Date", "Newsgroups", "Subject", "Message-ID", and "Path".
Update: see https://www.rfc-editor.org/rfc/rfc5537 (thanks CTMacUser) which says,
any of the following mandatory header fields MAY be omitted:
Message-ID, Date, and Path.
Related
in my application I'm post-processing couchdb documents by listening to the changes stream. The scenario is the following:
My application gets notified that a document got changed via /db/_changes
It fetches the document and checks if the document has an appropriate attachment and if the revpos of the attachments is equal to the first part of the document-rev. If for instance the rev looks like this 13-D2JDBS3 then I split the string at the - char, take the first match, convert it to a number and compare it to the revpos of the attachment.
If the above check fails, I generate a PDF and attach it to the document.
This works pretty good so far. But I'm wondering if this is intentional by couchdb's design. Is it safe to rely on this behaviour (that the revpos mirrors the first part of the revision that it belongs to)? I couldn't find anything about this in the docs.
Thanks in advance for any hint on this topic.
I think this intentional and seems to be public and documented API, though the wording could probably use some clarification.
In the Revisions documentation they say:
The revision number is the MD5 hash of the transport representation of a document with an N- prefix denoting the number of times a document got updated.
And in the Attachments documentation they say:
revpos (number): Revision number when attachment was added [emphasis theirs]
It's a bit unfortunate that they call the whole _rev identifier a "revision number" in the former documentation, since it seems clear that the intent within the latter is to highlight just the "N" prefix as the "number".
You might consider filing a documentation bug on this, asking them to clarify that revpos will always be the "N" part of the "N- prefix" if that's indeed something they are willing to guarantee.
When I pull media using either the user or tag endpoint, the received media not always contains all tags for a post. This seems (we are still in sandbox mode) to be the case when the tags are contained in comments BUT not always.
E.g: Requesting tag "arkiromantix" (https://api.instagram.com/v1/tags/arkiromantix?access_token=[access_token]).
Returned data contains among others post with id 1192868766714482828_38257867 which lists the requested tag under tags and post with id 1218885626018570787_210152727 which does not.
But with both posts the tag in question was added in a comment not in the caption.
My questions would be:
Is there a way to assure getting all tags (from caption and authors comments) when pulling media from the Instagram API? (For now I am requesting the comments for each media, which increases the amount of requests the app uses considerably). And if not:
Is there a rule by which Instagram decides when they return all tags (from caption and comments) and when not? (So i can at least reduce the amount of requests)
It seems that tags in comments count as tags on the gram itself if and only if the comment was written by the user that posted the image. This SO question deals with a related issue (i.e. retrieving recent grams with a given hashtag doesn't actually sort by post date of the gram if the hashtag is in a comment made by the gram's poster, but instead by post date of that comment, in that case). See in particular this comment.
I can confirm this (undocumented!) sorting quirk from personal experience from the past two days ... this sort of thing really makes work interesting.
I'm new to TPL (Smarty) but have been using PHP for years.
Is there a roadmap/guide for customising OJS?
As far as I understand this would involve a PHP script to retrieve/assign the information and then a TPL script to actually display the information.
Thanks
Petras
For references, have a look at the OJS Quick Reference and the OJS Technical Reference, both available here: https://pkp.sfu.ca/wiki/index.php?title=OJS_Documentation
By "Author's View Page", I'm assuming that you mean the pages with a URLs like http://.../index.php/[journalPath]/authors/view. Modifying these to include an author biography may be difficult because of the way OJS stores author records.
Each article may have several authors, and author records are not disambiguated -- for two articles with "Joe Smith" as an author, there will be two different entries in the authors table. Currently on the author listing the disambiguation is done by matching the same first name, last name, affiliation, and country. (See pages/search/SearchHandler.inc.php in the authors function for the code that does this.) Many author records may match this set of data, each potentially with its own biography data.
The reason the data is stored this way is to permit users' identities to evolve -- they may change last names, move between institutions, etc. -- without affecting the metadata of existing publications, which should not change.
If you want to determine a single biography statement, you'll need to decide how to pick a bio statement from among potentially many that match the set of data described above. Once you've done that, displaying it will be as simple as assigning the value to the template:
$templateMgr->assign('myVariableName', $somePhpVariable);
...and then using that variable in the templates/search/authorDetails.tpl template:
{$myVariableName|strip_usnafe_html}
FYI, our future plans include using third-party identifiers such as ORCiDs to disambiguate author identities; however, thus far our ORCiD integration is pretty limited. In the current release it's possible for users and authors to enter their ORCiDs so that they're stored with user and author records.
Specifically, we get these errors: "Validation error: The 'http://www.docusign.net/API/3.0:UserName' element is invalid ... The actual length is greater than the MaxLength value." But I have not been able to find any documentation about what the maximum length of this field is. I'd like to warn users of this value so they don't have to do trial and error to get it to work. Specs on all the field limitations would be useful. Or if the error message message said something along the line of "...is greater than the MaxLength value of 50."
The XSD provides this type of information, but I'm not sure whether or not DocuSign makes the XSD available for public consumption. I'll leave it to #Ergin (DocuSign) to comment on that, and to provide the link to the XSD if appropriate. Regarding specifically the UserName field, Max Length seems to be 100.
The API Documentation has info on field limits. You go the DocuSign API Documentation page, open either the Online SOAP API guide or the SOAP PDF guide, and do a search for CreateAndSendEnvelope. See page 40 of the PDF guide for instance.
The guide lists the schema of the call, and if you read the descriptions they state the maximum limits. For instance, it states the email subject is maximum 100 characters, email blurb is maximum 2000 characters, etc.
For envelope recipients you'll see a link that leads you to the Recipients schema (see page 53 of the PDF). On there, you can see that UserName is maximum 100 characters.
Like from Microsoft - "KB2756872" or from National Vulnerability
Database - "CVE-2010-1428" or from Red Hat - "RHSA-2010:0376" or
from OIDs - "1.3.6.1.4.1.311" or from UUID/GUID
- "550e8400-e29b-41d4-a716-446655440000".
I want to put several jobs to UIDs. See next...
I develop blog software and have idea to put unique ID in body of
each post so can easily identify that copy from local storage is
correspond to remote published copy.
Also I want to post to many different blogging services so if one
is down articles will be accessible from another. So link can
dead but if I add UID - anyone can try web-search to find post on
another service!
Also this allow to gather some article spreading
statistics. Many sites just replicate content (copy-writing and
rewriting bots and people) to broke search engines. With UID I
easily can identify such sites...
So my question how is to make UIDs (in which form) so it would be
easily indexed by search engines (web, like Google/Yahoo, and
corporate, like Lucene/Solr/Sphinx/Xapian/etc).
I know about some limitation of search engine like:
only >= 3 chars for each search part
it was not indexed dust like gfh6wytrh6wu56he5gahj763
so this task s not easy...
Any advice is appreciated (books/blog articles/etc).
You could use Tag URIs, as defined by RFC 4151.
They are globally unique, and everyone who owned a domain name or an email address for at least a day can mint them.
Note that these URIs only identify, they don’t locate. So a Tag URI doesn’t say anything about where something is published.
Let’s say your site’s domain is "example.com". If you create a blog post, you could create the following Tag URI:
tag:example.com,2012-12:cute-cat
Note that the date in this URI is not a publication date! It must be a (past) date on which you owned the domain (resp. email address). If you registered your domain in 2003, you could always use Tag URIs starting with tag:example.com,2004: (not "2003", because "2003" would mean "2003-01-01", which might be a time where you didn’t own the domain yet), followed by a (unique) string under your control. However, if you like you could always use the publication date, of course. But don’t use future dates.
You can use year and number based article identifier just like CVE identifiers. Since you need revisions as well, you can append dot after the identifier to clarify the version. For example, for an AWesome Blog Service, AWBS-2012-1.0 would refer to original document, AWBS-2012-1.1 would refer to first revision etc.
However, you need to make sure that AWBSs are unique before you use them. CVEs are assigned manually from the pool. You would probably need some kind of service that assigns AWBS from pool. It could be a simple database query.