[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][markup] First conference call
Hello All, 1. I have a comment regarding #3 below. The option two in #3 where a provider adds a prefix to all the javascript functions names is a very complex and involved task. Basically a provider will have to add a prefix to all javascript function names wherever they are defined and referenced. This part is easy. The real problems comes in where a javascript function calls another javascript function and the multiple different ways it may call the other function. The provider will have to parse through all its javascript functions in all the referenced javascript files, find all possible ways a js function might be calling another function and prepend all occurences with a prefix. In my opinion, this puts a very heavy burden on the provider. This parsing need not be done at runtime (unless all js is dynamically generated) but my concern is that putting this restriction on the provider essentially requires the provider to write a small js parser for all existing javascripts. 2. The list of allowed HTML tags does not allow for any browser specific tags. In my opinion, this can be very inhibiting for portlets that want to use really nice but browser specific ui and would require massive changes in some cases to conform to this standard. It almost seems that we need to define categories of HTML elements: (a) those that may affect the format/structure of the whole page (e.g. link, iframe etc.) (b) those that are self-contained (e.g. image etc.). Both lists should not be extensible, we just define the basic tags. We need to allow the second category and disallow the first. I am not very comfortable with the approach of defining allowed HTML tags because this lands us into an endless process of updating the list of tags and in some cases severally restricts the resulting ui. 3. Just like the javascripts, we need to encode the form names for namespaces too. Actually, we will have to encode the name/id of each and every field on the page as many browsers will break or act unpredictably if multiple elements have same ids on a page. A better approach would be to surround the content from each portlet into a container element (e.g. span or a div) but even that won't solve all the problems. What do you get when you do: document.all.item("FieldID") when you have multiple fields with id = "FieldID". 4. In the list of allowed tags, I see that we allow the Object tag. We definitely need to allow it but it opens up another set of problems for the portal. What if the object tag is pointing to a signed java applet? If the portal server is proxying it, what does it do with the codebase? What will happen to the certificate of the portlet server? Will it work? How many other permutations will we have to consider? More thoughts to come, Thanks, KM Khurram Mahmood Off: (925) 694-9566 Cell: (408) 230-6784 "Carsten Leue" <CLEUE@de.ibm.com To: "Gino Filicetti" <gfilicetti@bowstreet.com> > cc: "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org> Subject: RE: [wsrp][markup] First conference call 04/05/2002 04:04 AM Hi all, unfortunately today I got a terrible cold and may not be able to attend the call tonight. However here are some details on markup processing I dealt with when implementing the demo: 1. Markup Rules: The markup a portlet generates must be restricted in such a way that it can be aggregated together with other portlets onto a page. These restrictions depend on every markup we want to support, so we will have to work out the details for each case. For the case of HTML the markup restrictions were that the markup must be embeddable into an HTML table cell (so it must not include one of the following tags Base, body, frame, frameset, html, meta, noframes, style). However sometimes the portlet wishes to expose certain tags that can only occur in a global scope (e.g. meta tags or cetain javascript methods). The portlet API allows for this by defining the beginPage and endPage methods in addition to the service method that generates the markup. A mapping of these additional calls to WSRP calls would introduct two more roundtrips what is inacceptable. My current solution is to allow the portlet to generate markup that is structured into tree parts, one for the beginPage equivalent, one for the service equivalent and one for the endPage equivalent. The aggregator gets the markup in its beginPage call, parses it and stores the fragments. It can then stream the stored fragments inside the corresponding portletAPI methods into the output stream. Example: WSRP service generates in a single roundtrip <-- BEGIN_PAGE_TOKEN --> Begin Page Markup <-- MARKUP_TOKEN --> Markup <-- END_PAGE_TOKEN --> End Page Markup Aggregator gets the markup in its beginPage method: - parses the three parts. if no separator is located it assumes that the whole markup belongs to the service method. - outputs the beginPage part to the output stream in the service method - outputs the stored services part to the output stream in the endPage method - outputs the stored endPage part to the output stream 2. URL rewriting: The WSRP service must have the possibility to encode URLs in the markup so that are routed back to itself. From the point of view of the aggregator these URLs cannot be direct links to the provider but must be intercepted by the aggregator. I see two possibilities how such URLs can be embedded into the markup: 2.1 the aggregator sends a prefix with each markup request to the provider. The provider must then prefix each URL with this prefix and may append private data. When the user clicks on a link this event is automatically routed to the prefix's location so the aggregator can intercept. 2..2 the provider prefixes each URL with a predefined and constant value (would be part of the WSRP spec). The aggregator must then parse the markup for such prefixes and replace them by links that point to itself. In the demo I implemented the 2.2. version. It seems favorable to me due to the following reasons: - aggregator and provider are decoupled. In 2.1 it would not be possible for the provider to expose a static page as its markup but is must embed the (dynamic) prefixes in any case. In 2.2. the provider is free to expose static pages as the prefixes are constants. This also reduces the amount of data to be transfered between aggregator and provider. - The markup must be parsed anyway due to 1. If the prefixes are chosen wisely (see below) this can be done in one step. 3. Namespace encoding: If multiple portlets of the same kind are aggegrated into one page certain named entities (like javascript methods) may appear twice causing a name clash. To prevent this such entities must be encoded specially. One way to do so would be to parse the markup on the aggregator's side, identify each entity and put it into a unique namespace. However this approach requires a parser for each type of supported markup, a task that is very laborious and even impossible if markups are added on the fly. A solution would be to enforce the provider to encode the named entities somehow during markup generation. The provider would have to add a prefix to these entities that makes them unique. As in 2. two possiblities exist, either the aggregator passes the namespace to use to the provider or the provider uses a constant prefix that is rewritten on the aggregator's side. Using the same argument as in 2. I would prefer the second approach 4. Efficient parsing: All of the steps 1-3 require the aggregator to parse the markup generated by the provider. However it is not neccessary to understand the markup's syntax (e.g. build a document tree) but only to locate certain tokens in the markup and replace them by different tokens (e.g. replace the URL token by the aggregator's access point or the namespace token by the provider specific namespace valid in the aggregation context). An efficient way to parse the markup would be to define an escape token that is the same for all three cases. Specific information to distinguish URL rewriting and namespace encoding follows this token. A parsing algorithm could then use a very efficient search algorithm to locate the escape token and then branch to a (slower) analysis and rewriting procedure. As such a seach algorithm I would propose the BM alg. This approach would imply that the escape token is relatively long and consists of characters that are very improbable to find in a normal markup. e.g. ESCAPE_TOKEN = {29B23528-2736-4e97-93B6-3BECD04A4F6A} URL_TOKEN = ESCAPE_TOKEN<provider specific URL info> NAMESPACE_TOKEN = ESCAPE_TOKEN{name} Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Gino Filicetti | | | <gfilicetti@bowst| | | reet.com> | | | | | | 04/03/2002 06:06 | | | PM | | | Please respond to| | | Gino Filicetti | | | | |---------+----------------------------> > ---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org> | | Subject: RE: [wsrp][markup] First conference call | | | | | > ---------------------------------------------------------------------------------------------------------------------------------------------| Team, Here are the details for the conference call on Friday: ------------------- Date: Friday, April 05, 2002 Time: 11:00 AM Eastern, 8:00 AM Pacific Duration: 1 Hour Title: WSRP Markup Sub-Committee For quick access, go to https://bowstreet.spiderphone.com/27914907 (This link will help connect both your browser and telephone to the call) OR dial 1 (866) 633-2978 (in the US) or +1 (646) 485-9300 (internationally) and enter 2791 4907 ------------------- Carsten, I'm glad you can make the call, and we look forward to getting your input. Again, this call is open to any other interested parties as well. G > -----Original Message----- > From: Carsten Leue [mailto:cleue@de.ibm.com] > Sent: Wednesday, April 03, 2002 10:42 AM > To: Gino Filicetti > Cc: 'wsrp@lists.oasis-open.org' > Subject: Re: [wsrp][markup] First conference call > > > > Gino - I will be happy to attend the call on friday, 11am EST > is ok for me. > Can you send me an invitation together with the call-in details? > > To start with I could give a brief summary on what a portlet > programmer > must take into account to make remote portles work from my > experience with > the demo impl. This would include > - namespacing of fields and javascript functions > - URL rewriting > - how can common javascript methods (variables) be used by different > portlets > > I think that the concepts URL rewriting and namespace encoding are of > interest to the interface group as well and we should stay in > sync here. > > > Best regards > Carsten Leue > > ------- > Dr. Carsten Leue > Dept.8288, IBM Laboratory Böblingen , Germany > Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > > > |---------+----------------------------> > | | Gino Filicetti | > | | <gfilicetti@bowst| > | | reet.com> | > | | | > | | 04/02/2002 10:15 | > | | PM | > | | Please respond to| > | | Gino Filicetti | > | | | > |---------+----------------------------> > > >------------------------------------------------------------- > -------------------------------------------------------------- > ------------------| > | > > | > | To: "'wsrp@lists.oasis-open.org'" > <wsrp@lists.oasis-open.org> > | > | cc: > > | > | Subject: [wsrp][markup] First conference call > > | > | > > | > | > > | > > >------------------------------------------------------------- > -------------------------------------------------------------- > ------------------| > > > > Everyone, > > Since we didn't officially set a time for our first > conference call during > the face to face meeting, I'd like to propose our first > conference call for > this Friday, April 5th at, 11am EST, 8am PST and 6pm CET.... > Currently, we do not have any members in Germany, so we might be more > flexible on the time... However, I think it might be useful > to have someone > who worked on IBM's demo implementation on the phone this > time (and maybe > even part of the group permanently) such as Carsten... > Knowing more about > the challenges faced in that initial implementation would be a good > starting > point for us. > David has come up with a few topics that we should start > initial discussion > on during the call: > -CSS Style: naming standards, modularisation, themes, ... > -Markup rules : (HTML, WML, CHTML) > -Scripting rules and conventions (JavaScript, > VBScript, ???) > -Namespace encoding rules > -Developer guidelines ? > There may be some overlap here with the work that other groups will be > doing > and if so, we need to iron that out as well. I know Michael > has included > almost all of these points in his list of topics for the > initial con call > of > the interfaces and protocols sub-committee. > Please let me know if the proposed time is acceptable and I > will go ahead > and schedule the conference call. > > . . . . . . . . . . . . . . . . . . . . . . . . > Gino Filicetti | Software Engineer > One Harbour Place, Portsmouth, NH 03801 > T 603.559.1692 | gfilicetti@bowstreet.com > w w w . b o w s t r e e t . c o m > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC