nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Where are Extended Attributes stored?

System

Question:

Where are extended attributes stored? They're apparently not stored in the XML so I wonder what file or files contain this information that is recalled with iwextattr, for example.

Thanks,

Dave

dave@simpleinternet.com
+USA (215) 962-5153

Find more posts tagged with

Comments

iwovGraduate

In the backing store. I think the only way to mainpulate extended attributes is via CLTs or UI.

Migrateduser

The extended attributes are stored directly in the backing store. Manipulation of Extended Attributes can be done using the existing cgi's built into TeamSite, TeamSite Templating and MetaTagger. Other options would be TeamSite and TeamSite templating CLT's (iwextattr, iwgen) or openapi.

Migrateduser

Thanks but what IS the backing store exactly? Is it binary information and therefore not really retrievable through means other than iw commands and/or GUI? Thanks again,

Dave

dave@simpleinternet.com
+USA (215) 962-5153

iwovGraduate

Exactly. Its Interwoven proprietary format.
What are you trying to do that you need the extended attributes in a flat file ?

Migrateduser

Thanks for the info... no, I was just curious about the internals of TeamSite. If I were to initiate a "COPY TO AREA", it will copy all of the Extended Attributes, permissions, etc., right? Just want to make certain. Thanks,

Dave

dave@simpleinternet.com
+USA (215) 962-5153

iwovGraduate

Yes, "Copy to Area" will copy the extended attributes. Not sure about the permissions.

Migrateduser

copy to area uses the same API that the iwupdate command line tool uses. There is also an OpenAPI equivalent.

using Copy to Area allows you to copy the file history and associated metadata. the permissions set on the files themselves are also copied (you would need to adjust these with submit.cfg in the new area if you needed something different).

Migrateduser

Interwoven uses an obejct-store to persist content. Each leaf contains a reference to content and metadata (much like apple has a resource and data fork). Out-of-the-box, Interwoven stores content in the file system and extended attributes in the backing store, a binary file created on the file system.

Some interesting points:

- The binary backing store permits the fastest performance for projecting workarea, branches, authentication and so forth; loading; and failsafe/recovery operations. The binary performance is often labeled as proprietary; it can also be configured so that content and extended attributes can be configured to be stored in a relational database. By nature, content can be an XML file and extended attributes can be written to an XML file. As an example, portal integrations push both content and an XML Manifest (for pickup by search engine and portal servers).

- Extended attributes are name/value pairs. Metatagger is configured by default so that its fields are represented in XML.

- The base extended attributes are dublin core compliant. The system also can export ICE and PRISM.

----
Mark A. Hale, PhD, PE
Director of Content Technologies, Interwoven
mark.hale@interwoven.com

Migrateduser

That is a very interesting about storing the extended attributes in a relational database.

What kind of performance hit would TeamSite take configured as such … because its binary in nature (and that’s the reason for the performance of the database in the first place ) will the overall performance be degraded? Is there any more info on this and has anyone else configured TeamSite as such?

Grundy

Does iwperl come with any library functions which allow manipulation of ea's without having to call the iwextattr CLT?

The question arises because I'm working on a script which applies attributes to large numbers of files, and the repeated calls to iwextattr create errors on our Windows NT server. What I need could be probably be accomplished through OpenAPI, but I'm not very familiar with that yet. Any suggestions?

james1

We do not currently have any Perl modules that set/get TeamSite Extended Attributes, to my knowledge. Even if we do, I'm pretty sure that they do not bypass the iwextattr CLT.

If you are concerned about the performance of spawning the iwextattr CLT repeatly, then OpenAPI or Content Services is going to be your best bet.

-- James

Adam Stoller

Unfortunately, at this point in time - openAPI (Java) would be the only programmatic interface for doing this.

There is already a feature request in for being able to handle multiple key/value pairs for a single file per single execution of iwextattr - I will add another feature request for being able to process multiple files as well (probably need some file format directive for doing this correctly ... I'll try to think up something as I file the request)

--fish
(Interwoven, Curriculum Development)

Grundy

Does anyone have example code for manipulating extended attributes with OpenAPI?

james1

See this related DevNet thread.

-- James

james1

PS - EA manipulation is far simpler in Content Services than in OpenAPI. One method call to start a session, and then one method call (per file) to set (or to get) an unlimited number of EA's. (And then one method to end the session.) In general, Content Services is an easier-to-use API. It's just not as feature-rich as OpenAPI, for now.

james1

Here's a crazy idea: You could write a workflow that consists of a usertask, followed by an endtask. The usertask could have an eafinishop, which can set, append, and delete extended attributes. This would help you set EA's in a large batch without having to execute iwextattr repeatedly. Since the workflow engine resides inside of iwserver, this might be an efficient way of setting a large number of EA's at one time. Unfortunately, I believe that you would have to set the *same* set of EA's on all files, which may not suit your situation.

-- James

Adam Stoller

You could probably substitue the usertask for an externaltask as long as you select the files to tag before invoking the workflow - and thus further automate the process...

--fish
(Interwoven, Curriculum Development)