Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

Portal v3 - Markups and Annotations on your assets

Posted by Brian Dolan on Wed, Oct 07, 2009 @ 07:51 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

Now that version 3 of Portal is out, the markup and annotations feature is available to those that upgrade.  Now, that doesn't mean go out and install it immediately people!  Always make sure to contact NAPC first before any upgrades and ya know what, we're here to install it for you any way!  So, back to my point.

Portal 3, annotations & markups, yeah that's right!.  It's a very cool feature that deserves it's own min-blog.

Let's make this easy . . . the notes below come directly from Xinet's release notes of Portal v3:

"WebNative Portal 3.0, in conjunction with WebNative 16.0, allows on-line annotations of all images, documents, and videos. A palette allows users to add text, boxes, stamps, or sketches, and all of the annotations can be done in black or a range of colors. When adding annotations, the preview can be magnified for closer inspection. Individual annotations may be saved (with or without comments), deleted, or temporarily hidden from view. The annotations are stored in the Venture database, so any other WebNative user may access saved annotations via mview in Portal but the annotations are not saved to the file on the file system."

If you'd like to see a demo of this, please contact your Account Manager so we can arrange a quick demo.  Just another reason to get Portal or upgrade to the latest version!

0 Comments Click here to read/write comments

Who's On My Portal Server?

Posted by Sean Kenny on Thu, Oct 01, 2009 @ 12:37 PM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

 

Sometimes it would be nice to know who is actively logged into your Xinet Portal Server. Unfortunately there is not a current tool offered to retrieve this information...until now!

Using a simple php script it's actually possible to scrape the current php sessions that have been created and obtain a list of users that have active php sessions in Portal.

A little background on this....

On Portal servers php stores it session data inside of th session directory /tmp, this is specified by the session.save_path ini variable. All session files start with the prefix "sess_". Inside of a session file you will find a plethora of serialized text data, that php is managing with its session functions. Although this serialized information is highly unreadable, is is still possible to pick some key data out of it, without needing to go through a deserialization process.

So basically for each user logged in via Portal, a corresponding session file will be created inside of the /tmp directory. Contained within this file will be useful information including the username. So at this point all we need to to is create a php script that will read all the php session files located on the server and displays the count of usernames that it finds!

php code that does this looks like the following:

<?php

//create an empty array to house our users in
$users = array();


//loop through all of the sesssion files found in the php session temporary directory
foreach(glob('/tmp/sess_*') as $session_file){

    //get the contents of the sessions as a string
    $session_data = file_get_contents($session_file);
    
    //with a regex mine out the username contained within the session data
    preg_match('/USERNAME.*?"(.*?)";/', $session_data, $matches);

   //get the matched pattern out of the first grouping of the pattern
    $session_user = $matches[1];

   //if the found value is not empty then create the key for the array and/or increment the user count (users can be logged in multiple times)
    if ($session_user) $users[$session_user]++;
  }

//now that we have done the heavy lifting proceed to display the result with a simple foreach iteration over the users array that we have populated...

?>

<H1>Active Portal User Sessions</H1>

<UL>

<?php foreach($users as $username=>$count): ?>
<LI><?= $username ?>(<?= $count ?>)</LI>
<?php endforeach; ?>

</UL>

If You install this php code on your Portal Server you would get the following output.


 

This successfully displays all users currently logged into the Portal server.

As you can see, inspecting php sessions is a very useful technique for finding Xinet Portal user information, and using this technique it is possible to provide enhanced user tracking functionality.

1 Comments Click here to read/write comments

Portal 3.0 Data Interchange

Posted by Jason Palmer on Thu, Aug 20, 2009 @ 02:17 PM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

Portal 3.0 Data Interchange

 

Xinet is close to releasing the third iteration of their popular platform, Portal, and with this release comes every developers dream – an API.

 

Portal DI (Data Interchange), makes available all the core functions of Portal such as:

·      Listing files/folders within a directory/volume

·      Listing volumes

·      Read and Update metadata attributes for files

·      File manager operations such as upload, download, move, copy, etc.

·      Search

 

Xinet Portal 3.0 itself uses Portal DI to gather all the information it needs to build the site interface!

 

How does it work?

 

Portal DI is a REST-based API that serves JSON formatted data.  What this means is that you communicate with it using standard HTTP (GET or POST), and JSON formatted data is interpretable by nearly every language known to man at this point!  The simplicity of a REST-based API, coupled with the accurate & widely accepted JSON formatting makes this API truly a breeze to work with.

 

What can it do for me?

 

Portal DI essentially makes your DAM information modular.  Data about your assets can be accessed from anywhere and that data can be used in a variety of different ways.  As a developer who has been working with Portal for two years, I can’t explain how much easier integration with third-party platforms will be with Portal DI.

 

Can you show me an example?

Below is a very simple example of how to retrieve a list of volumes for a particular user (in this case 'demo').

 

Portal DI Example

 

As you can see, Portal DI is both simple and powerful.

2 Comments Click here to read/write comments

New Video featues in Xinet v16

Posted by Brian Dolan on Fri, Jul 03, 2009 @ 07:29 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

As the Holiday weekend starts up for us all, lets close the week out and chat a bit about all the cool things that are coming to the masses soon.  Xinet is going to be releasing version 16 of it’s suite of tools including a new, faster version of Portal, a unified web interface for all administration, easier tools and setup for PDF Image replacement, greatly enhanced video capabilities, basic web based markup and annotation tools and a whole bunch of other “under the hood” improvements.  Currently, NAPC is testing beta 2 of version 16 and we’re all pretty impressed with it so far.  One of the biggest features I’m excited about is the enhanced video features.  Let me esplain (as Ricky would say).


Xinet, in the new soon to be released version of video in Suite 16, has greatly enhanced how users in Portal interact with video assets.  In the current release of Video 2.0 in Xinet, it is possible to stream many video formats, create keyframes at a preset interval, and really, thats about it.  With the new version, you’ll be able to do much, much more.  First and foremost, the ability to create what I would call mini-reels, is now available as a basket plugin in Portal.  This is how it works:


1)    User logs in to a Portal site and identifies the files they want to work with.  Those files could be video files of various formats, InDesign files, static picture files, just about anything you can have in Xinet.
2)    The user would then add those files to a shopping basket.
3)    Once in the basket, the user would click the basket plugin named “Video Generation”
4)    This brings up a new Web 2.0 type of interface to arrange the assets into whatever order makes sense to the end user.  Asset arrangement is made simple by using drag and drop in a web browser-me likey!
5)    Once in the correct order, the user can set the ‘in and out’ times of the files based on keyframes generated by Xinet or by hours:minutes:seconds.
6)    The user can also set basic fade outs from clip to clip as well.  Gives it a nice touch!
7)    Once the files are arranged in the correct order and the in/out times are set, a new video file can be generated from those assets in either a Quicktime, Windows Media, or Flash format.
8)    The server then generates the appropriate file on the Xinet file system and once done, it gives the end user the ability to download the file to their desktop.

Here's a peek of what it'll look like:

 

This is huge everyone.  Think of it this way, if you have 30 second spots for a client for all of 2008, and they want to create a quick reel of all the ones that won awards (that you made of course!), they can quickly log in to Xinet via Portal, collect the assets, set the times and format and let Xinet make the file for them.  To be clear, this is not intended for broadcast but more for the web or computer screen aka small screen.  I think this is a huge leap forward for Xinet and since I used to work in the broadcast world, it’s pretty exciting for me as you might be able to tell!

On top of that, screen detection for keyframing is also part of the new release.  The current version can be set to sample a keyframe at a set interval say every 5 seconds or so regardless of scene change or not.  That can potentially add a bunch of useless keyframes into your database.  With the new scene detection functionality, you can set the admin preferences so it is “smart” and only creates keyframes when a scene actually changes with tolerance controls.  So, instead of keyframing a movie that is 1 minute long and getting 12 keyframes (when sampled every 5 seconds), you may only get 7 or 8 frames stored in the database. This can be very helpful!

Overall, we have a lot to look forward to with the upcoming release of version 16 of Xinet’s Suite of tools.

Enjoy the weekend all and as always, if you have any questions on any of this information, please give us a ring and we’ll be happy to help!  Want to see this new functionality for yourself???  Give your Account Manager a call and we’ll be happy to show you all the new stuff.

Happy 4th of July!

Brian Dolan

0 Comments Click here to read/write comments

Exploring Portal Template Variable Arrays

Posted by Sean Kenny on Mon, Jun 29, 2009 @ 10:44 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

Portal has a variety of template variable arrays that contain the data used by the HTML template pages for display. When making custom Portal sites it becomes a common need to investigate the data found in these arrays via a PHP print_r statement like the following.

<?php
print "<pre>";
#print_r($_SERVER);
#print_r($_SESSION);
#print_r($volume_info);
#print_r($dir_info);
#print_r($file_info);
#print_r($files_info);
#print_r($keywords_info);
#print_r($tmpl->variables['PORTALPAGE']);
#print_r($links_info);
#print_r($spreads_info);
print "</pre>";
?>

Through using this approach it becomes possible to display Portal’s template variables arrays directly in a web browser, which can be convenient for inspection and debugging. This article expands on alternatives and twists to this standard approach.

Alternative variable display functions

When exploring a variable's contents in PHP var_dump() and var_export() are common alternatives to the print_r() function. Each performs a similar task with a slightly different behavior. var_dump() prints slightly more informative (but less readable) information about the given variable’s data, while var_export() prints interpretable PHP code. The following table illustrates the output differences for these functions.

print_r() var_dump() var_export()
Array
(
[0] => Apples
[1] => Oranges
[2] => Pears
)
array(3) {
[0]=>
string(6) "Apples"
[1]=>
string(7) "Oranges"
[2]=>
string(5) "Pears"
}
array (
0 => 'Apples',
1 => 'Oranges',
2 => 'Pears',
)

Depending on your needs, these standard functions give a good set of options for displaying Portal template variable data for inspection and debugging.

Storing Portal variable information in a variable and/or file

Sometimes it is not always ideal to send Portal’s template variable data to the web browser for inspection and debugging. To help alleviate this issue the print_r() and var_export() functions both accept a second Boolean parameter that, when set as true, causes both of these functions to return a variable’s data from the function call instead of printing it. This allows for capturing a variable’s data in another variable and/or file for later inspection and debugging. The following snippet is an example of such an approach.

<?php
$portal_page = print_r($tmpl->variables['PORTALPAGE'], true);
file_put_contents('/some/directory/var_data.log', $portal_page);
?>

The print_r() function is called with a second parameter set to true. This cause the print_r() function to return the $tmpl->variables['PORTALPAGE’] variable information to the $portal_page variable instead of printing it. The contents of the $portal_page variable are then written to an external log file. This data could then be viewed, searched, and stored at another point in time.

Storing variable information as XML

Using PHP it is also possible to store the portal variable information in your own XML format. This XML data could then be transmitted and interpreted by any type of program geared to help inspection and debugging of Portal’s template variable arrays. The following code example could be placed inside of any one of your site’s local.inc.php files. This code snippet checks known Portal template variables arrays, and inserts their data into a hierarchical XML data structure. This file is then saved as XML on the server in the same directory as the file being executed.

<?php

$var_trees = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>";

//start the xml var trees hierarchical data structure
$var_trees .= "<var_trees>";

//check the known portal variables. If they exist generate an xml tree of the data
if ($volume_info != NULL) $var_trees .= var_tree('$volume_info', $volume_info);
if ($file_info != NULL) $var_trees .= var_tree('$file_info', $file_info);
if ($files_info != NULL) $var_trees .= var_tree('$files_info', $files_info);
if ($keywords_info != NULL) $var_trees .= var_tree('$keywords_info', $keywords_info);
if ($tmpl->variables['PORTALPAGE'] != NULL) $var_trees .=
var_tree('$tmpl->variables[\'PORTALPAGE\']', $tmpl->variables['PORTALPAGE']);
if ($links_info != NULL) $var_trees .= var_tree('$links_info', $links_info);
if ($spreads_info != NULL) $var_trees .= var_tree('$spreads_info', $spreads_info);
if ($_SERVER != NULL) $var_trees .= var_tree('$_SERVER', $_SERVER);
if ($_SESSION != NULL) $var_trees .= var_tree('$_SESSION', $_SESSION);

//close the xml var_tree hierarchical data structure
$var_trees .= "</var_trees>";

//store the xml data in an external xml file
file_put_contents(dirname(__FILE__).'/var_trees.xml', $var_trees);

//recursive function to generate nested xml data structure for a given variables data
function var_tree($key, $value){
$var_tree = "";
if(is_array($value)){
$var_tree .= "<var_tree label=\"".htmlentities($key)."\" >";
foreach($value as $key => $val){
$var_tree .= var_tree($key, $val);
}
$var_tree .= "</var_tree>";
}else{
$var_tree .= "<var_node label=\"".htmlentities($key)."\" value=\"".htmlentities($value)."\" />";
}
return $var_tree;
}
Creating a variable inspection and debugging tool using XML data

Taking this one step further, you can then utilize this developed XML format to create more advanced debugging tools. One quick example for this is a small Flex application that I quickly developed to interpret the previous example’s generated XML data. This debugger interface is automatically opened in a separate window when any portal template page embeds the {varviewer} template tag, which can be generated in your site’s local.inc.php file using a code snippet similar to the following.

$tmpl->variables['PORTALPAGE']['varviewer'] = 
"<SCRIPT TYPE='text/javascript'>winRef ="+
"window.open( '/VarViewer/templates/varviewer/PortalVariableViewer.html', 'varviewer',"+
"'height=450, width=750'); </SCRIPT>";

View the demo of this application HERE (user: blogdemo/pass: blogdemo). This XML variable debugger application has also been packaged as a House portal site named VarViewer that you can use and experiment with on your own portal server. You can download it HERE. This is a simple example, but illustrates the possibility of developing a more advanced and searchable Portal template variable arrays debugger.

Conclusion

There are a variety of ways to inspect and debug the Portal template variables. Using PHP’s built in variable display functions, and even custom data XML formats allows for a greater degree of flexibility when working with them. In the end these variables are an important to understand when trying to modify and extend Portal’s appearance and functionality, and using these techniques may help you during this learning process.

1 Comments Click here to read/write comments

10Gb networking and DAM

Posted by Rob Pelmas on Wed, Jun 03, 2009 @ 08:56 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

We're a bunch of performance geeks here. We've been tweaking blocksizes, stripe, and interleave settings on disk since SGI first gave you access to 'em. Tuning and re-tuning SWAP size, location, type is in our blood. A few percentage points here, double digit gains there, all without more capex. Gotta love it.

Now, anytime a paradigm shift in technology comes out there's a steep cost differential to it, right? 10Gb networking had only a tiny little blip of time when it was out of reach of the masses, which is a refreshing change. You can kit out most servers with a card, an acceptable managed switch with a 10Gb port or two, for a very reasonably cost.

Why go to 10? Our desktops have had Gb cards for what seems like forever, and very fast CPUs. With just a couple 'power' users you could swamp the networking capabilities of a server. Of course, a handful of years ago disks could only cough up 150Mb/sec or so of sustained data, so network tended to not be the gating factor in server  performance. Modern disk starts at well over 300Mb/sec, and if you stripe or otherwise use some common sense design principles you can achieve multiples of that.

 Xinet and NAPC both use the 1 to 6 rule for users and performance: with 6 retouchers (or 'power' users), you can assume 1 of them will be accessing the server at one time. 12=2, 18=3. It's a rough rule of thumb, but one that seems to stand up over time. 12 heavy hitters can thus drain 120Mb/sec out of a server, which is the better part of 2 1Gb cards bonded together. Add in the other users, doing layout, OPI printing (yep, some folks still use an OPI workflow), and Portal access, you've got a saturated pipe. 10gb gives you a good 800mb/sec of access speed, which will sate all but the most demanding organizations needs for data.

Next of course, we can talk about teaming 10Gb interfaces! (insert evil chortle of delight here).

 


2 Comments Click here to read/write comments

Portal Site Customization

Posted by Jason Palmer on Wed, May 20, 2009 @ 03:25 PM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

Customizing a Portal Site is a straightforward process and can offer you the ability to change the default look & feel of a site, or even increase the default functionality of a site.

How it all works

Exhibit File Structure


 

 

 

All sites follow a similar file structure.  Looking at the example above, we see that the default Exhibit site contains a few PHP files and a templates folder.

Config.inc.php – Contains all site configurations.
Index.php – Responsible for initializing (bootstrapping) the Portal architecture.
Startup.php – Responsible for initializing (bootstrapping) the Portal architecture.

Inside the templates folder, we see a bunch of html/css/js files and a single php file local.inc.php.  These are the files a web developer will modify to change the look & feel of a site and/or add their own functionality.

The first step in learning to develop for the Portal platform is understanding how Portal works and how a Portal site works.  The diagram below demonstrates how Portal creates the screens you see when browsing a Portal Site.

Portal Workflow


 

Inside a template file

The templates folder contains several *.tmpl.html files.  These are the front-end of the Portal Site and it’s where you can make layout and design changes.  You may structure these files the same way you structure your HTML documents normally.

A typical layout file contains mostly standard HTML, however they also contain tags and tag domains.

From the Xinet Portal manual:

"A tag domain is a designated block of HTML within a template that has variable portions called tags.  You can recognize a tag domain in WebNative Portal templates because a domain always begins with and ends with ."

A tag domain contains several tags.  Depending on the template (i.e. ImageInfo, Browse, etc), and the tag domain being used, certain tags will be available. 

During the bootstrapping process the default values for each tag are set, however a PHP programmer has the ability to change these values using the local.inc.php file.

 

Customizing a Tag

Before making any PHP customizations, one should always investigate whether a change can be made to the config.inc.php file first to give the desired result.

Xinet’s templating system works with a few arrays of data in which tags are derived.  These arrays store a variety of information about files, directories, volumes, keywords, etc.  Referencing the diagram above, it becomes clear that the values in these arrays can be accessed and manipulated using the local.inc.php file.

For example, if I wanted to append to all files Comment attribute I would write a block of code like this in the local.inc.php file:

Sample Portal Code


 

 

 

The above block of code would append “ – Copyright of my company” to the end of each files comment attribute.

Please reference the Xinet manual for a complete listing of PHP arrays.

Conclusion

Customizing a Portal Site is fairly simple and provides you with the ability to brand the interface and expand the functionality as you see fit, while still maintaining a powerful & secure asset management interface.

0 Comments Click here to read/write comments

All Posts